Hi Folks: What I am striving to do is build a software based speech
synthesizer into a linux driver. It is a greatly hacked version of
rsynth I call tuxtalk. My problem is that I have the code so far cut
down to about 66k without the shared library routines. When I
staticly build the object comes out to over 512k. Obviously this is
to large to want built-in to the kernel. The majority of the size is
from libm.a. There are five functions I need from the library, log(),
log10(), exp() cos() and sin().
My questions are:
Are these functions which are supplied by the FPU? I've looked
through the fpu emulation headers and exp() is the only one I can find
any reference to.
Is there a better method to provide these functions than to pull them
out of libm.a?
I appreciate any suggestions or recommendations people may have on
these questions.
Kirk
> Are these functions which are supplied by the FPU? I've looked
> through the fpu emulation headers and exp() is the only one I can find
You can't use FPU operations in the x86 kernel.
Maybe you should do this in user space ? Certainly the more I talk to people
like Nicholas Pitre the more it seems to me that most of the kernel side
stuff is the wrong approach.
Instead would it not be better to
- Fix select on /dev/vcsa to work
- During init start up after init processes are running have
the init tasks (or for that matter the kernel) fire up the
speech helper
The fact 95% of the speakup drivers are going to spontaneously go
obsolete the moment serial ports vanish bothers me.
On Fri, 12 Jul 2002, Kirk Reiser wrote:
> Hi Folks: What I am striving to do is build a software based speech
> synthesizer into a linux driver. It is a greatly hacked version of
> rsynth I call tuxtalk. My problem is that I have the code so far cut
> down to about 66k without the shared library routines. When I
> staticly build the object comes out to over 512k. Obviously this is
> to large to want built-in to the kernel. The majority of the size is
> from libm.a. There are five functions I need from the library, log(),
> log10(), exp() cos() and sin().
>
> My questions are:
> Are these functions which are supplied by the FPU? I've looked
> through the fpu emulation headers and exp() is the only one I can find
> any reference to.
>
> Is there a better method to provide these functions than to pull them
> out of libm.a?
>
> I appreciate any suggestions or recommendations people may have on
> these questions.
>
I think you want to do this in user-mode so you get to use
the FPU on Intel Machines. Actual interface to any hardware,
i.e., the stuff that sends/receives sounds can be done in
a cooperating kernel module.
We do this kind of stuff here at Analogic. We make all kinds
of waveforms using mathematics, then we write the stuff to
hardware memory and end up with really complex waveforms with
periods in the GHz range, while we created them at a leisurely
MHz or less (build waveform, then upload changes).
You really don't want to use 'C' runtime library routines inside
the kernel because some expect to interface to the kernel using
the user-mode API (int 0x80). This is NotGood(tm)!
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
Alan Cox <[email protected]> writes:
> You can't use FPU operations in the x86 kernel.
That answers that! 'grin'
> Maybe you should do this in user space ? Certainly the more I talk to people
> like Nicholas Pitre the more it seems to me that most of the kernel side
> stuff is the wrong approach.
I agree, except for providing access from the very beginning. If
access can be provided which would never leave the blind user without
speech with a user space solution this would be ideal.
> Instead would it not be better to
>
> - Fix select on /dev/vcsa to work
> - During init start up after init processes are running have
> the init tasks (or for that matter the kernel) fire up the
> speech helper
Can you give me more details? I certainly don't mind looking into
this as a possible solution. Are you willing to give up seeing
anything on the screen until init gets started?
> The fact 95% of the speakup drivers are going to spontaneously go
> obsolete the moment serial ports vanish bothers me.
It bothers me as well. I am currently working toward trying to make
them into standard drivers which can be loaded as modules. We have
new synths coming along which are pci, usb and pcmcia that would be
easier to integrate if I used a standard driver interface.
I am getting a lot of pressure to make some sort of software synth
solution available for folks that cannot afford a hardware synth or
use a platform which doesn't support hardware synths. I also have an
over all philosophy which requires me to provide solutions that
include speech and review capabilities from power up to power down.
Open BIOS and Linux for the first time ever can provide a way for the
blind community to not be a second class citizen to information
access. I am afraid that if I just take the emacspeak approach to
accessibility then my community will stay beholding to others for
their access to available information. I am sorry about the soap-box
preaching but it is a fundamental problem with just user space
solutions.
Kirk
--
Kirk Reiser The Computer Braille Facility
e-mail: [email protected] University of Western Ontario
phone: (519) 661-3061
> Can you give me more details? I certainly don't mind looking into
> this as a possible solution. Are you willing to give up seeing
> anything on the screen until init gets started?
This is how Nicholas stuff works, you can still get the kernel messages
by scrolling back. I'm told this meets S508.
> include speech and review capabilities from power up to power down.
> Open BIOS and Linux for the first time ever can provide a way for the
> blind community to not be a second class citizen to information
> access. I am afraid that if I just take the emacspeak approach to
> accessibility then my community will stay beholding to others for
> their access to available information. I am sorry about the soap-box
> preaching but it is a fundamental problem with just user space
> solutions.
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.
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 ?
Alan
On 12 Jul 2002, Kirk Reiser wrote:
> Alan Cox <[email protected]> writes:
>
> > Maybe you should do this in user space ? Certainly the more I talk to people
> > like Nicholas Pitre the more it seems to me that most of the kernel side
> > stuff is the wrong approach.
>
> I agree, except for providing access from the very beginning. If
> access can be provided which would never leave the blind user without
> speech with a user space solution this would be ideal.
This is certainly possible. This is how I've been accessing Linux (with
both modes i.e. speech and braille). We've added support to BRLTTY so it
can replace /sbin/init to be the very first user process to run and then
fork the real init binary. This is also how we modify Red Hat installation
bootdisks.
> > Instead would it not be better to
> >
> > - Fix select on /dev/vcsa to work
> > - During init start up after init processes are running have
> > the init tasks (or for that matter the kernel) fire up the
> > speech helper
>
> Can you give me more details? I certainly don't mind looking into
> this as a possible solution.
The /dev/vcsa0 device gives you the text content of the foreground virtual
console as well as color attributes and cursor coordinates. The BRLTTY
daemon is polling that device to refresh the braille display or generate
speech. However it would be pretty easy to add select() support for it so
not to have to poll the device.
Also, since the input API will now handle all kind of keyboards, you'll be
able to get any keyboard events from within user space directly as well.
This becomes really handy for speech-only solutions where the standard
keyboard is the only way to control the screen review daemon.
> Are you willing to give up seeing
> anything on the screen until init gets started?
Of course! The maintenance cost of a kernel space solution is simply too
high for the single benefit of actually having speech output while the
kernel is in the process of booting. And yet with an initial ramdisk
(initrd) containing all the user space daemon for speech I'm pretty sure we
can have the kernel reach the init process (or the /linuxrc process for that
matter) without failing in 99.9% of the cases. This gives you virtually the
same result as a kernel space solution.
> > The fact 95% of the speakup drivers are going to spontaneously go
> > obsolete the moment serial ports vanish bothers me.
Also, we must admit that hardware speech synth are simply doomed to get
obsoleted as software solutions are more and more available, affordable and
convenient to use. Those are also best run in user space where the access
to the soundcard is best arbitrated. This is also the only practical way to
run speech access solutions on a Compaq iPAQ for example.
> I am getting a lot of pressure to make some sort of software synth
> solution available for folks that cannot afford a hardware synth or
> use a platform which doesn't support hardware synths. I also have an
> over all philosophy which requires me to provide solutions that
> include speech and review capabilities from power up to power down.
> Open BIOS and Linux for the first time ever can provide a way for the
> blind community to not be a second class citizen to information
> access. I am afraid that if I just take the emacspeak approach to
> accessibility then my community will stay beholding to others for
> their access to available information. I am sorry about the soap-box
> preaching but it is a fundamental problem with just user space
> solutions.
Please _don't_ associate user space solutions with EmacSpeak! While I'm a
true believer in "do it in user space if it can be", I don't agree with the
EmacSpeak philosophy. There is a large gap in between where user space can
be used universally without restricting yourself to the Emacs environment.
And again, with a proper initrd, you can have the kernel reach your user
space speech daemon without any failure. Most boot failures are due to
wrong root devices and such but the final root fs gets mounted _after_ the
initrd is run.
Of course you'll want to see what the kernel displayed during the boot
process, but if you use /dev/vcsa0 you have access to the virtual console's
scrollback buffer where all kernel messages can be seen and even the BIOS
ones! You therefore virtually get from startup to shutdown speech access
and all from user space.
And probably the nicest thing about user space solutions: the old 1995
BRLTTY binary still runs fine on a 2.5.x kernel!
Nicolas
Alan Cox <[email protected]> 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?
>
> 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.
Kirk
--
Kirk Reiser The Computer Braille Facility
e-mail: [email protected] University of Western Ontario
phone: (519) 661-3061
> > 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?
Yes. But quite a few crashes could occur before that (and have) - eg
running a K6 kernel on a 486
> 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.
Serial is going away if the vendors get their way, maybe within 12 months
On Fri, Jul 12, 2002 at 05:31:37PM +0100, Alan Cox wrote:
> Serial is going away if the vendors get their way, maybe within 12 months
Indeed. The number of 'legacy free' boards available do seem to be
on the increase. No serial, no PS2, Nada.
If this keeps up I envisage things like netconsole being even more
useful. 8-)
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On 2002.07.12 Alan Cox wrote:
>> Are these functions which are supplied by the FPU? I've looked
>> through the fpu emulation headers and exp() is the only one I can find
>
>You can't use FPU operations in the x86 kernel.
>
Are you to worried about precission ? Can't you just do your sin() etc.
in fixed point ? (and move all your fpdata to fixed point, of course)
Or perhaps you could use some kind of DCT ?
--
J.A. Magallon \ Software is like sex: It's better when it's free
mailto:[email protected] \ -- Linus Torvalds, FSF T-shirt
Linux werewolf 2.4.19-rc1-jam3, Mandrake Linux 8.3 (Cooker) for i586
gcc (GCC) 3.1.1 (Mandrake Linux 8.3 3.1.1-0.7mdk)
Nicolas Pitre <[email protected]> writes:
> Of course! The maintenance cost of a kernel space solution is simply too
> high for the single benefit of actually having speech output while the
> kernel is in the process of booting. And yet with an initial ramdisk
> (initrd) containing all the user space daemon for speech I'm pretty sure we
> can have the kernel reach the init process (or the /linuxrc process for that
> matter) without failing in 99.9% of the cases. This gives you virtually the
> same result as a kernel space solution.
I don't understand this statement. Why would the maintanance cost of
providing speech output be any higher than serial or video or disk
filing or anything else for that matter?
I like the rest of your observations though and want to look over your
article in more depth and think about it. On first glance though,
modifying vcsa0 to support select is pretty much the same as providing
an output hook the same as I've done in speakup already.
This has somewhat strayed from my original questions though. 'wink'
Kirk
--
Kirk Reiser The Computer Braille Facility
e-mail: [email protected] University of Western Ontario
phone: (519) 661-3061
Kirk Reiser wrote:
>
> ... What I am striving to do is build a software based speech
> synthesizer into a linux driver. ... over 512k. Obviously this is
> to large to want built-in to the kernel.
Can you do it in a module instead?
> The majority of the size is from libm.a.
Does dietlibc help?
> There are five functions I need from the library, log(),
> log10(), exp() cos() and sin().
Can you do something useful with integer versions of those functions?
Forth people have done astronomical calculations with only scaled
16-bit arithmetic. If it's accurate enough to aim telescopes, why
not for your job?
Given that phones work with fine 8-bit samples, I suspect speech can
be done just fine with 16-bit math.
base 2 log is easy; I've seen code for it on the web. Scaling that to
get natural log and log10 is straightforward.
exp() is trivial, provided you have the scaling right so it doesn't
overflow into insanity. How hard the scaling is depends on the
application.
I suspect there's a better way, but a brute force unoptimised shot
at 16-bit sin() and cos() just uses a 128 K table; 16 bits in, 16
out.
Sandy Harris <[email protected]> writes:
> Can you do something useful with integer versions of those functions?
> Forth people have done astronomical calculations with only scaled
> 16-bit arithmetic. If it's accurate enough to aim telescopes, why
> not for your job?
Good question. It might work just fine. I'll take a closer look at
your suggestions and try to figure it out. The synth is not very
high quality so fixed point or integer may be sufficient.
Kirk
--
Kirk Reiser The Computer Braille Facility
e-mail: [email protected] University of Western Ontario
phone: (519) 661-3061
On Fri, Jul 12, 2002 at 06:22:29PM +0200, J.A. Magallon wrote:
>
> On 2002.07.12 Alan Cox wrote:
> >> Are these functions which are supplied by the FPU? I've looked
> >> through the fpu emulation headers and exp() is the only one I can find
> >
> >You can't use FPU operations in the x86 kernel.
>
> Are you to worried about precission ? Can't you just do your sin() etc.
> in fixed point ? (and move all your fpdata to fixed point, of course)
Or, you can use polynomial approximations.
--
William Park, Open Geometry Consulting, <[email protected]>
8-CPU Cluster, Hosting, NAS, Linux, LaTeX, python, vim, mutt, tin
On 12 Jul 2002, Kirk Reiser wrote:
> Nicolas Pitre <[email protected]> writes:
>
> > Of course! The maintenance cost of a kernel space solution is simply too
> > high for the single benefit of actually having speech output while the
> > kernel is in the process of booting. And yet with an initial ramdisk
> > (initrd) containing all the user space daemon for speech I'm pretty sure we
> > can have the kernel reach the init process (or the /linuxrc process for that
> > matter) without failing in 99.9% of the cases. This gives you virtually the
> > same result as a kernel space solution.
>
> I don't understand this statement. Why would the maintanance cost of
> providing speech output be any higher than serial or video or disk
> filing or anything else for that matter?
Kernel speech support maintenance is not hier than serial or disk, it's just
hier than necessary. Better do it in user space when you get the same
functionalities.
That's also exactly what x window is doing i.e. providing video output from
user space.
That's just much, so much easier to maintain user space solutions when it's
possible to do so. You then have the freedom to use whatever facility and
libraries available to user space as you wish.
Nicolas
Hi!
> > Are these functions which are supplied by the FPU? I've looked
> > through the fpu emulation headers and exp() is the only one I can find
>
> You can't use FPU operations in the x86 kernel.
Actually, you can do kernel_fpu_begin(); any FPU you want;
kernel_fpu_end(); but it is rarely good idea to do that.
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
On Sat, 2002-07-13 at 15:00, Pavel Machek wrote:
> > You can't use FPU operations in the x86 kernel.
>
> Actually, you can do kernel_fpu_begin(); any FPU you want;
> kernel_fpu_end(); but it is rarely good idea to do that.
Only
Providing the CPU has FPU facilities
Providing you do no blocking operation during the kernel_fpu_* range
Non x86 has other rules that may be even more complex.
On Fri Jul 12, 2002 at 11:42:19AM -0400, Sandy Harris wrote:
> Does dietlibc help?
>
This is kernel space. Using any math functions is forbidden
in kernel space, so using dietlibc, uClibc, or anything else
is not going to work. Moving the math stuff to userspace will
help, at which point he can use any C library that suits him,
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Erik Andersen wrote:
>
> On Fri Jul 12, 2002 at 11:42:19AM -0400, Sandy Harris wrote:
> > Does dietlibc help?
> >
>
> This is kernel space. Using any math functions is forbidden
> in kernel space,
Exactly what do you mean by "forbidden"?
Granted the kernel does not normally contain math libraries,
and that linking in a 500 meg library would be spectacularly
silly, what's wrong with using a few carefully chosen math
functions in a driver?
The kernel does not, I think, normally use floating point.
Would things break if a library that does was linked in?
Is that what you mean?
> so using dietlibc, uClibc, or anything else
> is not going to work.
Just linking in a whole library won't work, but stealing code
from a size-optimized library might.
> Moving the math stuff to userspace will
> help, at which point he can use any C library that suits him,
The guy asking the question thinks he needs math in his driver
because he needs a system that talks to blind users during the
boot process, before any userspace programs can run.
I've already suggested writing a scaled integer math library.
This should be faster than float, accurate enough for speech.
If what Erik is objecting to is floating point in the kernel,
not just any sort of math, then it avoids his objection.
Another possible solution:
Use two machines, both set to put boot messages on a serial
console and connected so that when either reboots, the other
is used as console. Do your sound in userspace (which I agree
is where it belongs). Now as long as you don't reboot both
at once (use a UPS!), you have sound for boot messages.
Sandy Harris writes:
> Erik Andersen wrote:
>> This is kernel space. Using any math functions is forbidden
>> in kernel space,
>
> Exactly what do you mean by "forbidden"?
You will corrupt the FPU registers of a user app and/or
cause an oops, assuming the kernel compiles at all.
Hi,
On Sun, 14 Jul 2002, Sandy Harris wrote:
> Use two machines, both set to put boot messages on a serial console and
> connected so that when either reboots, the other is used as console. Do
> your sound in userspace (which I agree is where it belongs). Now as long
> as you don't reboot both at once (use a UPS!), you have sound for boot
> messages.
One might set up an embedded device reading out console to do that.
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
Alan Cox <[email protected]> writes:
> > > 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?
>
> Yes. But quite a few crashes could occur before that (and have) - eg
> running a K6 kernel on a 486
>
> > 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.
>
> Serial is going away if the vendors get their way, maybe within 12 months
Well except for the debug port specification, which appears to be just
another name for a serial port.
Eric
Kirk Reiser <[email protected]> writes:
> Alan Cox <[email protected]> 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
[email protected] (Eric W. Biederman) writes:
> 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.
A small synthesizer is one of the things I am trying to work on.
After reading all the wonderful suggestions I've seen here on this
thread I'm not sure just how I'll fit it all together. Key tones to
indicate when particular events have taken place with the pc's speaker
could be very useful. We use the bell character to indicate the lilo
boot prompt currently. It could be expanded to indicate a lot of
useful events if built-in to the BIOS.
A user space program to give access to the cmos bios settings is
another feature which would be very useful. Currently there is no way
for a blind person to set up his/her own bios under the other O.S but
it could conceivably be done under Linux.
A few folks have written me suggesting the possibility of using the pc
speaker as the output for a low quality speech synth. I am skeptical
about the feasability of this but it would give everyone blind or
otherwise useful feedback possibly on systems which are headless. I
am not exactly sure yet just how small I can get a useable speech
synth. That is the whole reason for this thread in the first place.
>
> 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.
Is there an organized linuxbios project? If so, could someone give me
a pointer please.
Kirk
--
Kirk Reiser The Computer Braille Facility
e-mail: [email protected] University of Western Ontario
phone: (519) 661-3061
Kirk Reiser <[email protected]> writes:
> [email protected] (Eric W. Biederman) writes:
> >
> > 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.
>
> Is there an organized linuxbios project? If so, could someone give me
> a pointer please.
http://www.linuxbios.org
Eric
Followup to: <[email protected]>
By author: [email protected] (Eric W. Biederman)
In newsgroup: linux.dev.kernel
> >
> > Serial is going away if the vendors get their way, maybe within 12 months
>
> Well except for the debug port specification, which appears to be just
> another name for a serial port.
>
"Serial port that you have to break open your box to get to, and which
doesn't use the standard port numbers which have been in use since the
original IBM PC..."
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>