Dave Mielke <[EMAIL PROTECTED]> writes: >>"Shows up" is going to be complicated, because it might as well take some >>time until the chroot actually happens and the root fs is fully populated >>(e.g., >>I use a custom setup at work where the root fs is actually retrieved >>with rsync, that can take some time). But yes, that sounds like a plan. > > But brltty is now able to wait for resources. It doesn't need them all to be > available right up front. If enough devices are in the initramfs then it can > get going well enough, and still change to the real root file system later > for > even better functionality. Does the initramfs remain mounted to the real root > file system?
No, the ramfs does not stay mounted, its gone after the real /sbin/init starts. >>Could we perhaps use a special signal to implement this? >>We could have some parameter to brltty that tells it what the path >>of the new root fs is going to be, and if brltty receives this >>signal, it will reopen all its filehandles based on the >>new root? We could then just send this signal in >>the sysvinit script if we detect that brltty was started >>by initramfs... > > Do you have a particular signal in mind? Not really, samuel suggests to use SIGHUP. > Is there any convnetional signal for something like that? I dont know of any rules here. I would have used one that is normally not in use (like USR1...) -- CYa, Mario | Debian Developer <URL:http://debian.org/> .''`. | Get my public key via finger [EMAIL PROTECTED] : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/> _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
