From: ebiederm@xmission.com (Eric W. Biederman)
To: Kirk Reiser <kirk@braille.uwo.ca>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: Advice saught on math functions
Date: 15 Jul 2002 04:03:27 -0600 [thread overview]
Message-ID: <m1adotpats.fsf@frodo.biederman.org> (raw)
In-Reply-To: <x7hej5djbj.fsf@speech.braille.uwo.ca>
Kirk Reiser <kirk@braille.uwo.ca> writes:
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>
> > This is how Nicholas stuff works, you can still get the kernel messages
> > by scrolling back. I'm told this meets S508.
>
> I don't give two shits about S508. For one thing that is a
> U.S. statute. It has no relevance here.
>
> > Actually some of this is true for sighted people. You only get console
> > messages after PCI is initialised, until then they are queued away or
> > only on serial console.
>
> Even though, pci gets initialized pretty early in the boot sequence
> doesn't it? Considerably before init?
Some. Depending on how all of this works, in 2.5.x it should be possible
to get initramfs mounted and running very early on. But there are definitely
classes of problems that are not solved.
> > If you are using a conventional BIOS then the first kernel messages being
> > readable as they occur versus just after seems to have only a little value.
> > If you have a fully accessible LinuxBIOS thats something quite different.
> > In that case can you use a Linuxbios hook for the console speech until
> > user space takes over ?
>
> I don't really know. I haven't had time to really get into the BIOS
> accessibility yet. I know for serial synths we can turn serial on in
> lilo and at least hear what is going on. Without modifying lilo for
> each synth other than serial we have no way of knowing whether we have
> the full lilo prompt or what.
>
> If we could modify a linux BIOS and then flash it onto any flashable
> BIOS that would be really useful.
There are some pieces that the LinuxBIOS people could do.
The overall architecture is divided into two pieces
1) LinuxBIOS which simply initializes the hardware.
2) Bootloader (which may be based on Linux, but is usually a hacked
version of etherboot) which loads the kernel from some hardware
device.
Rom chips range from 256Kilobytes to 1Megabyte, with 256KB being the
median. So there isn't room for a lot of unnecessary fluff.
The bootloader is reusable while the core LinuxBIOS is not, it is just
a matter of selecting the correct firmware.
The current architecture does allows for all BIOS parameters to be set
from Linux so there is an accessibility gain there.
Given the space constraints on the BIOS side, either a very small
standalone speach synthsizer needs to be constructed, or more likely
a set of tones (that can work like post codes) can be introduced
to give a feel where in the boot process the BIOS is.
After that a nice bootloader based on the Linux kernel with a real
user space can be loaded from the hard drive where there is plenty of
room. Everything that possibly could would need to be built as
modules to decrease the time to user space, and to allow as many
messages to be processed by the speech synthesizer.
People doing serious kernel development would need more extensive
facilities, but this should suffice for basic trouble shooting. If
there is a standard brail output device, there may be solutions I am
not familiar with.
Eric
next prev parent reply other threads:[~2002-07-15 10:12 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-12 14:08 Advice saught on math functions Kirk Reiser
2002-07-12 14:39 ` Alan Cox
2002-07-12 14:52 ` Kirk Reiser
2002-07-12 15:32 ` Alan Cox
2002-07-12 16:04 ` Kirk Reiser
2002-07-12 16:31 ` Alan Cox
2002-07-12 16:21 ` Dave Jones
2002-07-15 9:46 ` Eric W. Biederman
2002-07-16 5:26 ` H. Peter Anvin
2002-07-15 10:03 ` Eric W. Biederman [this message]
2002-07-15 14:10 ` Kirk Reiser
2002-07-15 16:38 ` Eric W. Biederman
2002-07-12 15:46 ` Nicolas Pitre
2002-07-12 16:30 ` Kirk Reiser
2002-07-12 17:03 ` Nicolas Pitre
2002-07-12 16:22 ` J.A. Magallon
2002-07-12 16:49 ` William Park
2002-07-13 14:00 ` Pavel Machek
2002-07-13 17:10 ` Alan Cox
2002-07-12 14:46 ` Richard B. Johnson
2002-07-12 15:42 ` Sandy Harris
2002-07-12 16:46 ` Kirk Reiser
2002-07-14 0:20 ` Erik Andersen
2002-07-14 14:17 ` Sandy Harris
2002-07-14 16:49 ` Albert D. Cahalan
2002-07-14 17:01 ` Thunder from the hill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1adotpats.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=kirk@braille.uwo.ca \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox