Christmas list for the kernel

Christmas list for the kernel

[Jon Smirl]

There have been recent comments about the pace of kernel development
slowing. What are the major areas that still need major work? When the
thread slows down maybe Linus will tell us what the top ten items
really are.

To get things started here's a few that I would add:

1) graphics, it is a total mess.

2) get Xen merged, virtualization will be key on the server.
Hotplugable CPUs and memory are tied up in this one.

3) Reiser4 merge, Rieser4 itself is not important, it's the new
concepts about file systems that Reiser4 brings to the kernel that are
important. Get the issues around the VFS layer sorted out so that this
can happen. We need some forward evolution in file system concepts.

4) Merge klibc and fix up the driver system so that everything is
hotplugable. This means no more need to configure drivers in the
kernel, the right drivers will just load automatically.

--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Alistair John Strachan]

On Tuesday 22 November 2005 18:31, Jon Smirl wrote:
> There have been recent comments about the pace of kernel development
> slowing. 

I doubt the diffstat from the last 6 kernel releases will tell this story.

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: Christmas list for the kernel

[Jon Smirl]

On 11/22/05, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> On Tuesday 22 November 2005 18:31, Jon Smirl wrote:
> > There have been recent comments about the pace of kernel development
> > slowing.
>
> I doubt the diffstat from the last 6 kernel releases will tell this story.

Andrew Morton said it: "He suggested this may indicate that the kernel
is nearing completion. "Famous last words, but the actual patch volume
_has_ to drop off one day," said Morton. "We have to finish this thing
one day."

http://news.zdnet.co.uk/software/linuxunix/0,39020390,39221942,00.htm


--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Andrew Morton]

Jon Smirl <jonsmirl@gmail.com> wrote:
>
> On 11/22/05, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > On Tuesday 22 November 2005 18:31, Jon Smirl wrote:
> > > There have been recent comments about the pace of kernel development
> > > slowing.
> >
> > I doubt the diffstat from the last 6 kernel releases will tell this story.
> 
> Andrew Morton said it: "He suggested this may indicate that the kernel
> is nearing completion. "Famous last words, but the actual patch volume
> _has_ to drop off one day," said Morton. "We have to finish this thing
> one day."
> 
> http://news.zdnet.co.uk/software/linuxunix/0,39020390,39221942,00.htm
> 

I was wrong, as usual.  The trend at http://www.zip.com.au/~akpm/x.jpg is,
I think, being maintained.

Re: Christmas list for the kernel

[Jon Smirl]

On 11/22/05, Andrew Morton <akpm@osdl.org> wrote:
> Jon Smirl <jonsmirl@gmail.com> wrote:
> >
> > On 11/22/05, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > On Tuesday 22 November 2005 18:31, Jon Smirl wrote:
> > > > There have been recent comments about the pace of kernel development
> > > > slowing.
> > >
> > > I doubt the diffstat from the last 6 kernel releases will tell this story.
> >
> > Andrew Morton said it: "He suggested this may indicate that the kernel
> > is nearing completion. "Famous last words, but the actual patch volume
> > _has_ to drop off one day," said Morton. "We have to finish this thing
> > one day."
> >
> > http://news.zdnet.co.uk/software/linuxunix/0,39020390,39221942,00.htm
> >
>
> I was wrong, as usual.  The trend at http://www.zip.com.au/~akpm/x.jpg is,
> I think, being maintained.

I wonder what that would look like if you pull Adrian Bunk's changes
out. He is generating thousands of lines of patches (they're good
patches but they don't add features).

--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Josh Boyer]

On 11/22/05, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/22/05, Andrew Morton <akpm@osdl.org> wrote:
> > Jon Smirl <jonsmirl@gmail.com> wrote:
> > >
> > > On 11/22/05, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > > On Tuesday 22 November 2005 18:31, Jon Smirl wrote:
> > > > > There have been recent comments about the pace of kernel development
> > > > > slowing.
> > > >
> > > > I doubt the diffstat from the last 6 kernel releases will tell this story.
> > >
> > > Andrew Morton said it: "He suggested this may indicate that the kernel
> > > is nearing completion. "Famous last words, but the actual patch volume
> > > _has_ to drop off one day," said Morton. "We have to finish this thing
> > > one day."
> > >
> > > http://news.zdnet.co.uk/software/linuxunix/0,39020390,39221942,00.htm
> > >
> >
> > I was wrong, as usual.  The trend at http://www.zip.com.au/~akpm/x.jpg is,
> > I think, being maintained.
>
> I wonder what that would look like if you pull Adrian Bunk's changes
> out. He is generating thousands of lines of patches (they're good
> patches but they don't add features).

A change is a change.  You might as well pull out the ppc{32,64} ->
powepc stuff if you're simply looking for new shiny features.  Alot of
that stuff is "just change".  Andrew's chart is tracking change, not
new features.

josh

Re: Christmas list for the kernel

[Andrew Morton]

Jon Smirl <jonsmirl@gmail.com> wrote:
>
> On 11/22/05, Andrew Morton <akpm@osdl.org> wrote:
> > Jon Smirl <jonsmirl@gmail.com> wrote:
> > >
> > > On 11/22/05, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > > > On Tuesday 22 November 2005 18:31, Jon Smirl wrote:
> > > > > There have been recent comments about the pace of kernel development
> > > > > slowing.
> > > >
> > > > I doubt the diffstat from the last 6 kernel releases will tell this story.
> > >
> > > Andrew Morton said it: "He suggested this may indicate that the kernel
> > > is nearing completion. "Famous last words, but the actual patch volume
> > > _has_ to drop off one day," said Morton. "We have to finish this thing
> > > one day."
> > >
> > > http://news.zdnet.co.uk/software/linuxunix/0,39020390,39221942,00.htm
> > >
> >
> > I was wrong, as usual.  The trend at http://www.zip.com.au/~akpm/x.jpg is,
> > I think, being maintained.
> 
> I wonder what that would look like if you pull Adrian Bunk's changes
> out. He is generating thousands of lines of patches (they're good
> patches but they don't add features).
> 

grep '^[+-]' $(grep -rl '^From:.*Bunk' patches) | wc -l
  59298

59k out of 7M lines changed.

Re: Christmas list for the kernel

[Jon Smirl]

On 11/22/05, Andrew Morton <akpm@osdl.org> wrote:
>
> grep '^[+-]' $(grep -rl '^From:.*Bunk' patches) | wc -l
>   59298
>
> 59k out of 7M lines changed.

Cool, that's a lot less than I would have thought from the amount of
lkml messages.

Can you do a magic incantation and tell us who the top top twenty
contributors are?

--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Andrew Morton]

Jon Smirl <jonsmirl@gmail.com> wrote:
>
> Can you do a magic incantation and tell us who the top top twenty
>  contributors are?

That's rather non-trivial.

One has to identify the squillion BK-era patches which are marked From:me
and look into the changelog to see if there's another ^From: in there,
indicating that they were really from someone else.  Probably using the
final From: would work for those.

Re: Christmas list for the kernel

[Bill Davidsen]

Andrew Morton wrote:
> Jon Smirl <jonsmirl@gmail.com> wrote:
> 
>>On 11/22/05, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
>>
>>>On Tuesday 22 November 2005 18:31, Jon Smirl wrote:
>>>
>>>>There have been recent comments about the pace of kernel development
>>>>slowing.
>>>
>>>I doubt the diffstat from the last 6 kernel releases will tell this story.
>>
>>Andrew Morton said it: "He suggested this may indicate that the kernel
>>is nearing completion. "Famous last words, but the actual patch volume
>>_has_ to drop off one day," said Morton. "We have to finish this thing
>>one day."
>>
>>http://news.zdnet.co.uk/software/linuxunix/0,39020390,39221942,00.htm
>>
> 
> 
> I was wrong, as usual.  The trend at http://www.zip.com.au/~akpm/x.jpg is,
> I think, being maintained.

Ah, but the percentage of lines is dropping as the kernel gets more 
bloated^H^H^H^H^H^H^featureful.

BTW: what is the baseline day zero code here? 2.6.0?
-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Christmas list for the kernel

[Andrew Morton]

Bill Davidsen <davidsen@tmr.com> wrote:
>
> > I was wrong, as usual.  The trend at http://www.zip.com.au/~akpm/x.jpg is,
>  > I think, being maintained.
> 
>  Ah, but the percentage of lines is dropping as the kernel gets more 
>  bloated^H^H^H^H^H^H^featureful.
> 
>  BTW: what is the baseline day zero code here? 2.6.0?

2.5.34 or thereabouts.

Re: Christmas list for the kernel

[Christoph Hellwig]

(5) a pony

(6) world peace

Re: Christmas list for the kernel

[Jon Smirl]

On 11/22/05, Christoph Hellwig <hch@infradead.org> wrote:
> (5) a pony
>
> (6) world peace
>

How are you going to get the pony to compile on platforms?

It may be Christmas 2008 before we the presents but it can't hurt to ask.

--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Pavel Machek]

On Út 22-11-05 14:57:06, Jon Smirl wrote:
> On 11/22/05, Christoph Hellwig <hch@infradead.org> wrote:
> > (5) a pony
> >
> > (6) world peace
> >
> 
> How are you going to get the pony to compile on platforms?

Offer him apple if he lays down, and make sure train is not coming?
There's story about traveling _in_ train with pony, so this looks easy
;-).
								Pavel
-- 
Thanks, Sharp!

Re: Christmas list for the kernel

[Pavel Machek]

Hi!

> (5) a pony

Be carefull what you ask for. Pony is rather easy to get (not as easy
as a small cat, but...) and requires quite a lot of maintanence. Ouch
and it eats lots of energy even in sleep mode, and you'd better keep it
far away from computers.

> (6) world peace

Thats easy to do, too. Unfortunately it would probably mean "lets go
back to bacterias"

								Pavel
-- 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Christmas list for the kernel

[Greg KH]

On Tue, Nov 22, 2005 at 01:31:16PM -0500, Jon Smirl wrote:
> 
> 4) Merge klibc and fix up the driver system so that everything is
> hotplugable. This means no more need to configure drivers in the
> kernel, the right drivers will just load automatically.

What driver subsystem is not hotplugable and does not have automatically
loaded modules today?

There are a few issues around PnP devices that I know of, and PCMCIA
needs some seriously love, but other than that I think we are well off.
Or am I missing something big here?

thanks,

greg k-h

Re: Christmas list for the kernel

[Jon Smirl]

On 11/22/05, Greg KH <greg@kroah.com> wrote:
> On Tue, Nov 22, 2005 at 01:31:16PM -0500, Jon Smirl wrote:
> >
> > 4) Merge klibc and fix up the driver system so that everything is
> > hotplugable. This means no more need to configure drivers in the
> > kernel, the right drivers will just load automatically.
>
> What driver subsystem is not hotplugable and does not have automatically
> loaded modules today?

All of the legacy stuff - VGA, Vesafb, PS2, serial, parallel,
joystick, floppy, gameport, etc. Those drivers could be in initramfs
and only load if the hardware is found. Most of these legacy devices
have poor sysfs support too. Also, it's not just x86 legacy device all
of the platforms have them.

Currently you have to compile most of this stuff into the kernel.

> There are a few issues around PnP devices that I know of, and PCMCIA
> needs some seriously love, but other than that I think we are well off.
> Or am I missing something big here?
>
> thanks,
>
> greg k-h
>


--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Kasper Sandberg]

On Tue, 2005-11-22 at 16:13 -0500, Jon Smirl wrote:
> On 11/22/05, Greg KH <greg@kroah.com> wrote:
> > On Tue, Nov 22, 2005 at 01:31:16PM -0500, Jon Smirl wrote:
> > >
> > > 4) Merge klibc and fix up the driver system so that everything is
> > > hotplugable. This means no more need to configure drivers in the
> > > kernel, the right drivers will just load automatically.
> >
> > What driver subsystem is not hotplugable and does not have automatically
> > loaded modules today?
> 
> All of the legacy stuff - VGA, Vesafb, PS2, serial, parallel,
> joystick, floppy, gameport, etc. Those drivers could be in initramfs
> and only load if the hardware is found. Most of these legacy devices
> have poor sysfs support too. Also, it's not just x86 legacy device all
> of the platforms have them.
> 
> Currently you have to compile most of this stuff into the kernel.
forgive my ignorance, but whats stopping you from doing this now?
> 
> > There are a few issues around PnP devices that I know of, and PCMCIA
> > needs some seriously love, but other than that I think we are well off.
> > Or am I missing something big here?
> >
> > thanks,
> >
> > greg k-h
> >
> 
> 
> --
> Jon Smirl
> jonsmirl@gmail.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Christmas list for the kernel

[Jon Smirl]

On 11/22/05, Kasper Sandberg <lkml@metanurb.dk> wrote:
> > Currently you have to compile most of this stuff into the kernel.
> forgive my ignorance, but whats stopping you from doing this now?

It would be better if all of the legacy drivers could exist on
initramfs and only be loaded if the actual hardware is present. With
the current code someone like Redhat has to compile all of the legacy
support into their distribution kernel. That code will be present even
on new systems that don't have the hardware.

An example of this is that the serial driver is hard coded to report
four legacy serial ports when my system physically only has two. I
have to change a #define and recompile the kernel to change this.

The goal should be able to build something like Knoppix without
Knoppix needing any device probing scripts. Linux is 90% of the way
there but not 100% yet.

X is also part of the problem. Even if the kernel nicely identifies
all of the video hardware and input devices, X ignores this info and
looks for everything again anyway. In a more friendly system X would
use the info the kernel provides and automatically configure itself
for the devices present or hotplugged. You could get rid of your
xorg.cong file in this model.

--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[David Lang]

On Tue, 22 Nov 2005, Jon Smirl wrote:

> On 11/22/05, Kasper Sandberg <lkml@metanurb.dk> wrote:
>>> Currently you have to compile most of this stuff into the kernel.
>> forgive my ignorance, but whats stopping you from doing this now?
>
> It would be better if all of the legacy drivers could exist on
> initramfs and only be loaded if the actual hardware is present. With
> the current code someone like Redhat has to compile all of the legacy
> support into their distribution kernel. That code will be present even
> on new systems that don't have the hardware.
>
> An example of this is that the serial driver is hard coded to report
> four legacy serial ports when my system physically only has two. I
> have to change a #define and recompile the kernel to change this.
>
> The goal should be able to build something like Knoppix without
> Knoppix needing any device probing scripts. Linux is 90% of the way
> there but not 100% yet.

umm, don't you realize that this just means that the device probing 
scripts go on the initrd? the kernel doesn't magicly decide which drivers 
to load, it uses scripts. especially with legacy and ISA devices there are 
no safe way to probe for them.

> X is also part of the problem. Even if the kernel nicely identifies
> all of the video hardware and input devices, X ignores this info and
> looks for everything again anyway. In a more friendly system X would
> use the info the kernel provides and automatically configure itself
> for the devices present or hotplugged. You could get rid of your
> xorg.cong file in this model.

this needs to be sent as a suggestion to xorg, but since they run on 
things besides Linux don't expect them to eliminate the config file 
(besides, how else do you override the defaults when you need to)

David Lang

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

Re: Christmas list for the kernel

[Anton Altaparmakov]

On Tue, 22 Nov 2005, Jon Smirl wrote:
> On 11/22/05, Kasper Sandberg <lkml@metanurb.dk> wrote:
> > > Currently you have to compile most of this stuff into the kernel.
> > forgive my ignorance, but whats stopping you from doing this now?
> 
> It would be better if all of the legacy drivers could exist on
> initramfs and only be loaded if the actual hardware is present. With
> the current code someone like Redhat has to compile all of the legacy
> support into their distribution kernel. That code will be present even
> on new systems that don't have the hardware.
> 
> An example of this is that the serial driver is hard coded to report
> four legacy serial ports when my system physically only has two. I
> have to change a #define and recompile the kernel to change this.
> 
> The goal should be able to build something like Knoppix without
> Knoppix needing any device probing scripts. Linux is 90% of the way
> there but not 100% yet.
> 
> X is also part of the problem. Even if the kernel nicely identifies
> all of the video hardware and input devices, X ignores this info and
> looks for everything again anyway. In a more friendly system X would
> use the info the kernel provides and automatically configure itself
> for the devices present or hotplugged. You could get rid of your
> xorg.cong file in this model.

Note quite.  You would still need it (or other means) to configure for 
example what screen resolutions and what modes to allow and things like 
that.  Also which devices are core pointer/keyboard and which extra and 
also some devices are supported in userspace and not in the kernel for 
which you need to configure them there.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: Christmas list for the kernel

[Alan Cox]

On Maw, 2005-11-22 at 16:41 -0500, Jon Smirl wrote:
> An example of this is that the serial driver is hard coded to report
> four legacy serial ports when my system physically only has two. I
> have to change a #define and recompile the kernel to change this.

It does an autodetect sequence to find the ports. If it reports ttyS0-S3
your system probably has them, they may just not be wired to external
ports and that is kinda tricky to autodetect

> looks for everything again anyway. In a more friendly system X would
> use the info the kernel provides and automatically configure itself
> for the devices present or hotplugged. You could get rid of your
> xorg.cong file in this model.


Not really as half of xorg.conf is preferences

Re: Christmas list for the kernel

[Jon Smirl]

On 11/22/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2005-11-22 at 16:41 -0500, Jon Smirl wrote:
> > An example of this is that the serial driver is hard coded to report
> > four legacy serial ports when my system physically only has two. I
> > have to change a #define and recompile the kernel to change this.
>
> It does an autodetect sequence to find the ports. If it reports ttyS0-S3
> your system probably has them, they may just not be wired to external
> ports and that is kinda tricky to autodetect

The ports really aren't there. If we had a driver for the LPC chip it
would see that the chip only implemented two ports.  On modern
hardware a driver for LPC/super IO chips might be enough to do all of
the needed legacy detection.


>
> > looks for everything again anyway. In a more friendly system X would
> > use the info the kernel provides and automatically configure itself
> > for the devices present or hotplugged. You could get rid of your
> > xorg.cong file in this model.
>
>
> Not really as half of xorg.conf is preferences
>
>


--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Russell King]

On Tue, Nov 22, 2005 at 06:56:30PM -0500, Jon Smirl wrote:
> On 11/22/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > On Maw, 2005-11-22 at 16:41 -0500, Jon Smirl wrote:
> > > An example of this is that the serial driver is hard coded to report
> > > four legacy serial ports when my system physically only has two. I
> > > have to change a #define and recompile the kernel to change this.
> >
> > It does an autodetect sequence to find the ports. If it reports ttyS0-S3
> > your system probably has them, they may just not be wired to external
> > ports and that is kinda tricky to autodetect
> 
> The ports really aren't there. If we had a driver for the LPC chip it
> would see that the chip only implemented two ports.  On modern
> hardware a driver for LPC/super IO chips might be enough to do all of
> the needed legacy detection.

If the serial driver detects a port at a particular address, the
hardware or something which behaves very much like a serial port
is there.

However, as far as I recall, you've never reported this as a problem.
Care to put something in bugzilla or start a new thread?  Starting
with the entire kernel messages with the DEBUG_AUTOCONF stuff enabled
in the 8250 driver would probably be good.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Christmas list for the kernel

[Bill Davidsen]

Alan Cox wrote:
> On Maw, 2005-11-22 at 16:41 -0500, Jon Smirl wrote:
> 
>>An example of this is that the serial driver is hard coded to report
>>four legacy serial ports when my system physically only has two. I
>>have to change a #define and recompile the kernel to change this.
> 
> 
> It does an autodetect sequence to find the ports. If it reports ttyS0-S3
> your system probably has them, they may just not be wired to external
> ports and that is kinda tricky to autodetect
> 
> 
>>looks for everything again anyway. In a more friendly system X would
>>use the info the kernel provides and automatically configure itself
>>for the devices present or hotplugged. You could get rid of your
>>xorg.cong file in this model.
> 
> 
> 
> Not really as half of xorg.conf is preferences
> 
I think what he wants is that you could have preferences, but that 
something functional if not optimal would be selected. What would 
actually be useful is if the kernel would provide a small report of the 
video hardware in some useful format, such that (example) 
/proc/somthing/video_config could be included in the xorg.conf.

Yes, a number of distributions build the xorg.conf at install time, 
although it's sometimes wrong and can't readily be made right after the 
fact. And really should come from kernel info found at boot time, I believe.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Christmas list for the kernel

[Denis Vlasenko]

On Tuesday 22 November 2005 23:41, Jon Smirl wrote:
> On 11/22/05, Kasper Sandberg <lkml@metanurb.dk> wrote:
> > > Currently you have to compile most of this stuff into the kernel.
> > forgive my ignorance, but whats stopping you from doing this now?
> 
> It would be better if all of the legacy drivers could exist on
> initramfs and only be loaded if the actual hardware is present. With
> the current code someone like Redhat has to compile all of the legacy
> support into their distribution kernel. That code will be present even
> on new systems that don't have the hardware.
> 
> An example of this is that the serial driver is hard coded to report
> four legacy serial ports when my system physically only has two. I
> have to change a #define and recompile the kernel to change this.

> The goal should be able to build something like Knoppix without
> Knoppix needing any device probing scripts. Linux is 90% of the way
> there but not 100% yet.
 
It's not such a pressing need IMO. This stuff works, doesn't
need a lot of maintenance, is not too big code size wise, so why
should it be converted ASAP?

As discussed on "PCI core patch" thread, getting specs from
hardware vendors for new stuff is getting harder. When one suddenly
discovers than [s]he cannot run X on shiny new notebook -
_this_ is a serious problem.

> X is also part of the problem. Even if the kernel nicely identifies
> all of the video hardware and input devices, X ignores this info and
> looks for everything again anyway. In a more friendly system X would
> use the info the kernel provides and automatically configure itself
> for the devices present or hotplugged. You could get rid of your
> xorg.cong file in this model.
--
vda

Re: Christmas list for the kernel

[Vojtech Pavlik]

On Tue, Nov 22, 2005 at 04:41:02PM -0500, Jon Smirl wrote:
> On 11/22/05, Kasper Sandberg <lkml@metanurb.dk> wrote:
> > > Currently you have to compile most of this stuff into the kernel.
> > forgive my ignorance, but whats stopping you from doing this now?
> 
> It would be better if all of the legacy drivers could exist on
> initramfs and only be loaded if the actual hardware is present. With
> the current code someone like Redhat has to compile all of the legacy
> support into their distribution kernel. That code will be present even
> on new systems that don't have the hardware.
> 
> An example of this is that the serial driver is hard coded to report
> four legacy serial ports when my system physically only has two. I
> have to change a #define and recompile the kernel to change this.

Interesting. Something goes wrong on your system - I have only a single
serial port on my machine and it's correctly identified by PnP, with no
other ports showing up.

> The goal should be able to build something like Knoppix without
> Knoppix needing any device probing scripts. Linux is 90% of the way
> there but not 100% yet.
> 
> X is also part of the problem. Even if the kernel nicely identifies
> all of the video hardware and input devices, X ignores this info and
> looks for everything again anyway. In a more friendly system X would
> use the info the kernel provides and automatically configure itself
> for the devices present or hotplugged. You could get rid of your
> xorg.cong file in this model.
 
There is always the hope. :)

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Christmas list for the kernel

[Gene Heskett]

On Wednesday 23 November 2005 09:44, Vojtech Pavlik wrote:
>On Tue, Nov 22, 2005 at 04:41:02PM -0500, Jon Smirl wrote:
>> On 11/22/05, Kasper Sandberg <lkml@metanurb.dk> wrote:
>> > > Currently you have to compile most of this stuff into the kernel.
>> >
>> > forgive my ignorance, but whats stopping you from doing this now?
>>
>> It would be better if all of the legacy drivers could exist on
>> initramfs and only be loaded if the actual hardware is present. With
>> the current code someone like Redhat has to compile all of the legacy
>> support into their distribution kernel. That code will be present
>> even on new systems that don't have the hardware.
>>
>> An example of this is that the serial driver is hard coded to report
>> four legacy serial ports when my system physically only has two. I
>> have to change a #define and recompile the kernel to change this.
>
>Interesting. Something goes wrong on your system - I have only a single
>serial port on my machine and it's correctly identified by PnP, with no
>other ports showing up.

Now that you mention it:

In my case, I've been getting 6 serial ports reported at boot time
for most of the 2.6.x kernel series.  They are just repeats of ttyS0 and
ttyS1, including the ttyS0/1 designation.

>From my last dmesg while booting 2.6.14.2:

serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

I had posted about this before, but it was apparently lost in the lists
general noise.   I do use both ports here, and they are working, so I
hadn't pursued it further.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.36% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: Christmas list for the kernel

[Russell King]

On Wed, Nov 23, 2005 at 12:21:27PM -0500, Gene Heskett wrote:
> serio: i8042 AUX port at 0x60,0x64 irq 12
> serio: i8042 KBD port at 0x60,0x64 irq 1
> Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing enabled
> ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> 
> I had posted about this before, but it was apparently lost in the lists
> general noise.   I do use both ports here, and they are working, so I
> hadn't pursued it further.

So has the answer.  I've answered this twice today, and several times
in bugzilla.  It's one reason why these lines are now prefixed with
"serial8250" - that being the struct device to which they end up being
associated with.  (defaulting to "serial8250" for power management
purposes if no other exists.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Christmas list for the kernel

[Bill Davidsen]

Russell King wrote:
> On Wed, Nov 23, 2005 at 12:21:27PM -0500, Gene Heskett wrote:
> 
>>serio: i8042 AUX port at 0x60,0x64 irq 12
>>serio: i8042 KBD port at 0x60,0x64 irq 1
>>Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing enabled
>>ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>>ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
>>ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>>ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
>>ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>>ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
>>
>>I had posted about this before, but it was apparently lost in the lists
>>general noise.   I do use both ports here, and they are working, so I
>>hadn't pursued it further.
> 
> 
> So has the answer.  I've answered this twice today, and several times
> in bugzilla.  It's one reason why these lines are now prefixed with
> "serial8250" - that being the struct device to which they end up being
> associated with.  (defaulting to "serial8250" for power management
> purposes if no other exists.)
> 
Am I being slow? These messages are repeated three times because they 
are prefixed? 2.6.14 also presented the info several times:

PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:MICE] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
pnp: the driver 'serial' has been registered
pnp: match found with the PnP device '00:09' and the driver 'serial'
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

I don't have a 2.6.15 flavor system handy at the moment, my bleeding 
edge system is being OpenSolaris today :-( Is there value to having this 
apparently duplicate information displayed? It looks like babble, or 
worse some init code being called multiple times, if this is as it 
should be, or useful to some developer fine, I just don't quite read 
that into your answer saying it's prefixed. And I don't see serial8250 
in Gene's post or my dmesg.
-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Christmas list for the kernel

[Alan Cox]

On Maw, 2005-11-22 at 16:13 -0500, Jon Smirl wrote:
> All of the legacy stuff - VGA, Vesafb, PS2, serial, parallel,

PCI Parallel and serial hotplug
PS2 hotplugs if you've got hotpluggable PS2 - I've even used this
Most Joysticks hotplug
Gameports mostly hotplug
VESAfb is by definition not hotplug capable
VGA hotplug we don't do but you can load the module.


Alan

Re: Christmas list for the kernel

[Jon Smirl]

On 11/22/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2005-11-22 at 16:13 -0500, Jon Smirl wrote:
> > All of the legacy stuff - VGA, Vesafb, PS2, serial, parallel,
>
> PCI Parallel and serial hotplug
> PS2 hotplugs if you've got hotpluggable PS2 - I've even used this
> Most Joysticks hotplug
> Gameports mostly hotplug
> VESAfb is by definition not hotplug capable
> VGA hotplug we don't do but you can load the module.

The devices that plug into the ports hotplug, but the existence of the
ports themselves does not autodetect/hotplug at boot time.

>
>
> Alan
>
>


--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Alistair John Strachan]

On Tuesday 22 November 2005 23:58, Jon Smirl wrote:
> On 11/22/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > On Maw, 2005-11-22 at 16:13 -0500, Jon Smirl wrote:
> > > All of the legacy stuff - VGA, Vesafb, PS2, serial, parallel,
> >
> > PCI Parallel and serial hotplug
> > PS2 hotplugs if you've got hotpluggable PS2 - I've even used this
> > Most Joysticks hotplug
> > Gameports mostly hotplug
> > VESAfb is by definition not hotplug capable
> > VGA hotplug we don't do but you can load the module.
>
> The devices that plug into the ports hotplug, but the existence of the
> ports themselves does not autodetect/hotplug at boot time.

I think this is referred to as "cold plug".

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: Christmas list for the kernel

[Alan Cox]

On Maw, 2005-11-22 at 18:58 -0500, Jon Smirl wrote:
> On 11/22/05, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > On Maw, 2005-11-22 at 16:13 -0500, Jon Smirl wrote:
> > > All of the legacy stuff - VGA, Vesafb, PS2, serial, parallel,
> >
> > PCI Parallel and serial hotplug
> > PS2 hotplugs if you've got hotpluggable PS2 - I've even used this
> > Most Joysticks hotplug
> > Gameports mostly hotplug
> > VESAfb is by definition not hotplug capable
> > VGA hotplug we don't do but you can load the module.
> 
> The devices that plug into the ports hotplug, but the existence of the
> ports themselves does not autodetect/hotplug at boot time.

Untrue for PS2 ports, most modern joystick (old joystick has not
hotplug) and VGA. Also untrue for serial/parallel IFF your udev scripts
are right.

Re: Christmas list for the kernel

[Vojtech Pavlik]

On Tue, Nov 22, 2005 at 04:13:01PM -0500, Jon Smirl wrote:

> On 11/22/05, Greg KH <greg@kroah.com> wrote:
> > On Tue, Nov 22, 2005 at 01:31:16PM -0500, Jon Smirl wrote:
> > >
> > > 4) Merge klibc and fix up the driver system so that everything is
> > > hotplugable. This means no more need to configure drivers in the
> > > kernel, the right drivers will just load automatically.
> >
> > What driver subsystem is not hotplugable and does not have automatically
> > loaded modules today?
> 
> All of the legacy stuff - VGA, Vesafb, PS2, serial, parallel,
> joystick, floppy, gameport, etc.

You can remove these from the list:

ps/2 and serial (for input devices) use the 'serio' layer, which does
have automatic loading.

gameport is missing, but planned. Unfortunately you can't probe for
joysticks before you load the specific modules, so it simply will have
to load all available drivers. On the other hand, gameports are a dying
breed, replaced by USB, which is good.

And the others:

VGA drivers are autoloaded by the PCI subsystem.

VESAfb can't ever be autoloaded.

serial, parallel, gameport, etc are using the PnP subsystem and will be
autoloaded if ACPIPnP reports these devices.

And floppy, well, I think it isn't using ACPIPnP but possibly could ...

> Those drivers could be in initramfs
> and only load if the hardware is found. Most of these legacy devices
> have poor sysfs support too. Also, it's not just x86 legacy device all
> of the platforms have them.

The hardware is often found only by the driver, like in the joystick
case. Hopefully ACPIPnP will list all the devices ...

> Currently you have to compile most of this stuff into the kernel.

You don't.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Christmas list for the kernel

[Jon Smirl]

My system has:
2 serial
1 parallel
1 floppy
1 gameport
1 joystick
2 PS/2
2 VGA
1 HPET
1 RTC

In /sys/bus/platform/devices I see this:
floppy.0
i8042
serial8250
shouldn't there be entries for all of the legacy devices?

In /dev
fd0
fd/0
fd/1
fd/2
fd/3
floppy
ttyS0
ttyS1
ttyS2
ttyS3
parport0
parport1
parport2
parport3
lp0
lp1
lp2
lp3
hpet
not sure what serio0/.1 appear as

I don't have joystick/game modules loaded.
Lot's of extra device nodes
We need to start making VGA devices

Plus I have 64 tty devices. Couldn't the tty devices be created
dynamically as they are consumed? Same for the loop and ram devices?

Because /sys isn't right the right devices don't show up in HAL.

--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Russell King]

On Wed, Nov 23, 2005 at 09:43:58AM -0500, Jon Smirl wrote:
> My system has:
> 2 serial
> 
> In /sys/bus/platform/devices I see this:
> serial8250
> shouldn't there be entries for all of the legacy devices?
> 
> In /dev
> ttyS0
> ttyS1
> ttyS2
> ttyS3

You're basically confused about serial ports.  The kernel serial devices
whether or not hardware is found, to allow programs such as setserial to
function.

If you disagree with that, there'll be an equal number of people who
have serial cards that need setserial who will in turn disagree with
you.

> Plus I have 64 tty devices. Couldn't the tty devices be created
> dynamically as they are consumed? Same for the loop and ram devices?

You do realise that the dynamic device creation for those 64 console
devices is done via the console device being _opened_ by userspace?

Hence, if the device doesn't exist in userspace, it can't be created
for userspace to open it to create the device via udev.  Have you
noticed a catch-22 with that statement?

Note that with tty devices, the tty layer has to be told the number
of devices you want to support when you first register your driver.
You're fixed to that maximum number from that point on, until you
unregister *all* your ports and driver.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Christmas list for the kernel

[Jon Smirl]

On 11/23/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > Plus I have 64 tty devices. Couldn't the tty devices be created
> > dynamically as they are consumed? Same for the loop and ram devices?
>
> You do realise that the dynamic device creation for those 64 console
> devices is done via the console device being _opened_ by userspace?
>
> Hence, if the device doesn't exist in userspace, it can't be created
> for userspace to open it to create the device via udev.  Have you
> noticed a catch-22 with that statement?

Couldn't we create tty0-3 and then when one of those gets opened,
create tty4, and so on? Then there would always be two or three more
tty devices than there are open tty devices.

>
> Note that with tty devices, the tty layer has to be told the number
> of devices you want to support when you first register your driver.
> You're fixed to that maximum number from that point on, until you
> unregister *all* your ports and driver.
>
> --
> Russell King
>  Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
>  maintainer of:  2.6 Serial core
>


--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Marc Koschewski]

* Jon Smirl <jonsmirl@gmail.com> [2005-11-23 10:12:58 -0500]:

> On 11/23/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > > Plus I have 64 tty devices. Couldn't the tty devices be created
> > > dynamically as they are consumed? Same for the loop and ram devices?
> >
> > You do realise that the dynamic device creation for those 64 console
> > devices is done via the console device being _opened_ by userspace?
> >
> > Hence, if the device doesn't exist in userspace, it can't be created
> > for userspace to open it to create the device via udev.  Have you
> > noticed a catch-22 with that statement?
> 
> Couldn't we create tty0-3 and then when one of those gets opened,
> create tty4, and so on? Then there would always be two or three more
> tty devices than there are open tty devices.
> 

How does that work when you ie. have tty0, tty1, tty2, tty3 per default,
open tty4, tty5, tty6 and the close tty4? And what if you then open
another? Will it be tty4 oder tty7? If so, what if the maximum numer is
reached even if only 3 ttys are left open?

Re: Christmas list for the kernel

[Russell King]

On Wed, Nov 23, 2005 at 04:56:50PM +0100, Marc Koschewski wrote:
> * Jon Smirl <jonsmirl@gmail.com> [2005-11-23 10:12:58 -0500]:
> 
> > On 11/23/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > > > Plus I have 64 tty devices. Couldn't the tty devices be created
> > > > dynamically as they are consumed? Same for the loop and ram devices?
> > >
> > > You do realise that the dynamic device creation for those 64 console
> > > devices is done via the console device being _opened_ by userspace?
> > >
> > > Hence, if the device doesn't exist in userspace, it can't be created
> > > for userspace to open it to create the device via udev.  Have you
> > > noticed a catch-22 with that statement?
> > 
> > Couldn't we create tty0-3 and then when one of those gets opened,
> > create tty4, and so on? Then there would always be two or three more
> > tty devices than there are open tty devices.
> > 
> 
> How does that work when you ie. have tty0, tty1, tty2, tty3 per default,
> open tty4, tty5, tty6 and the close tty4? And what if you then open
> another? Will it be tty4 oder tty7? If so, what if the maximum numer is
> reached even if only 3 ttys are left open?

And what if you want consoles on 1-6 and syslog messages on tty12?

Also, remember that when init starts the gettys on tty1-N, they're
started in parallel, so you will end up with the gettys opening those
in a random order.

Therefore, you can not infer that if tty1 has been opened, tty2 will
be next, followed by tty3 and then tty4, etc.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Christmas list for the kernel

[Jon Smirl]

On 11/23/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> On Wed, Nov 23, 2005 at 04:56:50PM +0100, Marc Koschewski wrote:
> > * Jon Smirl <jonsmirl@gmail.com> [2005-11-23 10:12:58 -0500]:
> >
> > > On 11/23/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > > > > Plus I have 64 tty devices. Couldn't the tty devices be created
> > > > > dynamically as they are consumed? Same for the loop and ram devices?
> > > >
> > > > You do realise that the dynamic device creation for those 64 console
> > > > devices is done via the console device being _opened_ by userspace?
> > > >
> > > > Hence, if the device doesn't exist in userspace, it can't be created
> > > > for userspace to open it to create the device via udev.  Have you
> > > > noticed a catch-22 with that statement?
> > >
> > > Couldn't we create tty0-3 and then when one of those gets opened,
> > > create tty4, and so on? Then there would always be two or three more
> > > tty devices than there are open tty devices.
> > >
> >
> > How does that work when you ie. have tty0, tty1, tty2, tty3 per default,
> > open tty4, tty5, tty6 and the close tty4? And what if you then open
> > another? Will it be tty4 oder tty7? If so, what if the maximum numer is
> > reached even if only 3 ttys are left open?
>
> And what if you want consoles on 1-6 and syslog messages on tty12?
>
> Also, remember that when init starts the gettys on tty1-N, they're
> started in parallel, so you will end up with the gettys opening those
> in a random order.
>
> Therefore, you can not infer that if tty1 has been opened, tty2 will
> be next, followed by tty3 and then tty4, etc.

Before everyone gets excited, I realize that all of this has
historical implications. But that doesn't mean we can't discuss
possible future alternative solutions.

Thinking about this for a while it seems to me that the problem is
that the various apps (init, syslog) etc should not have a tty name as
part of their command line parameters. Instead these apps could use
ptys instead. Ptys would solve all of the race problems too.

Is there any good reason (other than history) for using a device node
name (tty0, etc) instead of some other naming scheme if names are
needed at all?

If init, syslog, etc can be converted to ptys, do we need ttys? Xterms
use ptys I don't notice that they aren't connect to a fix tty name.
The virtual consoles would still be 0,1,2 but do they have to be
hooked to tty0, 1, 2 instead of a pty?

--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Vojtech Pavlik]

On Wed, Nov 23, 2005 at 11:37:23AM -0500, Jon Smirl wrote:

> Before everyone gets excited, I realize that all of this has
> historical implications. But that doesn't mean we can't discuss
> possible future alternative solutions.
> 
> Thinking about this for a while it seems to me that the problem is
> that the various apps (init, syslog) etc should not have a tty name as
> part of their command line parameters. Instead these apps could use
> ptys instead. Ptys would solve all of the race problems too.
> 
> Is there any good reason (other than history) for using a device node
> name (tty0, etc) instead of some other naming scheme if names are
> needed at all?
> 
> If init, syslog, etc can be converted to ptys, do we need ttys? Xterms
> use ptys I don't notice that they aren't connect to a fix tty name.
> The virtual consoles would still be 0,1,2 but do they have to be
> hooked to tty0, 1, 2 instead of a pty?
 
The basic difference between a pty and tty is that a pty connects to a
program (that created it by opening the ptmx node, for example xterm or
ssh) on the other end, while a tty connects to the kernel doing all the
character drawing in the framebuffer.

You can't easily use one instead of the other, they're very different
beasts.

Of course, a way to use a pty would be to have the console
implementation in userspace.

The fact that no program is on the other end of a tty is also the reason
why they cannot be created dynamically like ptys, there is noone to open
a "ttmx" to create the ttys.

Hence, the device nodes are pre-created by the kernel, while the real
devices are only created on open.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Christmas list for the kernel

[Jon Smirl]

On 11/23/05, Vojtech Pavlik <vojtech@suse.cz> wrote:
> On Wed, Nov 23, 2005 at 11:37:23AM -0500, Jon Smirl wrote:
>
> > Before everyone gets excited, I realize that all of this has
> > historical implications. But that doesn't mean we can't discuss
> > possible future alternative solutions.
> >
> > Thinking about this for a while it seems to me that the problem is
> > that the various apps (init, syslog) etc should not have a tty name as
> > part of their command line parameters. Instead these apps could use
> > ptys instead. Ptys would solve all of the race problems too.
> >
> > Is there any good reason (other than history) for using a device node
> > name (tty0, etc) instead of some other naming scheme if names are
> > needed at all?
> >
> > If init, syslog, etc can be converted to ptys, do we need ttys? Xterms
> > use ptys I don't notice that they aren't connect to a fix tty name.
> > The virtual consoles would still be 0,1,2 but do they have to be
> > hooked to tty0, 1, 2 instead of a pty?
>
> The basic difference between a pty and tty is that a pty connects to a
> program (that created it by opening the ptmx node, for example xterm or
> ssh) on the other end, while a tty connects to the kernel doing all the
> character drawing in the framebuffer.
>
> You can't easily use one instead of the other, they're very different
> beasts.
>
> Of course, a way to use a pty would be to have the console
> implementation in userspace.
>
> The fact that no program is on the other end of a tty is also the reason
> why they cannot be created dynamically like ptys, there is noone to open
> a "ttmx" to create the ttys.
>
> Hence, the device nodes are pre-created by the kernel, while the real
> devices are only created on open.

I forgot about the kernel vs user space termination issue.

One solution would be to not create the tty nodes and instead modify
init, syslog to mknod the node before using it.

Another would be to have a little user space daemon that listened to
the pty creation, and then mknod the tty nodes as need and pipe the
data through. That would be a first step to moving to a user space
console implementation.

I see now that the 64 tty devices really are there and are provided by
the kernel. It's just that hardly anyone uses all of them and they
clutter up /dev.

--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Marc Koschewski]

* Jon Smirl <jonsmirl@gmail.com> [2005-11-23 11:59:27 -0500]:

> On 11/23/05, Vojtech Pavlik <vojtech@suse.cz> wrote:
> > On Wed, Nov 23, 2005 at 11:37:23AM -0500, Jon Smirl wrote:
> >
> > > Before everyone gets excited, I realize that all of this has
> > > historical implications. But that doesn't mean we can't discuss
> > > possible future alternative solutions.
> > >
> > > Thinking about this for a while it seems to me that the problem is
> > > that the various apps (init, syslog) etc should not have a tty name as
> > > part of their command line parameters. Instead these apps could use
> > > ptys instead. Ptys would solve all of the race problems too.
> > >
> > > Is there any good reason (other than history) for using a device node
> > > name (tty0, etc) instead of some other naming scheme if names are
> > > needed at all?
> > >
> > > If init, syslog, etc can be converted to ptys, do we need ttys? Xterms
> > > use ptys I don't notice that they aren't connect to a fix tty name.
> > > The virtual consoles would still be 0,1,2 but do they have to be
> > > hooked to tty0, 1, 2 instead of a pty?
> >
> > The basic difference between a pty and tty is that a pty connects to a
> > program (that created it by opening the ptmx node, for example xterm or
> > ssh) on the other end, while a tty connects to the kernel doing all the
> > character drawing in the framebuffer.
> >
> > You can't easily use one instead of the other, they're very different
> > beasts.
> >
> > Of course, a way to use a pty would be to have the console
> > implementation in userspace.
> >
> > The fact that no program is on the other end of a tty is also the reason
> > why they cannot be created dynamically like ptys, there is noone to open
> > a "ttmx" to create the ttys.
> >
> > Hence, the device nodes are pre-created by the kernel, while the real
> > devices are only created on open.
> 
> I forgot about the kernel vs user space termination issue.
> 
> One solution would be to not create the tty nodes and instead modify
> init, syslog to mknod the node before using it.
> 
> Another would be to have a little user space daemon that listened to
> the pty creation, and then mknod the tty nodes as need and pipe the
> data through. That would be a first step to moving to a user space
> console implementation.

Shouldn't this be udev then? I hear people scream when 'some deamon'
created a device in /dev. Was it udev? Was is 'ttydevd'? Even
'ondemanddevd'?

Marc

Re: Christmas list for the kernel

[Jon Smirl]

On 11/23/05, Marc Koschewski <marc@osknowledge.org> wrote:
> * Jon Smirl <jonsmirl@gmail.com> [2005-11-23 11:59:27 -0500]:
> > Another would be to have a little user space daemon that listened to
> > the pty creation, and then mknod the tty nodes as need and pipe the
> > data through. That would be a first step to moving to a user space
> > console implementation.
>
> Shouldn't this be udev then? I hear people scream when 'some deamon'
> created a device in /dev. Was it udev? Was is 'ttydevd'? Even
> 'ondemanddevd'?

udev listens to /sys/class for it's indications on when to create a node.

The tty daemon would need to listen for pty creation to tell it when
to create a node. Then after it creates the node it needs to maintain
a pipe between the pty and tty. This is a lot different than what udev
does.

--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Vojtech Pavlik]

On Wed, Nov 23, 2005 at 12:13:06PM -0500, Jon Smirl wrote:

> On 11/23/05, Marc Koschewski <marc@osknowledge.org> wrote:
> > * Jon Smirl <jonsmirl@gmail.com> [2005-11-23 11:59:27 -0500]:
> > > Another would be to have a little user space daemon that listened to
> > > the pty creation, and then mknod the tty nodes as need and pipe the
> > > data through. That would be a first step to moving to a user space
> > > console implementation.
> >
> > Shouldn't this be udev then? I hear people scream when 'some deamon'
> > created a device in /dev. Was it udev? Was is 'ttydevd'? Even
> > 'ondemanddevd'?
> 
> udev listens to /sys/class for it's indications on when to create a node.
> 
> The tty daemon would need to listen for pty creation to tell it when
> to create a node. Then after it creates the node it needs to maintain
> a pipe between the pty and tty. This is a lot different than what udev
> does.
 
Except for that it wouldn't work for a reason I've described earlier, it
could well be launched from udev.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Christmas list for the kernel

[Marc Koschewski]

* Jon Smirl <jonsmirl@gmail.com> [2005-11-23 12:13:06 -0500]:

> On 11/23/05, Marc Koschewski <marc@osknowledge.org> wrote:
> > * Jon Smirl <jonsmirl@gmail.com> [2005-11-23 11:59:27 -0500]:
> > > Another would be to have a little user space daemon that listened to
> > > the pty creation, and then mknod the tty nodes as need and pipe the
> > > data through. That would be a first step to moving to a user space
> > > console implementation.
> >
> > Shouldn't this be udev then? I hear people scream when 'some deamon'
> > created a device in /dev. Was it udev? Was is 'ttydevd'? Even
> > 'ondemanddevd'?
> 
> udev listens to /sys/class for it's indications on when to create a node.
> 
> The tty daemon would need to listen for pty creation to tell it when
> to create a node. Then after it creates the node it needs to maintain
> a pipe between the pty and tty. This is a lot different than what udev
> does.

I didn't mean to _say_ that it's the same. I just meant to _ask_ how you
are going to tell the users which daemon created what devices in /dev. I
would rather do the 'udev appoach' then (extend it in other words) so
that there's just one daemon that creates device nodes.

Marc

Re: Christmas list for the kernel

[Vojtech Pavlik]

On Wed, Nov 23, 2005 at 11:59:27AM -0500, Jon Smirl wrote:
> On 11/23/05, Vojtech Pavlik <vojtech@suse.cz> wrote:
> > On Wed, Nov 23, 2005 at 11:37:23AM -0500, Jon Smirl wrote:
> >
> > > Before everyone gets excited, I realize that all of this has
> > > historical implications. But that doesn't mean we can't discuss
> > > possible future alternative solutions.
> > >
> > > Thinking about this for a while it seems to me that the problem is
> > > that the various apps (init, syslog) etc should not have a tty name as
> > > part of their command line parameters. Instead these apps could use
> > > ptys instead. Ptys would solve all of the race problems too.
> > >
> > > Is there any good reason (other than history) for using a device node
> > > name (tty0, etc) instead of some other naming scheme if names are
> > > needed at all?
> > >
> > > If init, syslog, etc can be converted to ptys, do we need ttys? Xterms
> > > use ptys I don't notice that they aren't connect to a fix tty name.
> > > The virtual consoles would still be 0,1,2 but do they have to be
> > > hooked to tty0, 1, 2 instead of a pty?
> >
> > The basic difference between a pty and tty is that a pty connects to a
> > program (that created it by opening the ptmx node, for example xterm or
> > ssh) on the other end, while a tty connects to the kernel doing all the
> > character drawing in the framebuffer.
> >
> > You can't easily use one instead of the other, they're very different
> > beasts.
> >
> > Of course, a way to use a pty would be to have the console
> > implementation in userspace.
> >
> > The fact that no program is on the other end of a tty is also the reason
> > why they cannot be created dynamically like ptys, there is noone to open
> > a "ttmx" to create the ttys.
> >
> > Hence, the device nodes are pre-created by the kernel, while the real
> > devices are only created on open.
> 
> I forgot about the kernel vs user space termination issue.
> 
> One solution would be to not create the tty nodes and instead modify
> init, syslog to mknod the node before using it.

You'd have to add special treatment to quite a number of programs (all
the different *getty programs, for example), for what benefit? A
slightly cleaner /dev?

> Another would be to have a little user space daemon that listened to
> the pty creation, and then mknod the tty nodes as need and pipe the
> data through.

While we in theory could have hotplug events for pty creation, this is
not a working approach, since it tries to work from the wrong side.

A pty is created when ptmx is opened (by libc). You need to pass a
tty/pty device node to syslog/getty/whatever, and not ptmx.

The daemon would be in the same situation the kernel is now - it would
have to divine when an application will be trying to open a non-existent
device node and create it juste before that.

> That would be a first step to moving to a user space
> console implementation.

No. You don't need all that for a user space console. Xterm works today.
Just specify in a config file for the userspace console which pty VT's
should it create and which programs to pass them to.

> I see now that the 64 tty devices really are there and are provided by
> the kernel. It's just that hardly anyone uses all of them and they
> clutter up /dev.
 
True. It's a tradeoff.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Christmas list for the kernel

[Bill Davidsen]

Vojtech Pavlik wrote:
> On Wed, Nov 23, 2005 at 11:37:23AM -0500, Jon Smirl wrote:
> 
> 
>>Before everyone gets excited, I realize that all of this has
>>historical implications. But that doesn't mean we can't discuss
>>possible future alternative solutions.
>>
>>Thinking about this for a while it seems to me that the problem is
>>that the various apps (init, syslog) etc should not have a tty name as
>>part of their command line parameters. Instead these apps could use
>>ptys instead. Ptys would solve all of the race problems too.
>>
>>Is there any good reason (other than history) for using a device node
>>name (tty0, etc) instead of some other naming scheme if names are
>>needed at all?
>>
>>If init, syslog, etc can be converted to ptys, do we need ttys? Xterms
>>use ptys I don't notice that they aren't connect to a fix tty name.
>>The virtual consoles would still be 0,1,2 but do they have to be
>>hooked to tty0, 1, 2 instead of a pty?
> 
>  
> The basic difference between a pty and tty is that a pty connects to a
> program (that created it by opening the ptmx node, for example xterm or
> ssh) on the other end, while a tty connects to the kernel doing all the
> character drawing in the framebuffer.
> 
> You can't easily use one instead of the other, they're very different
> beasts.
> 
> Of course, a way to use a pty would be to have the console
> implementation in userspace.
> 
> The fact that no program is on the other end of a tty is also the reason
> why they cannot be created dynamically like ptys, there is noone to open
> a "ttmx" to create the ttys.
> 
> Hence, the device nodes are pre-created by the kernel, while the real
> devices are only created on open.
> 
Thank you, you can omit answering my previous post if you like, I can 
understand ugly but necessary.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Christmas list for the kernel

[Jon Smirl]

On 11/23/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> On Wed, Nov 23, 2005 at 09:43:58AM -0500, Jon Smirl wrote:
> > My system has:
> > 2 serial
> >
> > In /sys/bus/platform/devices I see this:
> > serial8250
> > shouldn't there be entries for all of the legacy devices?
> >
> > In /dev
> > ttyS0
> > ttyS1
> > ttyS2
> > ttyS3
>
> You're basically confused about serial ports.  The kernel serial devices
> whether or not hardware is found, to allow programs such as setserial to
> function.
>
> If you disagree with that, there'll be an equal number of people who
> have serial cards that need setserial who will in turn disagree with
> you.

This is confusing...

Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

/sys/bus/platform/devices/serial8250
[jonsmirl@jonsmirl serial8250]$ ls
bus  driver  power  tty:ttyS0  tty:ttyS1  tty:ttyS2  tty:ttyS3  uevent
[jonsmirl@jonsmirl serial8250]$


--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Russell King]

On Wed, Nov 23, 2005 at 10:19:19AM -0500, Jon Smirl wrote:
> On 11/23/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > On Wed, Nov 23, 2005 at 09:43:58AM -0500, Jon Smirl wrote:
> > > My system has:
> > > 2 serial
> > >
> > > In /sys/bus/platform/devices I see this:
> > > serial8250
> > > shouldn't there be entries for all of the legacy devices?
> > >
> > > In /dev
> > > ttyS0
> > > ttyS1
> > > ttyS2
> > > ttyS3
> >
> > You're basically confused about serial ports.  The kernel serial devices
> > whether or not hardware is found, to allow programs such as setserial to
> > function.
> >
> > If you disagree with that, there'll be an equal number of people who
> > have serial cards that need setserial who will in turn disagree with
> > you.
> 
> This is confusing...
> 
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

Yes it is, but it's down to the way folk want things to operate.  The
first two come from the legacy table in include/asm-*/serial.h.  The
second two come from something-that-I-have-no-clue-about but is probably
ACPI related.  Dunno.  We're back to the far-too-many-complex-ways-to-
initialise-serial problem again that I've given up really caring how
many lines of serial printk junk folk end up with.  I can't fight it
all.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Christmas list for the kernel

[Jon Smirl]

On 11/23/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > This is confusing...
> >
> > Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> > serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> > serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> > serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> > serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

Could this be the source of the four port versus the two port
confusion in the higher layers? It says 4 ports and list four ports,
but two are duplicates.

>
> Yes it is, but it's down to the way folk want things to operate.  The
> first two come from the legacy table in include/asm-*/serial.h.  The
> second two come from something-that-I-have-no-clue-about but is probably
> ACPI related.  Dunno.  We're back to the far-too-many-complex-ways-to-
> initialise-serial problem again that I've given up really caring how
> many lines of serial printk junk folk end up with.  I can't fight it
> all.


--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Russell King]

On Wed, Nov 23, 2005 at 10:31:15AM -0500, Jon Smirl wrote:
> On 11/23/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > > This is confusing...
> > >
> > > Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> > > serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> > > serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> > > serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> > > serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> 
> Could this be the source of the four port versus the two port
> confusion in the higher layers? It says 4 ports and list four ports,
> but two are duplicates.

Only if something's parsing the kernel messages.

The "4 ports" is about the _maximum_ number of ports that the driver
will support, and it will therefore create tty devices for ttyS0 to
ttyS3 regardless of whether the hardware exists.

To see why this is done, read my previous mails in this thread.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Christmas list for the kernel

[Marc Koschewski]

* Jon Smirl <jonsmirl@gmail.com> [2005-11-23 10:19:19 -0500]:

> On 11/23/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > On Wed, Nov 23, 2005 at 09:43:58AM -0500, Jon Smirl wrote:
> > > My system has:
> > > 2 serial
> > >
> > > In /sys/bus/platform/devices I see this:
> > > serial8250
> > > shouldn't there be entries for all of the legacy devices?
> > >
> > > In /dev
> > > ttyS0
> > > ttyS1
> > > ttyS2
> > > ttyS3
> >
> > You're basically confused about serial ports.  The kernel serial devices
> > whether or not hardware is found, to allow programs such as setserial to
> > function.
> >
> > If you disagree with that, there'll be an equal number of people who
> > have serial cards that need setserial who will in turn disagree with
> > you.
> 
> This is confusing...
> 
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> 
> /sys/bus/platform/devices/serial8250
> [jonsmirl@jonsmirl serial8250]$ ls
> bus  driver  power  tty:ttyS0  tty:ttyS1  tty:ttyS2  tty:ttyS3  uevent
> [jonsmirl@jonsmirl serial8250]$
> 

Mine looks like this.

* Why is the seconf line for ttyS1 missing (as you have one above)?
* What does these 'too much work' messages mean? Must have been come
  in lately...

marc@stiffy:~$ dmesg | grep -i serial
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: too much work for irq3
serial8250: too much work for irq3
serial8250: too much work for irq3
serial8250: too much work for irq3
serial8250: too much work for irq3
marc@stiffy:~$ ls /sys/bus/platform/devices/serial8250/
insgesamt 0
    832 drwxr-xr-x 3 root root    0 2005-11-23 16:57 ./
     12 drwxr-xr-x 7 root root    0 2005-11-23 09:21 ../
2452535 lrwxrwxrwx 1 root root    0 2005-11-23 16:58 bus -> ../../../bus/platform/
2452533 lrwxrwxrwx 1 root root    0 2005-11-23 16:58 driver -> ../../../bus/platform/drivers/serial8250/
    833 drwxr-xr-x 2 root root    0 2005-11-23 09:21 power/
2452534 lrwxrwxrwx 1 root root    0 2005-11-23 16:58 tty:ttyS1 -> ../../../class/tty/ttyS1/
2452536 --w------- 1 root root 4096 2005-11-23 09:20 uevent
marc@stiffy:~$

Marc

Re: Christmas list for the kernel

[Russell King]

On Wed, Nov 23, 2005 at 05:02:33PM +0100, Marc Koschewski wrote:
> Mine looks like this.
> 
> * Why is the seconf line for ttyS1 missing (as you have one above)?

Probably because whatever-added-ttyS0 didn't add ttyS1 as well.  As
I've said, due to the complex initialisation of serial (and the fact
I don't see this) I can't provide a more useful answer.

At a guess, the "whatever-added-ttyS0" could be ACPI.  ACPI doesn't
have the notion of devices, so any ACPI ports would appear as legacy
devices.  Hence, ttyS0 may have been provided by both the legacy table
and maybe ACPI, whereas ttyS1 seems to only be provided by the legacy
table.

Maybe that indicates your ACPI is buggy.  I don't know.  I know nothing
about ACPI.

> * What does these 'too much work' messages mean? Must have been come
>   in lately...

It means that we spun in the serial interrupt for more than 256 times
and reached the limit on the amount of work we were prepared to do.
Any idea what you were doing when these happened?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Christmas list for the kernel

[Marc Koschewski]

* Russell King <rmk+lkml@arm.linux.org.uk> [2005-11-23 16:16:37 +0000]:

> Maybe that indicates your ACPI is buggy.  I don't know.  I know nothing
> about ACPI.

Dude ... this is a DELL mobile! ;) Worse.

> 
> > * What does these 'too much work' messages mean? Must have been come
> >   in lately...
> 
> It means that we spun in the serial interrupt for more than 256 times
> and reached the limit on the amount of work we were prepared to do.
> Any idea what you were doing when these happened?

Sure, I know: I booted with a 3com Bluetooth Card in one of the two PCMCIA
slots I have.

Shouldn't PCMCIA slot 1 be ttyS0, PCMCIA slot 2 be ttyS1 and any of the
other serial ports ie ttyS2 and so forth? I have infrared as well (which
is setup in BIOS as well as RS232 on the back.l Where are these? Not
that I would need it... ;)

Regards,
	Marc

Re: Christmas list for the kernel

[Vojtech Pavlik]

On Wed, Nov 23, 2005 at 04:16:37PM +0000, Russell King wrote:
> On Wed, Nov 23, 2005 at 05:02:33PM +0100, Marc Koschewski wrote:
> > Mine looks like this.
> > 
> > * Why is the seconf line for ttyS1 missing (as you have one above)?
> 
> Probably because whatever-added-ttyS0 didn't add ttyS1 as well.  As
> I've said, due to the complex initialisation of serial (and the fact
> I don't see this) I can't provide a more useful answer.
> 
> At a guess, the "whatever-added-ttyS0" could be ACPI.  ACPI doesn't
> have the notion of devices, so any ACPI ports would appear as legacy
> devices.  Hence, ttyS0 may have been provided by both the legacy table
> and maybe ACPI, whereas ttyS1 seems to only be provided by the legacy
> table.
> 
> Maybe that indicates your ACPI is buggy.  I don't know.  I know nothing
> about ACPI.
> 
> > * What does these 'too much work' messages mean? Must have been come
> >   in lately...
> 
> It means that we spun in the serial interrupt for more than 256 times
> and reached the limit on the amount of work we were prepared to do.
> Any idea what you were doing when these happened?
 
Because ACPI was right and the second serial port isn't there?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Christmas list for the kernel

[Russell King]

On Wed, Nov 23, 2005 at 05:23:37PM +0100, Vojtech Pavlik wrote:
> On Wed, Nov 23, 2005 at 04:16:37PM +0000, Russell King wrote:
> > It means that we spun in the serial interrupt for more than 256 times
> > and reached the limit on the amount of work we were prepared to do.
> > Any idea what you were doing when these happened?
>  
> Because ACPI was right and the second serial port isn't there?

Well, it certainly looked like a serial port when it was probed - to the
extent that even loopback mode worked.  Hence I'd be very surprised if
it wasn't there.

It's the same test that's being applied as has been for the last 14
years to detect if a port is present or not.  Maybe Ted T'so would
be aware if it can optimistically discover ports?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Christmas list for the kernel

[Dmitry Torokhov]

On 11/23/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> On Wed, Nov 23, 2005 at 05:23:37PM +0100, Vojtech Pavlik wrote:
> > On Wed, Nov 23, 2005 at 04:16:37PM +0000, Russell King wrote:
> > > It means that we spun in the serial interrupt for more than 256 times
> > > and reached the limit on the amount of work we were prepared to do.
> > > Any idea what you were doing when these happened?
> >
> > Because ACPI was right and the second serial port isn't there?
>
> Well, it certainly looked like a serial port when it was probed - to the
> extent that even loopback mode worked.  Hence I'd be very surprised if
> it wasn't there.
>

It could be on board but not having a connector attached. SInce it is
not useable ACPI might omit it.

--
Dmitry

Re: Christmas list for the kernel

[Vojtech Pavlik]

On Wed, Nov 23, 2005 at 11:31:30AM -0500, Dmitry Torokhov wrote:
> On 11/23/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > On Wed, Nov 23, 2005 at 05:23:37PM +0100, Vojtech Pavlik wrote:
> > > On Wed, Nov 23, 2005 at 04:16:37PM +0000, Russell King wrote:
> > > > It means that we spun in the serial interrupt for more than 256 times
> > > > and reached the limit on the amount of work we were prepared to do.
> > > > Any idea what you were doing when these happened?
> > >
> > > Because ACPI was right and the second serial port isn't there?
> >
> > Well, it certainly looked like a serial port when it was probed - to the
> > extent that even loopback mode worked.  Hence I'd be very surprised if
> > it wasn't there.
> >
> 
> It could be on board but not having a connector attached. SInce it is
> not useable ACPI might omit it.
 
Still, even with noise on the RX line, the ISR should be able to empty
the RX FIFO faster than it fills itself, and not result in "too much
work".

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Christmas list for the kernel

[Vojtech Pavlik]

On Wed, Nov 23, 2005 at 04:27:28PM +0000, Russell King wrote:
> On Wed, Nov 23, 2005 at 05:23:37PM +0100, Vojtech Pavlik wrote:
> > On Wed, Nov 23, 2005 at 04:16:37PM +0000, Russell King wrote:
> > > It means that we spun in the serial interrupt for more than 256 times
> > > and reached the limit on the amount of work we were prepared to do.
> > > Any idea what you were doing when these happened?
> >  
> > Because ACPI was right and the second serial port isn't there?
> 
> Well, it certainly looked like a serial port when it was probed - to the
> extent that even loopback mode worked.  Hence I'd be very surprised if
> it wasn't there.
> 
> It's the same test that's being applied as has been for the last 14
> years to detect if a port is present or not.  Maybe Ted T'so would
> be aware if it can optimistically discover ports?
 
If the loopback check is still enabled - then no, I've seen the probe
code and that chance is next to zero, unless the i/o space is aliasing
to a real port.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Christmas list for the kernel

[Pierre Ossman]

Russell King wrote:
> On Wed, Nov 23, 2005 at 09:43:58AM -0500, Jon Smirl wrote:
>> My system has:
>> 2 serial
>>
>> In /sys/bus/platform/devices I see this:
>> serial8250
>> shouldn't there be entries for all of the legacy devices?
>>
>> In /dev
>> ttyS0
>> ttyS1
>> ttyS2
>> ttyS3
> 
> You're basically confused about serial ports.  The kernel serial devices
> whether or not hardware is found, to allow programs such as setserial to
> function.
> 
> If you disagree with that, there'll be an equal number of people who
> have serial cards that need setserial who will in turn disagree with
> you.
> 

But if no hardware is connected to those devices, then where does the 
driver route the setserial stuff?

We had a similar discussion regarding hal and the final solution was to 
check the uart type to determine if the port was there or not.

Rgds
Pierre

Re: Christmas list for the kernel

[Russell King]

On Wed, Nov 23, 2005 at 04:20:00PM +0100, Pierre Ossman wrote:
> But if no hardware is connected to those devices, then where does the 
> driver route the setserial stuff?

setserial /dev/ttyS2 port 0x200 irq 5 autoconfig

and you might then end up with another serial port detected.  If
/dev/ttyS2 and above do not exist, you can't do that.  That would
in turn effectively prevent folk with some serial cards using them
with Linux without editing and rebuilding their kernel.

As for the rest of the "setserial stuff" it gets recorded against
the port and remembered for when the hardware turns up, which it
may do if it's your PCMCIA modem card.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Christmas list for the kernel

[Pierre Ossman]

Russell King wrote:
> On Wed, Nov 23, 2005 at 04:20:00PM +0100, Pierre Ossman wrote:
>   
>> But if no hardware is connected to those devices, then where does the 
>> driver route the setserial stuff?
>>     
>
> setserial /dev/ttyS2 port 0x200 irq 5 autoconfig
>
> and you might then end up with another serial port detected.  If
> /dev/ttyS2 and above do not exist, you can't do that.  That would
> in turn effectively prevent folk with some serial cards using them
> with Linux without editing and rebuilding their kernel.
>
>   

Ah. But why is this not done through module parameters? That would be 
more consistent with how you specify resources for other drivers.

> As for the rest of the "setserial stuff" it gets recorded against
> the port and remembered for when the hardware turns up, which it
> may do if it's your PCMCIA modem card.
>
>   

This could be a bit more questionable. Setting the initial state of 
hardware is better done (IMHO) by reacting to some hotplug event. E.g. 
fedora uses an 'install' line in modprobe.conf to restore mixer state 
for sound cards.

Rgds
Pierre

Re: Christmas list for the kernel

[Russell King]

On Wed, Nov 23, 2005 at 04:39:35PM +0100, Pierre Ossman wrote:
> Russell King wrote:
> >On Wed, Nov 23, 2005 at 04:20:00PM +0100, Pierre Ossman wrote:
> >  
> >>But if no hardware is connected to those devices, then where does the 
> >>driver route the setserial stuff?
> >>    
> >
> >setserial /dev/ttyS2 port 0x200 irq 5 autoconfig
> >
> >and you might then end up with another serial port detected.  If
> >/dev/ttyS2 and above do not exist, you can't do that.  That would
> >in turn effectively prevent folk with some serial cards using them
> >with Linux without editing and rebuilding their kernel.
> 
> Ah. But why is this not done through module parameters? That would be 
> more consistent with how you specify resources for other drivers.

Take a moment to consider how you would supply a large number of ports
via this method - eg, 16 ports, where a port IO and IRQ configuration
takes about 10 characters ("0x1234,11"), and then what about the baud
base, probe flags (auto_irq, skip_test) ?

Also consider that ttyS0 might be your serial console for your headless
box, so you're unable to build 8250 as a module in the first place.

It really isn't simple.  Serial _is_ special - and that is why it keeps
sprouting new and wonderful initialisation paths.  I'd rather not add
yet another gods greatest invention initialisation path on top of those
we already have.

> >As for the rest of the "setserial stuff" it gets recorded against
> >the port and remembered for when the hardware turns up, which it
> >may do if it's your PCMCIA modem card.
> 
> This could be a bit more questionable. Setting the initial state of 
> hardware is better done (IMHO) by reacting to some hotplug event. E.g. 
> fedora uses an 'install' line in modprobe.conf to restore mixer state 
> for sound cards.

Actually, my example was slightly flawed - when the hardware turns up
it gets reset back to something sane.  So the settings are merely
remembered while the hardware doesn't exist.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Christmas list for the kernel

[Jon Smirl]

On 11/23/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> On Wed, Nov 23, 2005 at 04:20:00PM +0100, Pierre Ossman wrote:
> > But if no hardware is connected to those devices, then where does the
> > driver route the setserial stuff?
>
> setserial /dev/ttyS2 port 0x200 irq 5 autoconfig
>
> and you might then end up with another serial port detected.  If
> /dev/ttyS2 and above do not exist, you can't do that.  That would
> in turn effectively prevent folk with some serial cards using them
> with Linux without editing and rebuilding their kernel.

If my box has two serial ports and I use setserial to change the port,
I still only have two serial ports.  Shouldn't this behave as a
hotplug remove/add when the port address is changed?

> As for the rest of the "setserial stuff" it gets recorded against
> the port and remembered for when the hardware turns up, which it
> may do if it's your PCMCIA modem card.

This is definitely not in the current spirit of hotplug. The PCMCIA
card should generate a hotplug add event and then the script for the
event can do the setserial equivalent.

You could probably modify setserial to create the scripts and the user
would never know things changed.

--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[Russell King]

On Wed, Nov 23, 2005 at 10:49:35AM -0500, Jon Smirl wrote:
> On 11/23/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > On Wed, Nov 23, 2005 at 04:20:00PM +0100, Pierre Ossman wrote:
> > > But if no hardware is connected to those devices, then where does the
> > > driver route the setserial stuff?
> >
> > setserial /dev/ttyS2 port 0x200 irq 5 autoconfig
> >
> > and you might then end up with another serial port detected.  If
> > /dev/ttyS2 and above do not exist, you can't do that.  That would
> > in turn effectively prevent folk with some serial cards using them
> > with Linux without editing and rebuilding their kernel.
> 
> If my box has two serial ports and I use setserial to change the port,
> I still only have two serial ports.  Shouldn't this behave as a
> hotplug remove/add when the port address is changed?

Maybe, but that's not how it's historically been designed to work.
I'd rather not swipe the port from beneath setserial, especially
when it may want to do more than one IOCTL to configure the port.
What you suggest would again breaking existing setups.

> > As for the rest of the "setserial stuff" it gets recorded against
> > the port and remembered for when the hardware turns up, which it
> > may do if it's your PCMCIA modem card.
> 
> This is definitely not in the current spirit of hotplug. The PCMCIA
> card should generate a hotplug add event and then the script for the
> event can do the setserial equivalent.

These comments are misplaced given my corrected response.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Christmas list for the kernel

[Bill Davidsen]

Russell King wrote:
> On Wed, Nov 23, 2005 at 09:43:58AM -0500, Jon Smirl wrote:

>>Plus I have 64 tty devices. Couldn't the tty devices be created
>>dynamically as they are consumed? Same for the loop and ram devices?
> 
> 
> You do realise that the dynamic device creation for those 64 console
> devices is done via the console device being _opened_ by userspace?
> 
Which userspace program is opening 64 console devices? Surely it could 
be taught to use a smaller number. If you mean that open the console 
once creates all those devices, I think that's exactly what Jon was 
suggesting is not desirable (I agree).

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Christmas list for the kernel

[Jon Smirl]

On 11/23/05, Bill Davidsen <davidsen@tmr.com> wrote:
> Russell King wrote:
> > On Wed, Nov 23, 2005 at 09:43:58AM -0500, Jon Smirl wrote:
>
> >>Plus I have 64 tty devices. Couldn't the tty devices be created
> >>dynamically as they are consumed? Same for the loop and ram devices?
> >
> >
> > You do realise that the dynamic device creation for those 64 console
> > devices is done via the console device being _opened_ by userspace?
> >
> Which userspace program is opening 64 console devices? Surely it could
> be taught to use a smaller number. If you mean that open the console
> once creates all those devices, I think that's exactly what Jon was
> suggesting is not desirable (I agree).

I believe the 64 console devices is comming from this define in tty.h
#define MAX_NR_CONSOLES 63

>
> --
>     -bill davidsen (davidsen@tmr.com)
> "The secret to procrastination is to put things off until the
>   last possible moment - but no longer"  -me
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


--
Jon Smirl
jonsmirl@gmail.com

Re: Christmas list for the kernel

[John Stoffel]

>>>>> "Jon" == Jon Smirl <jonsmirl@gmail.com> writes:

Jon> My system has:
Jon> 2 serial
Jon> 1 parallel
Jon> 1 floppy
Jon> 1 gameport
Jon> 1 joystick
Jon> 2 PS/2
Jon> 2 VGA
Jon> 1 HPET
Jon> 1 RTC

Can you post the dmesg output of your bootup?  I'm sure that's going
to help the most for people to see what's going on here.  Also the
output of 'lspic -vvv' will also be useful.  

Don't expect me to be able to help much, I'm clueless at the low
level.  *grin*

John

Re: Christmas list for the kernel

[Martin Mares]

Hi!

> VESAfb can't ever be autoloaded.

Really?  Wouldn't be possible to detect the video mode number passed to
video.S during boot and if it's a graphics mode, load VESAfb?

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Wanted: Schroedinger Cat. Dead or Alive.

Re: Christmas list for the kernel

[Dmitry Torokhov]

On 11/22/05, Greg KH <greg@kroah.com> wrote:
> On Tue, Nov 22, 2005 at 01:31:16PM -0500, Jon Smirl wrote:
> >
> > 4) Merge klibc and fix up the driver system so that everything is
> > hotplugable. This means no more need to configure drivers in the
> > kernel, the right drivers will just load automatically.
>
> What driver subsystem is not hotplugable and does not have automatically
> loaded modules today?
>

Input core does not have modalias and needs a special handler to load
interfaces (mousedev, joydev, tsedv, evdev). But input_id is _huge_
and I am not sure that using modalias is a good idea here.

--
Dmitry

Re: Christmas list for the kernel

[Alan Cox]

On Maw, 2005-11-22 at 12:49 -0800, Greg KH wrote:
> What driver subsystem is not hotplugable and does not have automatically
> loaded modules today?

IDE is the one I kind of notice the most.

There are others too like ISAPnP hotplug on dock events, and BIOSPnP
dock hotplug but those are deeply obscure and dying out.

Early boot issues (WAS: Christmas list for the kernel)

[Benjamin Herrenschmidt]

On Tue, 2005-11-22 at 12:49 -0800, Greg KH wrote:
> On Tue, Nov 22, 2005 at 01:31:16PM -0500, Jon Smirl wrote:
> > 
> > 4) Merge klibc and fix up the driver system so that everything is
> > hotplugable. This means no more need to configure drivers in the
> > kernel, the right drivers will just load automatically.
> 
> What driver subsystem is not hotplugable and does not have automatically
> loaded modules today?
> 
> There are a few issues around PnP devices that I know of, and PCMCIA
> needs some seriously love, but other than that I think we are well off.
> Or am I missing something big here?

Well, there is at least one big problem :) We tend to call hotplug for
new devices way too early during boot, before it's even sane to try to
run userland. For example, we may well try to run it before we
created /dev/null or /dev/zero ... In some cases (PCI on various
platforms typically), devices are instanciated, then all sorts of
necessary fixups are applied, and it's assumed no driver will kick in
before those fixups are finished, etc...

I think it is be rather very unsafe to have /sbin/hotplug be called
before the system finishes with all initcalls...

There is a very similar problem lurking around the corner with
suspend/resume. Since during a machine suspend cycles, from the moment
we start suspending devices to the moment we have finished waking them
all up, any try to run userland things is doomed. The disk may be spun
down & locked, all other processes frozen, etc....

This is actually a real life problem with drivers using the
request_firmware interface nowadays: Some of them call it on resume, but
heh, it's too early, your disk may not be resumed yet ! Some of them
call it at more "normal" times, but in general, drivers have no way to
knwo that a machine suspend/resume cycle is in progress (the disk may
have been suspended already but the that other driver suspend not called
yet).

In fact, there is even a problem with GFP_KERNEL allocations :) In fact,
as soon as the suspend process is started, all allocations should be
silently turned into GFP_NOIO at the very least ...

Ben.

Re: Early boot issues (WAS: Christmas list for the kernel)

[Andi Kleen]

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> 
> I think it is be rather very unsafe to have /sbin/hotplug be called
> before the system finishes with all initcalls...

Yes it is - it unconvered some very interesting MM problems on x86-64
(now fixed, but there might be more lurking)

-Andi

Re: Christmas list for the kernel

[Bill Davidsen]

Jon Smirl wrote:
> There have been recent comments about the pace of kernel development
> slowing. What are the major areas that still need major work? When the
> thread slows down maybe Linus will tell us what the top ten items
> really are.
> 
> To get things started here's a few that I would add:
> 
> 1) graphics, it is a total mess.
> 
> 2) get Xen merged, virtualization will be key on the server.
> Hotplugable CPUs and memory are tied up in this one.
> 
Serious question, when/if xen is in the kernel, is there a reason for 
UML? If so, why would I use UML instead of xen, and where?

I'm looking at a project eventually headed for a blade server, clearly 
some cost saving in the testing environment would be nice.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Christmas list for the kernel

[Rob Landley]

On Tuesday 22 November 2005 16:11, Bill Davidsen wrote:
> Serious question, when/if xen is in the kernel, is there a reason for
> UML? If so, why would I use UML instead of xen, and where?

Xen requires support in the host kernel.  UML (skas0 mode) does not.

I have a build system that uses UML as a better fakeroot.  I can't use qemu 
for this because I want to boot borrowing the hosts's filesystem (so the 
build doesn't need a huge binary blob of precompiled stuff to start 
doing ./configure;make;make install with...  At that point I might as well 
just distribute the final binaries and be done with it).

I don't want the thing to require root access, yet the build needs to drop a 
symlink into /, wants to mknod, chown, chroot, and perform --bind and --move 
mounts.

Fakeroot wouldn't be sufficient because there's no guarantee the host system 
is running a 2.6 kernel (no --bind or --move mounts) and worse, I'm building 
uClibc against the most recent Mazur headers I can find which means the 
resulting uClibc may not run on an older kernel (even running against a 
sufficiently old 2.6 kernel means segfaults due to missing features the new 
headers describe).

I find UML a very convenient way to get a virtual environment borrowing 
resources from the host without having to set up the host.  This means I can 
deploy it to relatively unknown systems, without requiring somebody with root 
access on those systems to replace the kernel and reboot, which generally 
isn't an option.

Rob

Re: Christmas list for the kernel

[Pavel Machek]

On Út 22-11-05 13:31:16, Jon Smirl wrote:
> There have been recent comments about the pace of kernel development
> slowing. What are the major areas that still need major work? When the
> thread slows down maybe Linus will tell us what the top ten items
> really are.
> 
> To get things started here's a few that I would add:
> 
> 1) graphics, it is a total mess.
> 
> 2) get Xen merged, virtualization will be key on the server.
> Hotplugable CPUs and memory are tied up in this one.
> 
> 3) Reiser4 merge, Rieser4 itself is not important, it's the new
> concepts about file systems that Reiser4 brings to the kernel that are
> important. Get the issues around the VFS layer sorted out so that this
> can happen. We need some forward evolution in file system concepts.
> 
> 4) Merge klibc and fix up the driver system so that everything is
> hotplugable. This means no more need to configure drivers in the
> kernel, the right drivers will just load automatically.

5) Runtime power management

its just not there, or alternatively give me

6) E=mc^2 battery from the recent supercomputer thread

, which nicely solves 

7) word domination, 

too.

								Pavel
-- 
Thanks, Sharp!