linux-kernel - Re: [PATCH] Console keyboard events and accessibility

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070901125120.GC3251@implementation.famille.thibault.fr>
Date:	Sat, 1 Sep 2007 14:51:20 +0200
From:	Samuel Thibault <samuel.thibault@...-lyon.org>
To:	Pavel Machek <pavel@....cz>
Cc:	Jan Engelhardt <jengelh@...putergmbh.de>,
	linux-input@...ey.karlin.mff.cuni.cz, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, dtor@...l.ru
Subject: Re: [PATCH] Console keyboard events and accessibility

Hi,

Pavel Machek, le Sat 01 Sep 2007 12:32:58 +0000, a écrit :
> > > > > They can use the raw xlation for that.
> > > > 
> > > > For userland, yes.  This is for kernel modules.
> > > 
> > > And should speakup be a kernel module? Why?
> > 
> > Because userland only begins quite late in the boot process, and
> > userland may hang.
> 
> Initrd means userland is started very early on most machines these
> days, and kernel may hang, too.

Very early is not so early, and loading initrd itself may actually fail.
The kernel may indeed hang, but there are more chances to get some
messages before the hang.  Don't _you_ have a VGA screen for getting
earliest failure messages from the kernel?

> > > What is missing? Yes, you may want to do a small kernel module to read
> > > kernel bootup messages.
> > 
> > That's what it's all about.
> 
> But this small module should not need keyboard leds support, as those are not used during
> boot. If all you want is to read kernel bootup messages, you should
> just register a special console. Actually serial console should do.

The problem is that using both a tool for early message and for later
messages is not particularly handy, that's why speakup is actually
used by people both for boot time and afterwards.  People are indeed
considering moving speakup into userland, but some people still _need_
speakup in the kernel for their everyday work.  Having two versions of
speakup (user and kernel) is just asking for more maintain work, and it
happens that speakup already doesn't have many people involved...

Samuel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/