I’m trying to track down an user interface issue that might be in how Virtual Box communicates with Haiku, or it might be normal behavior in Haiku, but since I only have VB, I can’t tell. To learn more about the Haiku environment, I have enabled LOG_EVENT in MouseInputDevice.cpp. I can build mouse from the Jamfile in src/add-ons/input_server/devices/mouse (the top level Jamfile at src/ can not find the target from jam -q mouse, which kind of puzzles me because I thought I could specify any sub-target).
The challenge is replacing the mouse file in /boot/system/add-ons/input_server/devices. The partition is mounted read-only, which makes sense. To avoid messing things up, I added a second virtual storage device in VB, installed a recent haiku-nightly on it, and made it bootable (as per the instructions at https://www.haiku-os.org/documents/user/how_to_get_haiku_booted). However, when I boot from the normal drive, the bulk of the system files on the second drive disappear. When I hold the shift key down and boot from the alternate installation, the bulk of the system files from the normal boot drive disappear, and the booted system is mounted read-only. If I boot from the nightly iso and then go to the desktop, I get the system installation from the normal boot drive. I have not been able to locate documentation discussing this through a review of the submitted articles, the BeBook, and the Getting started pages. (Edit: I have seen some code in the bootloader code called BlacklistedPath:: PathBlacklist.cpp and I wonder if this is the mechanism by which non-booting systems are being hidden from view.)
Is there is a quick and straightforward way to replace individual system files, including kernel_x86, on either the currently booted system or a spare one, being used for development?
Thanks - I added the mouse driver to the non-packaged directory, and I am getting some messages indicating the driver was loaded, but I do not believe the driver was attached to the device. I think the add-ons mouse driver was attached. This is probably preferable, or else it’d be relatively easy to override a device driver with something else. During development phases, though, it would be nice to have some mechanism like that.
It discusses blacklisting packages, with the statement
“In Haiku’s boot menu , there is a ‘Blacklist entries’ option available. This method will only let you disable system packages, and only until the next time you reboot.”
Slick. If the OS is a package, even though it looks like a file system or a collection of files, it could be hidden pretty easily. This would reduce user confusion over boot systems. On the other hand, I wonder if something could get loaded at boot time and then get the filesystem to blacklist it while remaining resident in memory.
[quote=Diver]Actually, this is how it supposed to work. You can use the following command to see if your module is loaded:
listimage | grep mouse
[/quote]
Thanks! I did not know that was how it was supposed to work, and I did not know about listimage. Listimage shows my modified mouse driver as the only mouse driver loaded.