Shutdown

[Nobody III]

It seems like it would still be good to make the USB driver restartable,
and have the ability to do simulate disconnecting then reconnecting
individual devices as well.

On Fri, Apr 17, 2020, 9:07 AM Norman Feske <norman.feske at genode-labs.com>
wrote:

> Hi Colin,
>
> > 1) 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.
>
> > 2) 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
>
> --
> Dr.-Ing. Norman Feske
> Genode Labs
>
> https://www.genode-labs.com · https://genode.org
>
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
>
> _______________________________________________
> Genode users mailing list
> users at lists.genode.org
> https://lists.genode.org/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20200417/616b8919/attachment-0001.html>