* The binary search was somewhat broken.
* Restructure a bit so that only the binary/linear search itself is
handled separately. The handling afterwards is common again.
* Fix sparse block handling:
- There can be sparse blocks before the first extend.
- Set the return parameter _count in this case as well.
- Set the return parameter block to 0 instead of 0xffffffff. That's
what ext2_get_file_map() expects.
Fixes an infinite loop in ext2_get_file_map() when sparse blocks are
involved, due to previously returning a wrong block and a 0 count.
Ticket #9274 may be related.
* Check whether the vectors we get are sparse file vectors and satisfy
them immediately instead of creating a subrequest. Untested, since the
API isn't used by ext2 as it should be.
* Add error == B_OK to the condition of the outer loop.
Besides that it failed to actually iterate through the vectors, it
shouldn't try to clear physical memory in the first place. The iovecs
refer to virtual address ranges. Rename it to zero_iovecs() to avoid
confusion.
- Move InstallPackageAction's _FindPackageByName to PackageAction, so
UninstallPackageAction can make use of it as well.
- Rename DownloadProgressListener to PackageProgressListener and add
hooks for the package manager's DownloadProgressComplete,
StartApplyingChanges and ApplyingChangesDone events.
- InstallPackageAction implements DownloadProgressComplete in order to
gather all dependent packages that were downloaded as part of the
installation request. These are then set to active, or reset to available
depending on the outcome. Fixes the problem reported in #10189.
- UninstallPackageAction now implements the aforementioned ApplyingChanges
hooks in order to track all packages to be uninstalled as part of the
transaction. Upon completion, they are all accordingly marked as Available.
Previously the state wasn't correctly reset for any dependent packages that
were also removed as a consequence of the requested package's removal.
* App tried to create symlink in folder ~/config/boot/launch,
what throw an error, because this folder is read-only now.
* Now it creates such in ~/config/settings/boot/launch.
Signed-off-by: Matt Madia <mattmadia@gmail.com>
* It uses physical pages directly, not wasting kernel address space.
* The user interface is somewhat crude, it uses writes to a control
device (output to serial debug/syslog), e.g.
echo register 4g > /dev/disk/virtual/ram/control
to register a 4 GB RAM disk. It is published under
/dev/disk/virtual/ram/<index>/raw and can be formatted with DriveSetup
like any other disk. Unregistering is broken ATM.
* It's not on the image by default, but can be added via
AddNewDriversToHaikuImage disk virtual : ram_disk ;
* I found it quite useful when working on large HaikuPorts ports.
E.g. mounting a RAM disk at the port's work directory shaves a lot of
time off disk heavy operations. Obviously one shouldn't let changes
lie around on it without back up.
Set HAIKU_CONTAINER_SYSTEM_DIR_TOKENS for the Haiku image to "system
non-packaged". All the rules using the variable would put stuff in
directories that will be read-only in the end (and aren't used anymore).
This way they can be used in UserBuildConfig.
Simplify the code, which also fixes the bug that the I/O context's root
was ignored when it was a mount point, thus resulting in globally rooted
paths in this case.
* virtio_scsi can have 16384 luns, though we cap at 256 as our scsi_ccb
only uses uchar as a type for target_lun and target_id members.
* minor code cleanup in scsi_scan_bus().
Remove the reimplemented hook methods groups because some
hook methods are there, some are not, unfortunately doxygen can’t
tell if a hook method just calls the default or does something else and
we tend to include all the hook methods even if we don’t actually make
any functional changes to them making the docs a bit more verbose
than they otherwise would be.
