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?
Take a look at these 2 articles:
You can probably use “non-packaged” structure to override
This will likely not work for the kernel though
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.
Actually, this is how it supposed to work. You can use the following command to see if your module is loaded:
listimage | grep mouse
I found the following blog entry, after searching on packagefs:
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
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.