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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ