Hi Colin,
- I have been using Sculpt on real hardware. What I do for shutdown is
to open "Storage" under "Components" and de-select "Use" on my primary "GENODE*" partition. I assumed that this would cause any pending file operations to complete, similar to a UNIX "sudo umount". Is that right?
Unfortunately not. By "unusing" the Sculpt partition, you are immediately wiping out all components without mercy. You probably have been lucky because the file-system's cache is quite small and the file system writes back data periodically.
- Sometimes I do feel the need to reboot Sculpt, but potentially this
is not completely necessary if there were a way to restart certain services. Is it possible to restart internal components? Most common culprits for me would be usb_drv, and the depot-related components. Ideally this could be done without the runtime system killing my VMs, but I suspect that's asking too much.
The USB driver and the depot components are strict dependencies. If restarted, a dependent VM would be implicitly restarted as well. For example, even though you can in fact force the restart of the USB driver by editing a 'version' attribute in USB driver's <start> node in /config/drivers, this is not helpful because all dependent components (including Sculpt's leitzentrale) would be affected. Better don't do this! ;-)
We actually plan to make drivers for network, wifi, framebuffer, and audio restartable, which will generally become possible because those particular drivers do not encapsulate much state. But bus drivers (like USB) or storage drivers contain complex state that would go lost upon restart. So those components must ultimately become infallible.
You can help us with that. I encourage you to report any problems that you experience with those low-level components, if possible.
Cheers Norman