>>>>> "Valdis" == Valdis Kletnieks <[email protected]> writes:
>> You don't tell any kernel about that... it is the bootloader
>> you are talking to. And that one may very well have integrated
>> kbd support.
Valdis> So GRUB knows about keyboards, lets you type in the
Valdis> "init=/bin/bash", it loads the kernel, the kernel launches
Valdis> init, /bin/bash gets loaded
If init can launch /bin/bash (actually, it lauches getty in most
setups), why can't it start the userland keyboard driver daemon?
Back in the old days before the introduction of /etc/rc.d/, every
daemon was started from by init.
Valdis> - and /bin/bash can't talk to the keyboard because the
Valdis> userspace handler hasn't happened.
As soon as the daemon is running, /bin/bash can talk to the keyboard.
There is not much concurrency problems here. The current input system
makes it possible for /bin/bash to start opening the keyboard and
waiting for input before the userspace handler is ready.
Valdis> At that point you're stuck...
I can't see how stuck it is. And if you fear that the userland
keyboard driver would crash (maybe due to bugs), use the 'respawn'
option in /etc/inittab.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
On Sun, 2004-06-06 at 11:37, Sau Dan Lee wrote:
> >>>>> "Valdis" == Valdis Kletnieks <[email protected]> writes:
>
> >> You don't tell any kernel about that... it is the bootloader
> >> you are talking to. And that one may very well have integrated
> >> kbd support.
>
> Valdis> So GRUB knows about keyboards, lets you type in the
> Valdis> "init=/bin/bash", it loads the kernel, the kernel launches
> Valdis> init, /bin/bash gets loaded
>
> If init can launch /bin/bash (actually, it lauches getty in most
> setups), why can't it start the userland keyboard driver daemon?
>
> Back in the old days before the introduction of /etc/rc.d/, every
> daemon was started from by init.
>
>
> Valdis> - and /bin/bash can't talk to the keyboard because the
> Valdis> userspace handler hasn't happened.
>
> As soon as the daemon is running, /bin/bash can talk to the keyboard.
> There is not much concurrency problems here. The current input system
> makes it possible for /bin/bash to start opening the keyboard and
> waiting for input before the userspace handler is ready.
>
>
> Valdis> At that point you're stuck...
>
> I can't see how stuck it is. And if you fear that the userland
> keyboard driver would crash (maybe due to bugs), use the 'respawn'
> option in /etc/inittab.
The point is that 'init=/bin/bash' is usually used as a method to
do some _unexpected_ rescue work - meaning you usually do not think
about it (or write a shell script to start a keyboard daemon) until
you need it. Thats it - a rescue method - and its got nothing to do
with what is in inittab, or if getty's are started or not. Some
distro's even have sash installed by default (statically linked) in
case your glibc is borked or such, and you need to cp/mv/gunzip things.
Anyhow, the other point that should be made, is that your are really
getting boring/annoying. Please face the fact that many of us (most?)
do not want a silly daemon for keyboard, but an in-kernel driver.
Guess what else ... Valdis, etc do not even argue with you for wanting
this silliness (besides not wanting to get rid of the in-kernel driver),
but are prepared to add raw access, so that you can go and code/use your
daemon (Ok, so maybe the raw access is for more than what you want, but
anyhow ...).
So please stop being selfish and continuing to spam the list.
Thanks,
--
Martin Schlemmer
On Sun, Jun 06, 2004 at 11:37:41AM +0200, Sau Dan Lee wrote:
> >>>>> "Valdis" == Valdis Kletnieks <[email protected]> writes:
>
> >> You don't tell any kernel about that... it is the bootloader
> >> you are talking to. And that one may very well have integrated
> >> kbd support.
>
> Valdis> So GRUB knows about keyboards, lets you type in the
> Valdis> "init=/bin/bash", it loads the kernel, the kernel launches
> Valdis> init, /bin/bash gets loaded
>
> If init can launch /bin/bash (actually, it lauches getty in most
> setups), why can't it start the userland keyboard driver daemon?
>
> Back in the old days before the introduction of /etc/rc.d/, every
> daemon was started from by init.
At the risk of being flamed, here is an explanation.
If you, at the kernel command line, type "init=/bin/bash", the bash
shell will be used _instead_ of the regular init program. This is very
useful when you made a mistake in the inittab, something deleted your
root entry in passwd/shadow, your filesystem is in trouble and in many
other cases.
This also means that there will be no other program run before or after
bash. All you get is a prompt.
This means the keyboard will have to work without any setup - or you
won't be able to type in anything, like a command to run the daemon, or
a command to insert a module.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Sunday 06 June 2004 04:37 am, Sau Dan Lee wrote:
> >>>>> "Valdis" == Valdis Kletnieks <[email protected]> writes:
>
> >> You don't tell any kernel about that... it is the bootloader
> >> you are talking to. And that one may very well have integrated
> >> kbd support.
>
> Valdis> So GRUB knows about keyboards, lets you type in the
> Valdis> "init=/bin/bash", it loads the kernel, the kernel launches
> Valdis> init, /bin/bash gets loaded
>
> If init can launch /bin/bash (actually, it lauches getty in most
> setups), why can't it start the userland keyboard driver daemon?
>
Init does not start bash, in the case above bash started by the kernel
_instead_ of init. The only thing you have is bash. No regular init scripts
will be executed, nothing.
> Back in the old days before the introduction of /etc/rc.d/, every
> daemon was started from by init.
>
>
> Valdis> - and /bin/bash can't talk to the keyboard because the
> Valdis> userspace handler hasn't happened.
>
> As soon as the daemon is running, /bin/bash can talk to the keyboard.
But nothing has started driver (no scriprs were run, remember?) so it's not
running and bash can't get keyboard input.
--
Dmitry
>>>>> "Dmitry" == Dmitry Torokhov <[email protected]> writes:
>> If init can launch /bin/bash (actually, it lauches getty in
>> most setups), why can't it start the userland keyboard driver
>> daemon?
>>
Dmitry> Init does not start bash, in the case above bash started
Dmitry> by the kernel _instead_ of init. The only thing you have
Dmitry> is bash. No regular init scripts will be executed,
Dmitry> nothing.
If you can launch /bin/bash using init= from GRUB or LILO, you can
equally lauch a bash script that starts the userspace keyboard driver
daemon before and then "exec /bin/bash".
Of course, you can argue that this daemon may rest on a fs that hasn't
be mounted yet, or on a fs that has been corrupted. But so can the
/bin/bash executable!
Moreover, I can also argue the kernel image may also have been
corrupted due to disk errors, and the keyboard driver code lies in
those corrupted sectors, unfortunately.
Further, a kernel keyboard driver can coexist with a userspace one.
The kernel one can be made simpler, providing only the very basic
needs. Once the userspace daemon starts successfully, it can take
over. Programs like X11 may drive the keyboard directly and provide
many sophisticated features that a simple kernel driver doesn't
provide. Take a look at xkb.
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee