[BRLTTY] "Can't access console"
Mario Lang
mlang at delysid.org
Tue Nov 13 09:30:30 EST 2007
Dave Mielke <dave at mielke.cc> 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 mlang at db.debian.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>
More information about the BRLTTY
mailing list