[PATCH] Re: Move of input drivers, some word needed from you
Linus Torvalds
On Sun, 20 Aug 2000, Christoph Hellwig wrote:
> >
> > Who will send the joystick Makefile/Config.in patch to Linus? Please send it
> > ASAP, I'll do the hackery for CONFIG_INPUT_ADBHID after that then.
>
> Me. Here's a patch for -test7pre5.
> NOTE (for Linus): beside the Changes to the makefiles and {C,c}onfig.ins
> this is the same as moving drivers/joystick/*.c and drivers/usb/{evdev.c,
> hid-debug.h, hid.c, hid.h, iforce.c, input.c, keybdev.c, mousedev.c, usbkbd.c,
> usbmouse.c, wacom.c } to drivers/input
I have yet to understand WHY all of this is done.
Why?
I personally think this is a major step backwards. Moving things to be in
the same directory just because it made some configuration easier. Nobody
has explained to me why you couldn't just add one new configuration
option, and make the affected drivers (in their regular places) dependent
on that configuration option.
Are all the SCSI drivers going to be under drivers/scsi/? No. The "normal"
ones that don't have any better place for them are, but nobody has really
suggested moving drivers/usb/storage around to another place just because
it uses the SCSI layer.
This patch is not going in until somebody can explain to me (in words of
one syllable) why it makes any sense at all. As far as I can tell, it
would be a ton more cleaner to do just
mv drivers/usb/input.c drivers/char/
and add a config option for it that the real drivers (wherever they may
be - be they USB, firewire, joysticks, what-not) can know to disable
themselves or not.
I object to moving files around in ways that makes the tree _less_ clear.
I want the kernel tree to be a nice hierarchy of drivers, filesystems,
etc. I don't see the point in lumping everything together in one
subdirectory just because they happen to be "input" devices, regardless of
what kind of device they really are.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
Philipp Rumpf
> Are all the SCSI drivers going to be under drivers/scsi/? No. The "normal"
> ones that don't have any better place for them are, but nobody has really
> suggested moving drivers/usb/storage around to another place just because
> it uses the SCSI layer.
> I object to moving files around in ways that makes the tree _less_ clear.
> I want the kernel tree to be a nice hierarchy of drivers, filesystems,
> etc. I don't see the point in lumping everything together in one
> subdirectory just because they happen to be "input" devices, regardless of
> what kind of device they really are.
I have to admit I don't quite understand how drivers/ is organized right now.
There seem to be at least four criteria for subdirectories of drivers/:
drivers/<function> (sound, net)
drivers/<interface> (char, block) (this isn't the same as function IMHO)
drivers/<bus-the-device-is-on> (usb, sbus)
drivers/<architecture> (s390, sgi)
then there are some hybrids (usb seems to be both "devices that are on USB"
and "USB controllers") and strange things like drivers/char/sysrq.c (which
isn't a character device at all, and isn't really a driver either).
I don't see any particular preference, and my impression is that new
directories get added pretty much at random.
I think I'm not the only one to be a bit confused about this.
Philipp Rumpf
Linus Torvalds
On Mon, 21 Aug 2000, Philipp Rumpf wrote:
>
> I have to admit I don't quite understand how drivers/ is organized right now.
There's a few "overlapping" organizations, which is why it certainly is
confusing.
Basically, the thing originally was just "drivers/char" and
"drivers/block". Nothing more.
It became quite unmanageable fairly quickly, because by the time you have
a few hundred files in a directory, "ls" no longer gives the directory
listing, it just gives tons of lines scolling by too fast to make much
sense of it. And configuration etc is painful.
Right now, drivers/net is pretty horrible, for example, and we've started
separating things out a bit (ie drivers/net/tulip, drivers/net/pcmcia etc
to get a better hierarchy). Same thing happened to drivers/block -
although in that case the splitup happened to drivers/ide, drivers/cdrom.
drivers/char is messy, and _should_ probably contain only "fundamental
char drivers" (ie things like basic tty layer stuff, ptys, /dev/zero,
etc). It has too many "misc" drivers in it. Stuff like bttv, zr36120 etc.
And the low-level serial stuff should probably go into drivers/serial or
something.
> There seem to be at least four criteria for subdirectories of drivers/:
>
> drivers/<function> (sound, net)
> drivers/<interface> (char, block) (this isn't the same as function IMHO)
> drivers/<bus-the-device-is-on> (usb, sbus)
> drivers/<architecture> (s390, sgi)
The last should probably be arch/<xxx>/drivers, but the other ones are
either sensible (tons of bus-independent drivers) or conceptual UNIX
things (char vs block).
> I don't see any particular preference, and my impression is that new
> directories get added pretty much at random.
I'm eager to add new directories if they help make for finer-granularity
hierarchy.
The reason I dislike drivers/input is that it seems to collapse many
drivers under one, and split up something that conceptually is clearly one
tree (usb). So it fails both the "split things up for clarity" and the
"organize things after something simple" idea.
Which is not to say that the drivers/ hierarchy is necessarily all that
wonderful as-is.
Linus
Alan Cox
> hierarchy.
I'd like to see drivers/video4linux/radio and drivers/video4linux/video
appear. That would remove a lot of small drivers from drivers/char. I just
dont have the time right now to do it
But as (notional at best) video4linux maintainer whoever does it has my
best wishes 8)
Roman Zippel
> > drivers/<architecture> (s390, sgi)
>
> The last should probably be arch/<xxx>/drivers, but the other ones are
> either sensible (tons of bus-independent drivers) or conceptual UNIX
> things (char vs block).
What about drivers/macintosh or drivers/zorro, that are needed by two
architectures. Is a mach/ directory still feasible?
bye, Roman
Arjan van de Ven
> This patch is not going in until somebody can explain to me (in words of
> one syllable) why it makes any sense at all. As far as I can tell, it
> would be a ton more cleaner to do just
> mv drivers/usb/input.c drivers/char/
> and add a config option for it that the real drivers (wherever they may
> be - be they USB, firewire, joysticks, what-not) can know to disable
> themselves or not.
Then can you tell me why you rejected my (minimal) patch that did exactly that?
Or should I resend it again?
Greetings,
Arjan van de Ven
Matthias Andree
> Hi,
>
> > > drivers/<architecture> (s390, sgi)
> >
> > The last should probably be arch/<xxx>/drivers, but the other ones are
> > either sensible (tons of bus-independent drivers) or conceptual UNIX
> > things (char vs block).
>
> What about drivers/macintosh or drivers/zorro, that are needed by two
> architectures. Is a mach/ directory still feasible?
Are you talking about the Zorro bus that Amigas use? If so, what
architecture besides Amiga-m68k uses it? Is it for PPC?
Why does that belong into drivers/$ARCH? arch/$ARCH/drivers is fine, and
you can symlink it around if more than one architecture shares a certain
piece of hardware.
Plus, drivers should be separated from abstraction layers. Things get
unmaintainable otherwise.
--
Matthias Andree
Matthew Wilcox
> > There seem to be at least four criteria for subdirectories of drivers/:
> >
> > drivers/<function> (sound, net)
> > drivers/<interface> (char, block) (this isn't the same as function IMHO)
> > drivers/<bus-the-device-is-on> (usb, sbus)
>
> The last should probably be arch/<xxx>/drivers, but the other ones are
> either sensible (tons of bus-independent drivers) or conceptual UNIX
> things (char vs block).
ugh, no. not arch/foo/drivers. people miss them when they're updating
drivers, and worse, the same chipset gets used on different architctures
and we end up with 15 different lance drivers. not to mention that we
have a driver which is shared between parisc and ia64... :-)
--
Revolutions do not require corporate support.
Linus Torvalds
On Mon, 21 Aug 2000, Arjan van de Ven wrote:
>
> Then can you tell me why you rejected my (minimal) patch that did exactly that?
Probably because I get too much email, and because I hadn't realized how
much email the whole input thing would end up generating..
> Or should I resend it again?
Please do.
Linus
Linus Torvalds
On Mon, 21 Aug 2000, Alan Cox wrote:
>
> I'd like to see drivers/video4linux/radio and drivers/video4linux/video
> appear. That would remove a lot of small drivers from drivers/char. I just
> dont have the time right now to do it
I'd rather not have the "video4linux" there - it doesn't make sense to me
except as a group name. But perhaps a plain "drivers/radio" thing?
Possibly under a "drivers/media" hierarchy?
Mike A. Harris
>Date: Sun, 20 Aug 2000 20:52:56 +0200
>From: Christoph Hellwig <h...@caldera.de>
>To: Franz.Si...@lauterbach.com
>Cc: jsim...@neruo.com, linuxcon...@lists.sourceforge.net, bh...@calva.net,
> pau...@linuxcare.com.au, co...@fsmlabs.com, torv...@transmeta.com,
> linux-...@vger.kernel.org
>Subject: [PATCH] Re: Move of input drivers, some word needed from you
>
>> Well, OK. This will get really ugly when adbhid.c gets added with one of the
>> next PPC merges and and drivers/usb has to be entered for
>> CONFIG_ADB/CONFIG_INPUT_ADBHID too. Well, if that's the final word for
>> 2.4.0... Can we schedule the move for 2.4.1 then?
>>
>> Who will send the joystick Makefile/Config.in patch to Linus? Please send it
>> ASAP, I'll do the hackery for CONFIG_INPUT_ADBHID after that then.
>
>Me. Here's a patch for -test7pre5.
>NOTE (for Linus): beside the Changes to the makefiles and {C,c}onfig.ins
>this is the same as moving drivers/joystick/*.c and drivers/usb/{evdev.c,
>hid-debug.h, hid.c, hid.h, iforce.c, input.c, keybdev.c, mousedev.c, usbkbd.c,
>usbmouse.c, wacom.c } to drivers/input
Was it entirely necessary to post an 800k patch to 2 mailing
lists of which I'm on both? It could have at least been gzipped,
or better yet put on a web site with a URL. With an address like
@caldera.de, I would assume you'd have a good idea of technical
know how and such. I'm assuming thus that it was an
accident. So please just be more careful in the future. Large
patches should generally never get posted to lists. Those that
want them will go get them from the web somewhere or FTP.
I'm looking forward to the new console code, but not at 2Mb a day
in my inbox. ;o)
take care,
TTYL
--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate
Try out Red Hat Linux today: http://www.redhat.com
ftp://ftp.redhat.com/pub/redhat/redhat-6.2/
Alan Cox
> except as a group name. But perhaps a plain "drivers/radio" thing?
> Possibly under a "drivers/media" hierarchy?
drivers/media/video drivers/media/radio would work yes
The radio and video stuff belongs at least in proximity since there are devices
heavily involved in doing both and they use the same core code and API (a
radio is a TV with no picture to Linux)
Jes Sorensen
Roman> Hi,
>> > drivers/<architecture> (s390, sgi)
>>
>> The last should probably be arch/<xxx>/drivers, but the other ones
>> are either sensible (tons of bus-independent drivers) or conceptual
>> UNIX things (char vs block).
Roman> What about drivers/macintosh or drivers/zorro, that are needed
Roman> by two architectures. Is a mach/ directory still feasible?
drivers/zorro is on the line of drivers/pci, it's code to drive the
Zorro bus, there are no drivers for devices connected to a zorro bus
in there, just like there are no PCI Ethernet drives in
drivers/pci. drivers/macintosh are a mixture of the code for the
busses and actual devices, I'd like to see the actual drivers moved to
other directories, char, scsi etc. and possible merged with drivers
for other machines that use the same chips.
Jes
Jes Sorensen
Matthias> On Mon, 21 Aug 2000, Roman Zippel wrote:
>> What about drivers/macintosh or drivers/zorro, that are needed by
>> two architectures. Is a mach/ directory still feasible?
Matthias> Are you talking about the Zorro bus that Amigas use? If so,
Matthias> what architecture besides Amiga-m68k uses it? Is it for PPC?
PPC, just as sbus support applies to sparc, sparc64 and m68k and nubus
is for PPC and m68k.
Matthias> Why does that belong into drivers/$ARCH? arch/$ARCH/drivers
Matthias> is fine, and you can symlink it around if more than one
Matthias> architecture shares a certain piece of hardware.
Because it needs to be outside the arch hierachy and symlinks are
foul.
Mike Galbraith
Wrong.. patches should be posted/digested by list recipients. If
subscribers can't be bothered to read patches, they should reconsider
their initial application for acceptance to this list. I'll happily
de-uuencode gunzip and whatever, but I _don't like_ to have to chase
it down to see it. Please post patches.. _not_ URL's.
-Mike
Matthias Andree
filters)
On Mon, 21 Aug 2000, Jes Sorensen wrote:
> PPC, just as sbus support applies to sparc, sparc64 and m68k and nubus
> is for PPC and m68k.
D'accord. I was unaware of that.
> Matthias> Why does that belong into drivers/$ARCH? arch/$ARCH/drivers
> Matthias> is fine, and you can symlink it around if more than one
> Matthias> architecture shares a certain piece of hardware.
>
> Because it needs to be outside the arch hierachy and symlinks are
> foul.
Hum. So would not the arch boil down to provide the following:
* bootstrapping, pulling all necessary information off the
BIOS/OpenPROM/whatever, passing them on to the Kernel.
* provide Config.in to the actual hardware drivers
--
Matthias Andree
Roman Zippel
> drivers/zorro is on the line of drivers/pci, it's code to drive the
> Zorro bus, there are no drivers for devices connected to a zorro bus
> in there, just like there are no PCI Ethernet drives in
> drivers/pci. drivers/macintosh are a mixture of the code for the
> busses and actual devices, I'd like to see the actual drivers moved to
> other directories, char, scsi etc. and possible merged with drivers
> for other machines that use the same chips.
I mostly agree for that, but we still have arch/(m68k|ppc)/amiga, that
could share some more code. Currently it doesn't for several reasons.
There is some code for Amigas/Macs, that is truly machine specific, but
used on both m68k/ppc.
bye, Roman
Brian Gerst
>
> On Mon, 21 Aug 2000, Mike A. Harris wrote:
>
> > Was it entirely necessary to post an 800k patch to 2 mailing
> > lists of which I'm on both? It could have at least been gzipped,
> > or better yet put on a web site with a URL. With an address like
> > @caldera.de, I would assume you'd have a good idea of technical
> > know how and such. I'm assuming thus that it was an
> > accident. So please just be more careful in the future. Large
> > patches should generally never get posted to lists. Those that
> > want them will go get them from the web somewhere or FTP.
>
> Wrong.. patches should be posted/digested by list recipients. If
> subscribers can't be bothered to read patches, they should reconsider
> their initial application for acceptance to this list. I'll happily
> de-uuencode gunzip and whatever, but I _don't like_ to have to chase
> it down to see it. Please post patches.. _not_ URL's.
I'd wager most people on this list do not have broadband access to the
internet. Downloading large attachments takes time and in some cases
(especially for people outside the US) money. The normal traffic on
this list is large enough already without large attachments. If someone
is interested enough in a patch they will download it from a URL.
--
Brian Gerst
Christoph Hellwig
> Wrong.. patches should be posted/digested by list recipients. If
> subscribers can't be bothered to read patches, they should reconsider
> their initial application for acceptance to this list. I'll happily
> de-uuencode gunzip and whatever, but I _don't like_ to have to chase
> it down to see it. Please post patches.. _not_ URL's.
Posting patches is generally a good thing (IMHO). Gziping them
is just plain ugly (also IMHO).
On the other hand very big patches that do nothing else then
moving files around (like my patch) don't really have to be posted
to lkml. If I hadn't overssen the size of this patch, I would
probably have put it on ftp.
My apologies
Christoph
--
Always remember that you are unique. Just like everyone else.
Jeff Garzik
> Wrong.. patches should be posted/digested by list recipients. If
> subscribers can't be bothered to read patches, they should reconsider
> their initial application for acceptance to this list. I'll happily
> de-uuencode gunzip and whatever, but I _don't like_ to have to chase
> it down to see it. Please post patches.. _not_ URL's.
URLs are better for big patches; some people still have to pay by the
minute for their Internet access...
--
Jeff Garzik |
Building 1024 | Andre the Giant has a posse.
MandrakeSoft, Inc. |
Mike Galbraith
> Mike Galbraith wrote:
> >
> > On Mon, 21 Aug 2000, Mike A. Harris wrote:
> >
> > > Was it entirely necessary to post an 800k patch to 2 mailing
> > > lists of which I'm on both? It could have at least been gzipped,
> > > or better yet put on a web site with a URL. With an address like
> > > @caldera.de, I would assume you'd have a good idea of technical
> > > know how and such. I'm assuming thus that it was an
> > > accident. So please just be more careful in the future. Large
> > > patches should generally never get posted to lists. Those that
> > > want them will go get them from the web somewhere or FTP.
> >
> > Wrong.. patches should be posted/digested by list recipients. If
> > subscribers can't be bothered to read patches, they should reconsider
> > their initial application for acceptance to this list. I'll happily
> > de-uuencode gunzip and whatever, but I _don't like_ to have to chase
> > it down to see it. Please post patches.. _not_ URL's.
>
> I'd wager most people on this list do not have broadband access to the
> internet. Downloading large attachments takes time and in some cases
> (especially for people outside the US) money. The normal traffic on
> this list is large enough already without large attachments. If someone
> is interested enough in a patch they will download it from a URL.
I don't have a high bandwidth connection either. I still _very much_
prefer a large patch to an URL. Once it's loaded, (I'm patient) it
can sit and wait to be read/re-read. I'm a busy little penguin.. if
I have to go get it, I probably won't (unless it's really important)
simply because I have so many things I want to do that hours run out.
wrt money: I live in Germany!!.. and I still prefer to load the patch.
Heck, most of the time, there's more generic noise than patches by far.
:) send lotsa [mondo] patches. I _love_ patches.. especially the kind
it hurts to read.
-Mike
Mike Galbraith
> On Mon, Aug 21, 2000 at 08:35:43PM +0200, Mike Galbraith wrote:
> > Wrong.. patches should be posted/digested by list recipients. If
> > subscribers can't be bothered to read patches, they should reconsider
> > their initial application for acceptance to this list. I'll happily
> > de-uuencode gunzip and whatever, but I _don't like_ to have to chase
> > it down to see it. Please post patches.. _not_ URL's.
>
> Posting patches is generally a good thing (IMHO). Gziping them
> is just plain ugly (also IMHO).
Agree! (but gzip/bz2 of _hellatious big_ patches is ok imho;)
Brian Gerst
>
> On Mon, Aug 21, 2000 at 08:35:43PM +0200, Mike Galbraith wrote:
> > Wrong.. patches should be posted/digested by list recipients. If
> > subscribers can't be bothered to read patches, they should reconsider
> > their initial application for acceptance to this list. I'll happily
> > de-uuencode gunzip and whatever, but I _don't like_ to have to chase
> > it down to see it. Please post patches.. _not_ URL's.
>
> Posting patches is generally a good thing (IMHO). Gziping them
> is just plain ugly (also IMHO).
>
> moving files around (like my patch) don't really have to be posted
> to lkml. If I hadn't overssen the size of this patch, I would
> probably have put it on ftp.
Patches that just move files around are better posted as a script (with
mv commands) and a cleanup patch. Benefits are twofold: less bandwidth
and makes the real changes more apparent.
--
Brian Gerst
Christoph Hellwig
> > this is the same as moving drivers/joystick/*.c and drivers/usb/{evdev.c,
> > hid-debug.h, hid.c, hid.h, iforce.c, input.c, keybdev.c, mousedev.c, usbkbd.c,
> > usbmouse.c, wacom.c } to drivers/input
>
It's done to have all drivers that use the new input layer in one place.
>
> Why?
>
> I personally think this is a major step backwards. Moving things to be in
> the same directory just because it made some configuration easier.
The configuration problems were only a side-effect of having the input stuff
spread around in the tree.
> Nobody
> has explained to me why you couldn't just add one new configuration
> option, and make the affected drivers (in their regular places) dependent
> on that configuration option.
It could be done. But having related drivers in one place is the
cleaner solution (IMHO).
> Are all the SCSI drivers going to be under drivers/scsi/? No. The "normal"
> ones that don't have any better place for them are, but nobody has really
> suggested moving drivers/usb/storage around to another place just because
> it uses the SCSI layer.
Having the usb storage stuff in drivers/scsi seems not too ugly to me.
The general problem is (and it is already discussed in this thread) having
a proper scheme for drivers/. Currently there is no scheme.
IMHO there are three appronpinquate shemes:
1. Group drivers by the subsystem they belong to:
drivers/usb
drivers/scsi
drivers/ide
2. Group drivers by their interface and function. Examples:
drivers/input
drivers/sound
drivers/video
2. Group drivers by the bus they are on. Examples::
drivers/scsi (the real scsi drivers, not the scsi controller)
drivers/i2c (the i2c clients only)
and additionally:
driver/pci for pci drivers (not the pci subsystem!)
drivers/isa for isa drivers
drivers/ic for bus independend drivers
drivers/pseudo for pseudo devices
In my opinion 3.) is the best solution. But following at least one
of this alternatives strictly would make the tree a lot cleaner.
Christoph
--
Always remember that you are unique. Just like everyone else.
Jes Sorensen
Roman> I mostly agree for that, but we still have
Roman> arch/(m68k|ppc)/amiga, that could share some more
Roman> code. Currently it doesn't for several reasons. There is some
Roman> code for Amigas/Macs, that is truly machine specific, but used
Roman> on both m68k/ppc.
There is definately room for improvement there, we have come a fair
bit of the way though. I really need to get my A3K PSU switched to the
foul .us/.ca power system and bring it back up.
Jes
Arnaldo Carvalho de Melo
> 2. Group drivers by the bus they are on. Examples::
> drivers/scsi (the real scsi drivers, not the scsi controller)
> drivers/i2c (the i2c clients only)
>
> and additionally:
>
> driver/pci for pci drivers (not the pci subsystem!)
> drivers/isa for isa drivers
> drivers/ic for bus independend drivers
> drivers/pseudo for pseudo devices
>
> In my opinion 3.) is the best solution. But following at least one
> of this alternatives strictly would make the tree a lot cleaner.
Please note that there are drivers that support ISA, EISA and PCI
hardware, where would they be?
- Arnaldo
Linus Torvalds
On Mon, 21 Aug 2000, Christoph Hellwig wrote:
>
> It could be done. But having related drivers in one place is the
> cleaner solution (IMHO).
Indeed.
Which is why I want all the USB drivers in one place.
The USB interfaces are more likely to change than the keyboard interfaces.
When somebody changes how the USB urb's interact, I'd rather have all of
that under one tree.
Think about it another way: what about a driver that implements a
touchscreen and a framebuffer device, all in one (imagine a graphics chip
with built-in touch-screen support)? Do you want to split it up, so that
the touchscreen part is in "input", and the framebuffer part is in video?
Imagine the nastyness when these "two" drivers have to synchronize over
shared resources? (This, btw, is how the PC keyboard + PS/2 mouse driver
worked. Nightmare with shared spinlocks etc).
No. You don't split it up according to function. You split it up according
to other issues first, and _then_ you may sub-split it according to
function.
Linus
Philipp Rumpf
> Right now, drivers/net is pretty horrible, for example, and we've started
> separating things out a bit (ie drivers/net/tulip, drivers/net/pcmcia etc
> to get a better hierarchy). Same thing happened to drivers/block -
So we have drivers/net/pcmcia, but drivers/s390/net ?
> > There seem to be at least four criteria for subdirectories of drivers/:
> >
> > drivers/<function> (sound, net)
> > drivers/<interface> (char, block) (this isn't the same as function IMHO)
> > drivers/<bus-the-device-is-on> (usb, sbus)
> > drivers/<architecture> (s390, sgi)
>
> The last should probably be arch/<xxx>/drivers, but the other ones are
> either sensible (tons of bus-independent drivers) or conceptual UNIX
> things (char vs block).
Do we have _any_ bus-independent drivers ? There are things like the serial
driver which work with several busses, but they're not really independent in
the sense that you could add a new bus type without any modifications to the
drivers. I don't see a problem with putting those into drivers/common or
similar, especially since the drivers I'm aware of still need bus-specific
detection and initialization.
So wouldn't it be the cleanest thing to do to split up the serial driver, put
the generic parts into drivers/common/tty/serial.c, the PCI, ISAPnP, and GSC
things (mostly detection) into drivers/{pci,isapnp,gsc}/serial/serial.c, and
the architecture-dependent default ports into drivers/<arch>/serial/serial.c ?
Basically what I'm proposing is to put drivers into
drivers/<bus or arch>/<function or interface>/<name>.c
it's obvious which APIs a driver uses (the <bus>-specific interface as well as
the <function> abstraction), it helps keep #ifdef noise down (by splitting
things up into separate files), and there is a relatively low number of places
you have to look in for the driver you're searching.
Another advantage is you'd be able to see all pci drivers as drivers/pci/*/*.c,
and all network drivers as drivers/*/net/*.c (especially with the less popular
subsystems / busses, where reading the existing drivers is a good way to find
out API details).
Philipp
Linus Torvalds
On Mon, 21 Aug 2000, Philipp Rumpf wrote:
>
> Do we have _any_ bus-independent drivers ?
I don't think they make sense.
Yes, people always worry about common chips, but they don't happen all
that often in the end, and the pain from trying to share the code is
usually much MUCH bigger than the pain from just occasionally stealing
code from the other guy.
> So wouldn't it be the cleanest thing to do to split up the serial driver, put
> the generic parts into drivers/common/tty/serial.c, the PCI, ISAPnP, and GSC
> things (mostly detection) into drivers/{pci,isapnp,gsc}/serial/serial.c, and
> the architecture-dependent default ports into drivers/<arch>/serial/serial.c ?
The "common" part is drivers/char/. That makes sense to me, and I don't
think we have to come up with anything different. The other cases aren't
that big of a deal, they might as well just all go in drivers/serial:
unlike networking there aren't _that_ many serial chips out there.
The truly architecture-specific stuff (ie the ARM built-in serial stuff
etc) can go into arch/<xxx>/, but that wouldn't be a big thing either.
Let's not make this overly complex. The networking drivers have worked
pretty well with a single directory, and it makes it easy to find and grep
for things. Splitting things up _just_ for a nice hierarchy is a bad idea
too. It should be split up only when it actually starts getting crowded or
nasty for some other reason.
(There is a _lot_ to be said for the simplicity of just being able to do a
simple "grep xxxx *.c". Making people have to search for things usually
means something gets overlooked).
The current driver layout works pretty well in most cases, after all.
Linus
Christoph Hellwig
> Please note that there are drivers that support ISA, EISA and PCI
> hardware, where would they be?
It would go to drivers/ic for more or less bus-independad drivers.
If the PCI or ISA support takes some amount of extra work, only
the base driver would be in drivers/ic and the bus-dependend part
ind drivers/${BUS}. (yes, this is the NetBSD way ...)
Christoph
--
Always remember that you are unique. Just like everyone else.
Russell King
> The last should probably be arch/<xxx>/drivers, but the other ones are
> either sensible (tons of bus-independent drivers) or conceptual UNIX
> things (char vs block).
This is where I start rolling around all over the floor laughing at various
people...
Under pressure from others, I moved all the drivers I used to have in
arch/arm/drivers in the 2.0 trees into the generic drivers/* directories.
It now seems that these "others" were wrong for the ARM specific drivers.
I do now agree that all drivers should be placed in the drivers
subdirectory, and not anywhere under arch/*/drivers since, when some
people go around checking net device drivers, they ONLY look in
drivers/net, and nowhere else.
I'm even considering moving drivers/acorn/net to drivers/net/acorn (and
similarly for the others) so that when changes do occur, these drivers
also get a look in.
However, having said that, I think drivers/media is a good idea, but
do we have enough drivers or separation to warrant drivers/media/radio
and drivers/media/video? I'm willing to pick this change up btw, if no
one objects.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King r...@arm.linux.org.uk --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
Linus Torvalds
On Mon, 21 Aug 2000, Russell King wrote:
>
> I do now agree that all drivers should be placed in the drivers
> subdirectory, and not anywhere under arch/*/drivers since, when some
> people go around checking net device drivers, they ONLY look in
> drivers/net, and nowhere else.
That's a fairly good point - the fact that even if you came up with the
perfect hierarchy that explained where everything is sanely, it would suck
simply because people don't think that way.
In the end, we just have to balance the "everything in one place so that
it is easy to find" with "uhhuh, that 'ls' output is just too confusing,
and I can't seem to find my driver any more".
Linus
Alan Cox
> subscribers can't be bothered to read patches, they should reconsider
> their initial application for acceptance to this list. I'll happily
> de-uuencode gunzip and whatever, but I _don't like_ to have to chase
> it down to see it. Please post patches.. _not_ URL's.
For anything that isnt small, post URLS.
You might have a dual E3 into your backroom but most people dont
Philipp Rumpf
> On Mon, 21 Aug 2000, Philipp Rumpf wrote:
> >
> > Do we have _any_ bus-independent drivers ?
> I don't think they make sense.
>
> Yes, people always worry about common chips, but they don't happen all
> that often in the end, and the pain from trying to share the code is
> usually much MUCH bigger than the pain from just occasionally stealing
> code from the other guy.
So you think it's a good thing we have 5 serial drivers rather than one, and
it'd be a good thing to split up the one we have into several drivers again ?
I think what might be saving us right now is that there is only one widely-used
bus architecture (PCI and it's derivatives/predecessors), so no-one is going to
implement conflicting new features in both parts of a split driver.
> > So wouldn't it be the cleanest thing to do to split up the serial driver, put
> > the generic parts into drivers/common/tty/serial.c, the PCI, ISAPnP, and GSC
> > things (mostly detection) into drivers/{pci,isapnp,gsc}/serial/serial.c, and
> > the architecture-dependent default ports into drivers/<arch>/serial/serial.c ?
> The "common" part is drivers/char/. That makes sense to me, and I don't
> think we have to come up with anything different. The other cases aren't
> that big of a deal, they might as well just all go in drivers/serial:
> unlike networking there aren't _that_ many serial chips out there.
I don't think "there aren't going to be a great many file in this directory"
is really a good argument against creating a directory, except for the very
special case that there would be no files at all in it.
> The truly architecture-specific stuff (ie the ARM built-in serial stuff
> etc) can go into arch/<xxx>/, but that wouldn't be a big thing either.
I disagree with the idea of putting drivers into arch/, even if they are
completely architecture-dependent; they still could be instructive to
authors of new drivers.
> Let's not make this overly complex. The networking drivers have worked
"a network driver can be in arch/*/drivers/net/*.c, or it can be in
drivers/*/net/*.c, or it can be in drivers/net/*.c, or it can be in
drivers/net/*/*.c" is complex.
"a network driver can be in drivers/*/net/*.c" isn't.
> pretty well with a single directory, and it makes it easy to find and grep
> for things. Splitting things up _just_ for a nice hierarchy is a bad idea
Easy for those who already have a pretty good idea where things are, yes.
I would assume that most people who will ever hack Linux haven't started to
do so yet, though.
> too. It should be split up only when it actually starts getting crowded or
> nasty for some other reason.
In the specific case of the serial driver, I think 5700 lines, many of them
in bus-specific code, qualify as "crowded".
> (There is a _lot_ to be said for the simplicity of just being able to do a
> simple "grep xxxx *.c". Making people have to search for things usually
> means something gets overlooked).
And you are implying drivers in arch/<arch>/drivers wouldn't be overlooked ?
> The current driver layout works pretty well in most cases, after all.
It works pretty well for people who've used it for more than five years, but
that's not really a surprise. In my very limited experience it's confusing
to new users though.
Philipp
Alan Cox
> > usually much MUCH bigger than the pain from just occasionally stealing
> > code from the other guy.
>
> So you think it's a good thing we have 5 serial drivers rather than one, and
> it'd be a good thing to split up the one we have into several drivers again ?
We have architecture specific drivers. We have nice ones in places too. They
work very well when the hardware in question requires a common and complex
set of interactions to make it work
Things like the Z85x30 chips, the 16x50 UART etc.
Alan
Pauline Middelink
> > I'd rather not have the "video4linux" there - it doesn't make sense to me
> > except as a group name. But perhaps a plain "drivers/radio" thing?
> > Possibly under a "drivers/media" hierarchy?
>
> drivers/media/video drivers/media/radio would work yes
>
> The radio and video stuff belongs at least in proximity since there are devices
> heavily involved in doing both and they use the same core code and API (a
> radio is a TV with no picture to Linux)
A few months ago I had a patch doing just that, although it
created drivers/v4l en drivers/v4l/radio. Shall I rework it?
Met vriendelijke groet,
Pauline Middelink
--
PGP Key fingerprint = DE 6B D0 D9 19 AD A7 A0 58 A3 06 9D B6 34 39 E2
For more details look at my website http://www.polyware.nl/~middelink
Linus Torvalds
On Mon, 21 Aug 2000, Philipp Rumpf wrote:
> On Mon, Aug 21, 2000 at 12:02:03PM -0700, Linus Torvalds wrote:
> >
> > Yes, people always worry about common chips, but they don't happen all
> > that often in the end, and the pain from trying to share the code is
> > usually much MUCH bigger than the pain from just occasionally stealing
> > code from the other guy.
>
> So you think it's a good thing we have 5 serial drivers rather than one, and
> it'd be a good thing to split up the one we have into several drivers again ?
Probably.
Which does not mean that we should just duplicate all the code. The same
way we don't duplicate the whole TCP/IP stack for each network card
driver. There are tons of common issues in serial cards, and it's probably
a good idea to have common code. But you should not take it too far.
I think the current serial.c is starting to be a major mistake. That one
driver tries to handle everything from the original 16450 all the way up
to serial multi-port cards that happen to just be multiple 16550's with
some tweaks. As a result, the driver is quite complex and huge and is a
mess of #ifdef CONFIG_xxx.
A lot of serial.c is actually completely hardware-independent, and
serial.c in many ways is already "two drivers", in that it both knows how
to handle the low-level hardware AND it knows how to handle the
higher-level issues. And I don't think it would be bad to split it up some
more.
I would not be unhappy to have separate drivers for different chipsets,
and even if you want to have the same driver for a 16450 and a 16550 (they
_are_ quite close, after all), it's not clear that it makes sense to do
the same thing for the multiport things etc.
> I think what might be saving us right now is that there is only one widely-used
> bus architecture (PCI and it's derivatives/predecessors), so no-one is going to
> implement conflicting new features in both parts of a split driver.
And this is not going to change. Everything but PCI is dead, and there
isn't going to be multiple different buses. Sure, we'll have some serial
new-generation stuff, and we'll continue to have things like USB, but I'm
not worried about having the same chip on different buses. It'
s a thing of the past.
> I don't think "there aren't going to be a great many file in this directory"
> is really a good argument against creating a directory, except for the very
> special case that there would be no files at all in it.
I think you're wrong.
Logical naming and hierarchy are only helpers. If they lead to people
finding the files more quickly and understanding them better, they are
doing their job.
If hierarchy leads to having to look more places, think about it more, and
just more work, that hierarchy is BAD. It doesn't matter if it is logical
or not. It sucks. It just ends up being in your way.
We could create a subdirectory for each driver. In some cases we _do_
that (tulip and ide come to mind). But in the end, it should be done only
when it clarifies things, not just because somebody thinks it "ought" to
be that way.
And "there aren't going to be many files in this directory" is an argument
against it. It means that the directory doesn't end up clarifying things
very much at all.
Linus
Alan Cox
> to serial multi-port cards that happen to just be multiple 16550's with
> some tweaks. As a result, the driver is quite complex and huge and is a
> mess of #ifdef CONFIG_xxx.
There are two or three cards that are well weird - but trying to maintain
a seperate driver for that would be a real nightmare. Possibly the access
functions need more abstraction but its pretty well done as is
> to handle the low-level hardware AND it knows how to handle the
> higher-level issues. And I don't think it would be bad to split it up some
> more.
generic_serial.c - mission already in progress for some cards.
Brendan Cully
> > Let's not make this overly complex. The networking drivers have worked
>
> "a network driver can be in arch/*/drivers/net/*.c, or it can be in
> drivers/*/net/*.c, or it can be in drivers/net/*.c, or it can be in
> drivers/net/*/*.c" is complex.
>
> "a network driver can be in drivers/*/net/*.c" isn't.
After struggling with this problem for a while in my general archive
tree, I threw up my hands and created a bunch of symlinks. What about
something like this:
arch/net -> net/arch
That way you can work with your source where you want it and random
people looking for stuff will also tend to find it... that is the
symlinks serve as nothing more than reminders for people updating
particular sections of the kernel...
--
Don't make Godzilla mad!
Franz Sirl
> On Mon, 21 Aug 2000, Arjan van de Ven wrote:
> > Then can you tell me why you rejected my (minimal) patch that did exactly
> > that?
Minimal means moving input.c, *dev.c and related configury into drivers/char?
That is the relevant part for me and would be good enough.
> Probably because I get too much email, and because I hadn't realized how
> much email the whole input thing would end up generating..
Heh, me neither :-). But it seems to be a quite fruitful discussion.
> > Or should I resend it again?
>
> Please do.
Please CC me on the patch if possible.
Thanks,
Franz.
Vojtech Pavlik
> Indeed.
>
> Which is why I want all the USB drivers in one place.
>
> The USB interfaces are more likely to change than the keyboard interfaces.
> When somebody changes how the USB urb's interact, I'd rather have all of
> that under one tree.
>
> Think about it another way: what about a driver that implements a
> touchscreen and a framebuffer device, all in one (imagine a graphics chip
> with built-in touch-screen support)? Do you want to split it up, so that
> the touchscreen part is in "input", and the framebuffer part is in video?
> Imagine the nastyness when these "two" drivers have to synchronize over
> shared resources? (This, btw, is how the PC keyboard + PS/2 mouse driver
> worked. Nightmare with shared spinlocks etc).
>
> No. You don't split it up according to function. You split it up according
> to other issues first, and _then_ you may sub-split it according to
> function.
Ok, lets then move the input.c, mousedev.c, evdev.c, keybdev.c and joydev.c to a
common directory (be it drivers/input, drivers/char, drivers/char/input
or whatever then). Moving just input.c doesn't help anything.
I don't mind the drivers being sorted by the bus the interface (bus)
they live on (gameport / usb / serial port / whatever) or by the
interface they provide (scsi / input / network / whatever). Both have
their logic. I believe the later is nicer, though.
Also, I doubt the usb interface is less stable than the input one, so I
really believe both the choices are equal.
However, if now more than just the usb drivers use the mousedev, evdev,
keybdev and joydev, and these (input -> chardevice) drivers don't live
on usb or provide usb, they should be moved out of the usb dir to be
accessible by others even when CONFIG_USB is not set.
input.c and the *dev.c files need to live in a separate directory or at
least in a directory that is not dependent itself on any config option
(drivers/char for example).
So: would you accept a patch that does this? I suppose yes. Should the
destination be drivers/char? I suppose yes. Good. By the way, we are
moving these files to a directory named by what they provide. (The
opposite of the usb approach). Not that I mind ...
--
Vojtech Pavlik
SuSE Labs
Philipp Rumpf
> On Mon, 21 Aug 2000, Philipp Rumpf wrote:
> > On Mon, Aug 21, 2000 at 12:02:03PM -0700, Linus Torvalds wrote:
> > I think what might be saving us right now is that there is only one widely-used
> > bus architecture (PCI and it's derivatives/predecessors), so no-one is going to
> > implement conflicting new features in both parts of a split driver.
>
> And this is not going to change. Everything but PCI is dead, and there
> isn't going to be multiple different buses. Sure, we'll have some serial
> new-generation stuff, and we'll continue to have things like USB, but I'm
> not worried about having the same chip on different buses. It'
> s a thing of the past.
Possible. It's also possible people will go back to having many protocols, if
only because it's just another few K of firmware ROM on the device side and the
fibre connection is physically identical.
> > I don't think "there aren't going to be a great many file in this directory"
> > is really a good argument against creating a directory, except for the very
> > special case that there would be no files at all in it.
>
> I think you're wrong.
>
> Logical naming and hierarchy are only helpers. If they lead to people
> finding the files more quickly and understanding them better, they are
> doing their job.
> If hierarchy leads to having to look more places, think about it more, and
According to my proposal, we would end up having all network drivers in
drivers/*/net/*.
Currently we have arch/*/drivers/net/*, drivers/net/*, drivers/net/*/*, and
drivers/*/net/*.
> just more work, that hierarchy is BAD. It doesn't matter if it is logical
> or not. It sucks. It just ends up being in your way.
I agree with the general statement. I also think it applies to the current
hierarchy more strongly than to the proposed new hierarchy. The current
hierarchy isn't logical, but it also doesn't give you a low number of places
to look in for drivers. My opinion about the next point should be pretty
obvious, and I do believe it is getting in the way of people actually trying
to read some drivers.
> We could create a subdirectory for each driver. In some cases we _do_
> that (tulip and ide come to mind). But in the end, it should be done only
> when it clarifies things, not just because somebody thinks it "ought" to
> be that way.
Just to avoid misunderstandments, I never proposed creating a directory for
each driver. I agree it's a bad idea.
> And "there aren't going to be many files in this directory" is an argument
> against it. It means that the directory doesn't end up clarifying things
> very much at all.
I would say drivers/s390/net and drivers/s390/misc are good directories.
They clarify things. Most people just couldn't care less for them, and
those people can safely ignore all of drivers/s390. Most people don't care
for sbus, acorn, or sgi, either. some weird embedded people don't care
about PCI. Most people don't care about weird embedded people's devices.
Philipp
Linus Torvalds
On Mon, 21 Aug 2000, Philipp Rumpf wrote:
>
> > If hierarchy leads to having to look more places, think about it more, and
>
> According to my proposal, we would end up having all network drivers in
> drivers/*/net/*.
But even that isn't enough, as shown by the tulip driver: basically even
the regular PC drivers are available in so many different setups that
you'd still want sub-hierarchies.
(drivers/pc/ would end up being about 99% of the drivers, with the rest
being just smatterings here and there).
> I would say drivers/s390/net and drivers/s390/misc are good directories.
I would not disagree entirely. At the same time, there would be advantages
to arch/s390/drivers too. Especially if most people aren't that interested
in them - keep them out of the way.
Keeping them out of the way is bad at times (ie those times when changes
are made that affect everybody). But at other times it would be exactly
what you want. Not polluting the namespace with stuff you don't want or
need is nice.
What I'm saying is that it's not a case of "this is the right solution".
I think drivers/input _is_ a good solution. I think it sucks as a solution
if it implies moving all the drivers that need it into the same place, but
I think it's potentially the right answer if it's localized to the "core
input handling routines" and people see it that way (kind of the same way
drivers/pci works - not all pci drivers are there, but it is a good way to
partition the _generic_ issues about PCI somewhere which is neutral wrt
what the driver actually ends up doing).
But other issues, like how to move things around.. I'm not going to make
that choice as long as it's not the "obviously right one". As long as it's
not clear what the best choice is, the best bet is always "do as little as
possible, and nothing more".
Linus
Kai Henningsen
> > I'd rather not have the "video4linux" there - it doesn't make sense to me
> > except as a group name. But perhaps a plain "drivers/radio" thing?
> > Possibly under a "drivers/media" hierarchy?
>
> drivers/media/video drivers/media/radio would work yes
In that case, you could also have drivers/media/sound there.
Do we have anything else that's related to multimedia? Current frame
buffer devices probably don't count.
Another thing that definitely makes sense is distinguishing by type of
kernel-internal interface. net vs. isdn vs. char vs. block is certainly an
example of that.
MfG Kai
Theodore Y. Ts'o
From: Linus Torvalds <torv...@transmeta.com>
I would not be unhappy to have separate drivers for different chipsets,
and even if you want to have the same driver for a 16450 and a 16550 (they
_are_ quite close, after all), it's not clear that it makes sense to do
the same thing for the multiport things etc.
Well, the amount of code which changes between 16450 and 16550 is less
than 50 lines of code (out of 5700).
The amount of code which is multiport specific is about 100 lines of
source (again, out of 5700 --- or about 2% of the code). The reason why
we have the #ifdef's is because there are some inline functions which
get included a second time when we compile in the multiport code, so it
makes a pretty significant difference to the object size.
Of course, on modern architectures it's not clear the inline functions
are worth it, so I'll likely make that go away post 2.4.
Actually the largest chunk of code in there is the PCI/ISA PNP support
--- over 1500 LOC. But if you think PCI is the "privileged bus",
separating it out doesn't necessarily make that much sense.
- Ted
Vojtech Pavlik
> And "there aren't going to be many files in this directory" is an argument
> against it. It means that the directory doesn't end up clarifying things
> very much at all.
I have 63 .c files in the drivers/input directory in the linux-console CVS.
Some more will be added later. Is that enough? IMHO it groups together
stuff that belongs together. But opinions vary.
--
Vojtech Pavlik
SuSE Labs
Paul Mackerras
> I think drivers/input _is_ a good solution.
So, do you think the input layer is a good solution generally?
Should PC keyboards and mice go through it, for example?
Or is it unnecessary extra complication?
There is a push on to make ADB keyboards and mice go through the input
layer in the PPC port, but no-one has explained to me what we would
gain from that.
Paul.
alme...@lrc.di.epfl.ch
Linus Torvalds wrote:
> In the end, we just have to balance the "everything in one place so that
> it is easy to find" with "uhhuh, that 'ls' output is just too confusing,
> and I can't seem to find my driver any more".
I think there is value in having everything under drivers/... With
drivers/<bus>, we can already cover most of the architecture-specific
bits. Maybe just a few more bus types are needed - e.g. many "system on
a chip" design families have some tiny little bus and all the devices
there are rather unique and may have a lot of shared resources.
On the other hand, drivers/<function> makes sense for generic drivers
(e.g. drivers/char/mem.c) and those supporting many buses. So perhaps a
chipset that is used on many platforms should be split into the bus
interfaces in drivers/<bus> and the portable part in drivers/<fn> ?
This would probably require include/drivers or such, to avoid
cluttering include/linux with tons of additional "internal" files.
Also, drivers/<bus> should probably be reserved for drivers for the bus
itself, with the device drivers in drivers/<bus>/<fn>, or drivers/pci
would look a little nasty ;-)
Furthermore, if a driver starts is existence in drivers/<bus>, and then
turns out to be useful on other buses too, it would have to be split.
This would be a departure from the current implicit assumption that you
pick "The Right Place" once and forever. It would also make it harder
to port somebody else's driver to a second bus. But it would limit code
replication.
Does this sound reasonable ?
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH werner.al...@ica.epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
Jes Sorensen
>> So you think it's a good thing we have 5 serial drivers rather than
>> one, and it'd be a good thing to split up the one we have into
>> several drivers again ?
Alan> We have architecture specific drivers. We have nice ones in
Alan> places too. They work very well when the hardware in question
Alan> requires a common and complex set of interactions to make it
Alan> work
Alan> Things like the Z85x30 chips, the 16x50 UART etc.
At least for some of these drivers, they could be merged in a nice
way. Some of them were not originally written as individual drivers
because there was a real need for it (I can claim this because I made
this mistake myself in the past).
Jes
Linus Torvalds
On Tue, 22 Aug 2000, Paul Mackerras wrote:
> Linus Torvalds writes:
>
> > I think drivers/input _is_ a good solution.
>
> So, do you think the input layer is a good solution generally?
> Should PC keyboards and mice go through it, for example?
> Or is it unnecessary extra complication?
I think it might be a good idea in a perfect world.
However, it's really hard to make that concept do the right thing for
serial mice, for example. Which in my opinion waters down the advantages
of the input approach quit a lot.
Basically, because we cannot reasonably do a good job for serial mice,
we'll always be in the situation that the X server needs to be able to
handle different mice. Which in my opinion makes it redundant in the
kernel: while I know that things like GPM etc use mouse devices directly,
I'm personally convinced that in the bigger picture the only thing that
really matters is X.
And X handles multiple input devices quite nicely, these days. That didn't
use to be the case. So the advantage of having an input layer in the
kernel is greatly diminished - and basically nonexistent if X still has to
be able to do different mice.
> There is a push on to make ADB keyboards and mice go through the input
> layer in the PPC port, but no-one has explained to me what we would
> gain from that.
Quite frankly, I think that input to a large degree was a thing where the
argument for it has gone away. I suspect the GGI people are the only ones
who _really_ feel they have to have it.
Linus
Linus Torvalds
On Tue, 22 Aug 2000, Vojtech Pavlik wrote:
> On Mon, Aug 21, 2000 at 02:01:59PM -0700, Linus Torvalds wrote:
>
> > And "there aren't going to be many files in this directory" is an argument
> > against it. It means that the directory doesn't end up clarifying things
> > very much at all.
>
> I have 63 .c files in the drivers/input directory in the linux-console CVS.
> Some more will be added later. Is that enough? IMHO it groups together
> stuff that belongs together. But opinions vary.
Hey, move a few drivers from drivers/scsi there too, and you'll have a few
hundred .c files there.
If you didn't guess already, I disagree strongly with people moving USB
drivers around. I don't see the logic in it, AT ALL.
The USB drivers use "kmalloc()" to allocate memory. Does that mean that
they are part of memory management, and we should move them to mm/drivers?
Obviously not. Nobody would be stupid enough to really argue that. Yet
people seem to argue that because some USB drivers use features offered by
the input layer, they should be "input drivers". Not so.
Mike Galbraith
> > Wrong.. patches should be posted/digested by list recipients. If
> > subscribers can't be bothered to read patches, they should reconsider
> > their initial application for acceptance to this list. I'll happily
> > de-uuencode gunzip and whatever, but I _don't like_ to have to chase
> > it down to see it. Please post patches.. _not_ URL's.
>
> For anything that isnt small, post URLS.
>
> You might have a dual E3 into your backroom but most people dont
I have plain isdn. But no matter. All the replies I got were pro URL,
I'll cope ;-)
-Mike
Rogier Wolff
> I would not be unhappy to have separate drivers for different chipsets,
> and even if you want to have the same driver for a 16450 and a 16550 (they
> _are_ quite close, after all), it's not clear that it makes sense to do
> the same thing for the multiport things etc.
Linus, when I got my first "speed4" card, (PCI, single chip quad uart
based card), I just typed a few setserial commands, and had the card
running.
It is the 16550 driver that handles this chip. 8250, 16450 16550 are
all ISA. Now we have a chip that's two levels away (PCI, quad) getting
handled by the same driver.
It really would help reduce bugs if there were more shared code.
If you split drivers, the number of users will drop. So less bugs get
found.
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* Common sense is the collection of *
****** prejudices acquired by age eighteen. -- Albert Einstein ********
Eric S. Raymond
> It really would help reduce bugs if there were more shared code.
>
> If you split drivers, the number of users will drop. So less bugs get
> found.
Linus, I think this is an excellent point and one you should consider.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"If I must write the truth, I am disposed to avoid every assembly
of bishops; for of no synod have I seen a profitable end, but
rather an addition to than a diminution of evils; for the love
of strife and the thirst for superiority are beyond the power
of words to express."
-- Father Gregory Nazianzen, 381 AD
Vojtech Pavlik
> I think it might be a good idea in a perfect world.
>
> However, it's really hard to make that concept do the right thing for
> serial mice, for example. Which in my opinion waters down the advantages
> of the input approach quit a lot.
Well, it depends on what you mean by 'the right thing'. I have an
in-kernel serial mouse driver, that easily handles all GPM-supported
serial mice (with a small daemon to do the autodetection / init /
userconfig / holding the devices open with an N_MOUSE ldisc), all in
about 290 lines of code. It uses the input interface, yes. It performs
better (updates/second) for some (all MSC, some Logitech) mice, though
not because of being in kernel.
I didn't submit it [yet], because the issue of whether serial mice
should be handled in the userland (GPM, and X, with sharing problems for
newer mice) or kernel was usually a cause of vast disagreement.
> Basically, because we cannot reasonably do a good job for serial mice,
> we'll always be in the situation that the X server needs to be able to
> handle different mice. Which in my opinion makes it redundant in the
> kernel: while I know that things like GPM etc use mouse devices directly,
> I'm personally convinced that in the bigger picture the only thing that
> really matters is X.
It's probably true, and it's also true X will very likely have all the
serial/ps2/busmouse/whatever mouse drivers always in it, if not for
Linux, then for other OSes, anyway.
> And X handles multiple input devices quite nicely, these days. That didn't
> use to be the case. So the advantage of having an input layer in the
> kernel is greatly diminished - and basically nonexistent if X still has to
> be able to do different mice.
Well, it still makes keyboard and joystick drivers much simpler.
> > There is a push on to make ADB keyboards and mice go through the input
> > layer in the PPC port, but no-one has explained to me what we would
> > gain from that.
>
> Quite frankly, I think that input to a large degree was a thing where the
> argument for it has gone away. I suspect the GGI people are the only ones
> who _really_ feel they have to have it.
Maybe. I personally never liked GGI much. In my opinion it was much too
complex for a simple (and impossible with the graphics part of it, too),
task.
Well, even the X people seemed to like the input layer. I've discussed
it with Jim Gettys for example and found out this is very similar to how
he wanted the things to be when X was born.
And game developers like it too, for example Sam Lantinga of Loki said
something like (quotation far from exact) 'it's much easier to write
input-related stuff in Linux than in Windows, I really enjoyed it'.
And distribution makers like it. Once fully implemented, it could remove
most of the huge 'select your mouse type and model' menus in the
installers, a point where most users are perpetually making the wrong
choice.
It's a level of abstraction that makes writing the low-level drivers
easier. Makes the drivers shorter, too. Application writing easier. I
believe that's good.
--
Vojtech Pavlik
SuSE Labs
David Woodhouse
> how to handle the low-level hardware AND it knows how to handle the
> higher-level issues. And I don't think it would be bad to split it up
> some more.
The problem is that if you start to decouple the chipset driver from the
code which knows how to access the chip, you end up with lots of horrible
indirect function calls in the inner loops. This isn't really going to help
improve performance - and the serial driver has one of the biggest problems
w.r.t latency already.
I figure I can get away with it for the MTD code (see the interaction
between the CFI chipset code and the 'map' modules) because flash is
generally slow as hell anyway, but for serial it's just not that feasible.
We have the same problem when readb() becomes something other than a
#define or inline function.
One possibility for serial might be to reuse the generic chipset code in
source form rather than object form - i.e. define serial_readb() et al.
functions for your particular board/bus/mapping and then
#include <generic_16550.c>. That's quite ugly though.
--
dwmw2
Philipp Rumpf
>
> torv...@transmeta.com said:
> > A lot of serial.c is actually completely hardware-independent, and
> > serial.c in many ways is already "two drivers", in that it both knows
> > how to handle the low-level hardware AND it knows how to handle the
> > higher-level issues. And I don't think it would be bad to split it up
> > some more.
>
> The problem is that if you start to decouple the chipset driver from the
> code which knows how to access the chip, you end up with lots of horrible
> indirect function calls in the inner loops. This isn't really going to help
indirect function calls aren't that expensive anymore. especially when you
consider CPUs at 500 MHz and PCI still running at 33 MHz, a few cycles for
an indirect call aren't all that terrible.
> improve performance - and the serial driver has one of the biggest problems
> w.r.t latency already.
The serial driver suffers from other drivers leaving interrupts disabled for
too long. Making the calls indirect wouldn't be a problem (except on old
386-class machines, that is).
> We have the same problem when readb() becomes something other than a
> #define or inline function.
It is in generic alpha kernels.
> One possibility for serial might be to reuse the generic chipset code in
> source form rather than object form - i.e. define serial_readb() et al.
> functions for your particular board/bus/mapping and then
> #include <generic_16550.c>. That's quite ugly though.
yuck.
Philipp
Alan Cox
> I'm personally convinced that in the bigger picture the only thing that
> really matters is X.
For those of us working on embedded platforms X is not the answer. In fact
X is a cause of much mirth merriment and laughter when you try and mix even
the tinyX works memory foot print with such devices.
(The 'but they get bigger' argument doesnt work too. In the PDA work right now
sure but in general - no. They don't get bigger they get -cheaper-, if your
print manager box uses 8Mb less ram it costs less to make and you undercut
the other guys)
Ironically, the input device isnt what you want for an embedded box either. Its
too generic and it increases the footprint again. Handling just the devices
actually there in whatever isnt X11 will do fine.
> And X handles multiple input devices quite nicely, these days. That didn't
> use to be the case. So the advantage of having an input layer in the
> kernel is greatly diminished - and basically nonexistent if X still has to
> be able to do different mice.
Who managers which mice, keyboards and screens go to which display ? Putting
multiple monitors/keyboards/mice on a pc is becoming trendy. This is the one
thing I think input helps with a lot (we also have to fix the current
virtual console model which has a very 'one keyboard, one screen. one user'
model for things like security.
Alan
Rogier Wolff
>
> torv...@transmeta.com said:
> > A lot of serial.c is actually completely hardware-independent, and
> > serial.c in many ways is already "two drivers", in that it both knows
> > how to handle the low-level hardware AND it knows how to handle the
> > higher-level issues. And I don't think it would be bad to split it up
> > some more.
>
> The problem is that if you start to decouple the chipset driver from the
> code which knows how to access the chip, you end up with lots of horrible
> indirect function calls in the inner loops. This isn't really going to help
> w.r.t latency already.
>
> between the CFI chipset code and the 'map' modules) because flash is
> generally slow as hell anyway, but for serial it's just not that feasible.
>
> #define or inline function.
>
> source form rather than object form - i.e. define serial_readb() et al.
> functions for your particular board/bus/mapping and then
> #include <generic_16550.c>. That's quite ugly though.
It is not quite that bad.
We need an architecture similar to the net devices.
tty layer just need a few callbacks.
The tty layer needs to set termios, and write characters. tty layer
should copy these into the circular buffer without leaving that to the
individual driver. (*) Usually the interrupt routine will just empty
the circular buffer.
The serial driver needs to report "here is another char". That might
be an inline function.
The serial driver also should be able to report "here is a bunch of
chars in IO memory". There are a few more possibilities.
Initial implementation of the improved tty layer may implement that
the trivial way, but it can be enormously optimized almost trivially
too.
Now, currently, most of the recieve handling is postponed to the
bottom half. I question the usefulness of this optimization. It
certainly adds latency. What is it that needs to be done on reception
of a few chars? Copy the data to userspace, and hit the waitq of the
process that's waiting for data. If you want to prevent the races, use
a kernel-space circular buffer, and do the processing (copy to
userspace) in the context of the wokenup process.
Similarly, a line discipline like "ppp" will just scan the chars for
the end-of-packet char while copying the data to the reception skbuf.
It's not as if this is highly time-consuming: we already have to copy
the data somewhere, so that part is "unavoidable". And the possibly
more expensive part is the "packet recieved". We already call that
from the interrupt routine many more times per second for the 100mbps
ethernet cards.
Oh, with DCD and stuff, we also need a callback for "modem signals
changed". What to do with that (i.e. unblock someone in open, or
hangup the users shell) should be the tty layer's choice. Not
something that is done in the hardware driver.
A driver would implement:
open /* Just the bare "tell the hardware we're now
interested in various things like CD. */
close /* nobody interested anymore. Disable interrupts
for this device. */
get_modemsignals /* report the modem signals */
set_modemsignals /* Set the modem signals */
tx_buffer_nonempty /* Call to use when tx buffer becomes
nonempty */
change_termios /* termios changed. returns termios settings NOT
implemented in the hardware. */
and performs callbacks from the interrupt routine for:
- reception of characters
- modem status change
Getting a callback for a modem status change (e.g. CD dropped) while
that is currently ignored is not a problem. This doesn't happen that
often.
tx_buffer_nonempty will, on some chips (e.g. 16550 and compatible)
just enable tx buffer empty interrupts. On others it may have to push
a buffer full of data onto the card (for example, sx doesn't interrupt
for tx_empty unless the buffer was previously filled).
The standard open routine will all the open routine followed by
set_modemsignals to set rts/dtr. Next, get_modemsignals is called to
check for DCD.
This certainly CANNOT happen for 2.4, and it's a lot of work to get to
the level that we currently have with the current structuring.
generic_serial is a step in the right direction, but it certainly
isn't the best way to do things.
Roger.
(*) Just like filesystem or device drivers change file->ops to point
to their own "ops" structure, that is what a "super intelligent"
serial driver would do if it didn't want the automatic "write copies
into circular buffer". Or we could have a write routine anyway, which
most drivers wouldn't implement as they wanted the fallback
copy-to-circular buffer....
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* Common sense is the collection of *
****** prejudices acquired by age eighteen. -- Albert Einstein ********
Franz Sirl
>On Mon, Aug 21, 2000 at 08:34:01PM -0700, Linus Torvalds wrote:
> > > There is a push on to make ADB keyboards and mice go through the input
> > > layer in the PPC port, but no-one has explained to me what we would
> > > gain from that.
> >
> > Quite frankly, I think that input to a large degree was a thing where the
> > argument for it has gone away. I suspect the GGI people are the only ones
> > who _really_ feel they have to have it.
>
>Maybe. I personally never liked GGI much. In my opinion it was much too
>complex for a simple (and impossible with the graphics part of it, too),
>task.
>
>Well, even the X people seemed to like the input layer. I've discussed
>it with Jim Gettys for example and found out this is very similar to how
>he wanted the things to be when X was born.
>
>And game developers like it too, for example Sam Lantinga of Loki said
>something like (quotation far from exact) 'it's much easier to write
>input-related stuff in Linux than in Windows, I really enjoyed it'.
>
>And distribution makers like it. Once fully implemented, it could remove
>most of the huge 'select your mouse type and model' menus in the
>installers, a point where most users are perpetually making the wrong
>choice.
Yes, every PPC distribution maker I talked to liked it, and I guess the
benefits are even higher for distributions supporting multiple platforms.
>It's a level of abstraction that makes writing the low-level drivers
>easier. Makes the drivers shorter, too. Application writing easier. I
>believe that's good.
I wholeheartedly agree. Initially I entered this whole "input game" cause I
wanted to get rid of "I ruined my keyboard layout with tool xyz" reports on
PPC (not to talk about the "big USB disaster" in early 2.2) and took a look
at the "Linux keycodes" approach in usb/keybdev.c. But it soon appeared to
me that it would be just plain silly _not_ to use possibilities provided by
the input drivers.
- it factors out a lot of code (eg. it obsoletes adbmouse.c on PPC,
replaced with 5 lines of code)
- it's convenient for driver developers
- it's convenient for users (eg. one unified mouse protocol)
- it's very lightweight
Franz.
Vojtech Pavlik
Hi!
This sounds very very nice, almost unreal. Even for the USB modem /
serial drivers it'd make them much simpler and cleaner.
Vojtech
--
Vojtech Pavlik
SuSE Labs
Franz Sirl
>Ironically, the input device isnt what you want for an embedded box
>either. Its
>too generic and it increases the footprint again. Handling just the devices
>actually there in whatever isnt X11 will do fine.
Increases the footprint? I don't believe that. Eg. if you have any kind of
keyboard input, it's nearly impossible to get rid of pc_keyb.c right now
(embedded is PPC and ARM business) and it has ~1000 lines,
usbkbd.c+input.c+keybdev.c ends up with less code... :-).
Franz.
Bjorn Wesen
> We need an architecture similar to the net devices.
agree
> The tty layer needs to set termios, and write characters. tty layer
> should copy these into the circular buffer without leaving that to the
> individual driver. (*) Usually the interrupt routine will just empty
> the circular buffer.
I'd agree that the arch is very similar to net devices (network devices
are in fact nothing else than a very specific form of serial devices :).
BUT, by the same argument, the ol' circular buffer thingy needs to go as
well.
Example - our embedded CPU has full DMA to every I/O and the serial port
can easily do 1.8 megabaud and has a 6 megabaud mode as well. Trying to
get that to work with serial.c was a minor headache. Just because the PC
still has shit-for-serial-ports should not be a limitation to scalability.
My solution was to let the driver DMA directly into the tty flipbuf while
the sends still has to be copied into a buffer.
SOmething similar to the skb's would be preferable - so I can just take
write blocks and chain them into the DMA hardware. Incoming data can go
into "skb's" as well up to the tty.
My point is just that if we're going to go through the horror of
completely redesigning serial.c we might as well get rid of the "char by
char" mentality, at least not so that it limits the _fast_ ports out
there.
> Now, currently, most of the recieve handling is postponed to the
> bottom half. I question the usefulness of this optimization. It
> certainly adds latency. What is it that needs to be done on reception
> of a few chars? Copy the data to userspace, and hit the waitq of the
> process that's waiting for data. If you want to prevent the races, use
> a kernel-space circular buffer, and do the processing (copy to
> userspace) in the context of the wokenup process.
Forget the circular buffer and use a chain of buffers instead on the
incoming queue. A circular buffer is just a fixed buffer-chain of 1-byte
elements, but with an overflow headache and a flipping problem..
> It's not as if this is highly time-consuming: we already have to copy
> the data somewhere, so that part is "unavoidable". And the possibly
A line discipline doing raw tty I/O can do zero-copy, in the sense that
the serial driver on the receiving end gives away its received buffers to
the upper levels. Just like in the network stack.
> just enable tx buffer empty interrupts. On others it may have to push
> a buffer full of data onto the card (for example, sx doesn't interrupt
> for tx_empty unless the buffer was previously filled).
Just don't think all serial HW's do char-by-char or have buffers that go
empty.
-Bjorn
Rogier Wolff
Agreed.
Part of my suggestion is that there may be more than one "I got input"
routines.
Some devices may not be able to provide more than one char at a
time. Think 8250.
ser_got_one_char (inb (port->base + DATA));
Others like CD1864 may be able to provide us with a number of valid
chars before we read them from the data register:
nvc = inb (port->base + NR_VALID_CHARS);
ser_got_chars_in_one_ioreg (port->base + DATA, nvc);
I also have a driver that would need:
nchars = readb (port->base + CHARS_IN_BUFFER)
ser_got_chars_in_iomem (port->base + BUFFER, nchars);
You'r suggesting that you'd like to do:
nchars = readl (port->base + CUR_DMA_POINTER) - port->cur_buf;
ser_got_chars_in_mem (port->cur_buf, nchars);
port->cur_buf = kmalloc (BUFSIZE);
writel (port->base + CUR_DMA_POINTER, virt_to_bus (port->cur_buf));
Now having something like skbuffs internally may make more sense if
you think about passing those buffers around. Point is: the driver
shouldn't need to know.
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* Common sense is the collection of *
****** prejudices acquired by age eighteen. -- Albert Einstein ********
James Simmons
>Which is why I want all the USB drivers in one place.
>
>The USB interfaces are more likely to change than the keyboard
>interfaces. When somebody changes how the USB urb's interact, I'd rather
>have all of that under one tree.
Very good point here. I see this only true for USB and ADB devices. As for
regular joysticks, mice and keyboards this is not the case. Can those go
into new input directory.
>Think about it another way: what about a driver that implements a
>touchscreen and a framebuffer device, all in one (imagine a graphics chip
>with built-in touch-screen support)? Do you want to split it up, so that
>the touchscreen part is in "input", and the framebuffer part is in video?
>Imagine the nastyness when these "two" drivers have to synchronize over
>shared resources? (This, btw, is how the PC keyboard + PS/2 mouse driver
>worked. Nightmare with shared spinlocks etc).
Actually I have a situation like this. My SoundBlaster has a joystick port.
I use the analog joystick driver and the SB driver and they are completely
independent of each other. This problem is going to get worst. In the near
future you will see sound cards and video cards merge. IMO it is better to
split a driver up according to functionality. This is just my opinion and
it should be the choice of the driver writer if he/she wants a massive
single file that does everything for the hardware or a bunch of split
files each doing it's own functionality. In time the best design for that
peice of hardware will come out.
James Simmons
>> So, do you think the input layer is a good solution generally?
>> Should PC keyboards and mice go through it, for example?
>> Or is it unnecessary extra complication?
>
[snip]..
>Basically, because we cannot reasonably do a good job for serial mice,
>we'll always be in the situation that the X server needs to be able to
>handle different mice. Which in my opinion makes it redundant in the
>kernel: while I know that things like GPM etc use mouse devices directly,
>I'm personally convinced that in the bigger picture the only thing that
>really matters is X.
>
>And X handles multiple input devices quite nicely, these days. That
>didn't use to be the case. So the advantage of having an input layer in
>the kernel is greatly diminished - and basically nonexistent if X still
>has to be able to do different mice.
>
>Quite frankly, I think that input to a large degree was a thing where the
>argument for it has gone away. I suspect the GGI people are the only ones
>who _really_ feel they have to have it.
Reasons to support the input interface:
1) I don't know how well you understand X internals but X internals are
based around the concept of a input device. Allows for a much better
design for the X server.
2) We don't have to wait 6 months for XFree86 to actually support
the device. You have to admit kernel developement is 100 times faster
than XFree86 developement. Look at the video cards supported in
XF4.0. More cards are supported via fbdev than any other method with
XF4.0 Does XF4.01 even support USB mice and keyboards yet and how long
as USB been supported under linux?
3) Having X run on a embedded machine will never happen.
4) I see /dev/event like DRI. Think of computer games runing with OpenGL
under X windows. OpenGL has a side library called glut with has things
like joystick support. Which do you think will be faster? The OpenGL to
create a X network packet and send to the X server and wait for the X
server to process the packet. Or have the glut library directly access
/dev/event. For computer games, which drive the computer industry,
timing is critical. In this case the kernel manages the input resources
between OpenGL and X windows just like DRI manages the vidoe hardware
between X windows and OpenGL.
James Simmons
On Mon, 21 Aug 2000, Alan Cox wrote:
> > I'd rather not have the "video4linux" there - it doesn't make sense to me
> > except as a group name. But perhaps a plain "drivers/radio" thing?
> > Possibly under a "drivers/media" hierarchy?
>
> drivers/media/video drivers/media/radio would work yes
>
> The radio and video stuff belongs at least in proximity since there are devices
> heavily involved in doing both and they use the same core code and API (a
> radio is a TV with no picture to Linux)
I also like this. What do you think about having drivers/media/fbdev and
drivers/media/dri as well?
ty...@valinux.com
The problem is that if you start to decouple the chipset driver from the
code which knows how to access the chip, you end up with lots of horrible
indirect function calls in the inner loops. This isn't really going to help
improve performance - and the serial driver has one of the biggest problems
w.r.t latency already.
The serial driver uses inline functions with explicit case statements,
and before you condemn such tactics, I suggest you actually benchmark
things. As long as everything is in cache (as it is for any tight
loops), given modern CPU's with call stacks, even indirect function
calls are pretty much cheap compared to the time it takes for characters
to arrive. Certainly the amount of time it takes to execute the case
statement is very, very, small compared to the time it takes to do any
kind of serial I/O operation. (Remember, CPU's have been getting faster
and faster; serial speeds have stayed pretty much the same, or have at
most doubled or quadroupled over the past decade.)
Jim Gettys has a wonderful explanation of this effect in the X server.
It turns out that with branch predictions and the relative speed of CPU
vs. memory changing over the past decade, loop unrolling is pretty much
pointless. In fact, by eliminating all instances of Duff's Device from
the XFree86 4.0 server, the server shrunk in size by _half_ _a_
_megabyte_ (!!!), and was faster to boot, because the elimination of all
that excess code meant that the X server wasn't thrashing the cache
lines as much.
The bottom line is that our intuitive assumptions of what's fast and
what isn't can often be wrong, especially given how much CPU's have
changed over the past couple of years. For example, Rusty and I have
talked about this issue, and we have a sneaking suspicion that many of
the inline functions (yes, including in the serial driver) can and
should go away, and be turned into normal functions, for similar
reasons. Essentially, compared to cache misses, you can execute a
*large* number of instructions for "free".
- Ted
P.S. The latency problems of the serial driver are completely unrelated
to this issue. They are caused by (a) IDE (and other drivers) masking
interrupts for long periods of time, and (b) the serial driver batching
characters and only calling the line discpline every clock tick. This
behaviour can be turned off by using the command "setserial /dev/ttyS0
low_latency", which will increase the CPU overhead ---- on an 8250, if
you are receiving characters at 115200 bps, the line discpline code will
be called 11,520 times a second, instead of 100 times a second. But,
you will have a very low-latency driver. Of course, if you're reading
characters in cooked mode, this CPU time is basically completely
wasted.
Given that there are very few applications where latency actually
matters --- a well designed protocol like kermit, zmodem, or TCP use
windowing to avoid lockstep performance issues --- we ASYNC_LOW_LATENCY
isn't turned on by default.
ty...@valinux.com
From: R.E....@BitWizard.nl (Rogier Wolff)
The tty layer needs to set termios, and write characters. tty layer
should copy these into the circular buffer without leaving that to the
individual driver. (*) Usually the interrupt routine will just empty
the circular buffer.
Well, the high-level code can offer these services as an option, much
like the VFS layer offers various utility functions to the tty devices,
but not all low-level tty drivers will find this useful.
Now, currently, most of the recieve handling is postponed to the
bottom half. I question the usefulness of this optimization. It
certainly adds latency. What is it that needs to be done on reception
of a few chars? Copy the data to userspace, and hit the waitq of the
process that's waiting for data. If you want to prevent the races, use
a kernel-space circular buffer, and do the processing (copy to
userspace) in the context of the wokenup process.
It does *not* have to be postponed to the bottom half. Take a look at
the rocketport driver. Since it only gets characters out of a large
fifo every clock tick (the hardware doesn't support interrupts, since
for a large number of active ports, polling is more efficient), it
simply calls the line discpline directly.
As I explained earlier, the down side of this is that at 115200 bps, you
will be calling the line discpline 11,520 times a second. On a 40 MHz
386, this became a real bottleneck. On modern CPU's it's less of an
issue, but most of the time you don't care about latency anyway. That's
why I added ASYNC_LOW_LATENCY; it's now configurable whether you care
about latency or not.
Oh, with DCD and stuff, we also need a callback for "modem signals
changed". What to do with that (i.e. unblock someone in open, or
hangup the users shell) should be the tty layer's choice. Not
something that is done in the hardware driver.
That's something I want to do in 2.5 --- move all of the hangup
processing into the high-level tty drivers, instead of have it split
between the high and low-level tty drivers.
- Ted
ty...@valinux.com
From: Bjorn Wesen <bj...@sparta.lu.se>
Forget the circular buffer and use a chain of buffers instead on the
incoming queue. A circular buffer is just a fixed buffer-chain of 1-byte
elements, but with an overflow headache and a flipping problem..
Trust me, you don't want to re-invent BSD clists. They are a
performance disaster.
A line discipline doing raw tty I/O can do zero-copy, in the sense that
the serial driver on the receiving end gives away its received buffers to
the upper levels. Just like in the network stack.
I verymuch doubt that given all of setup overhead and general
hair/complexity necessary for zero-copy, that this would be useful *at*
*all* in any real-life application. The code is already optimized for
single-copy; given the relative speeds of serial transfer rates versus
memory copy speeds, this is a pointless optimization.
Linus Torvalds
On Tue, 22 Aug 2000, Eric S. Raymond wrote:
> Rogier Wolff <R.E....@BitWizard.nl>:
> > It really would help reduce bugs if there were more shared code.
> >
> > If you split drivers, the number of users will drop. So less bugs get
> > found.
>
> Linus, I think this is an excellent point and one you should consider.
It's a stupid lie, and one we should ignore at all times it comes up.
It is NOT true that "shared code means less bugs". People, wake up!
It's true that "simple and tested code means less bugs". And quite often,
code sharing will imply that the code gets (a) more complex and (b) has
cases that people who make changes will never be able to test.
No, I'm not saying that sharing is bad. Sharing is good. But anybody who
makes a blanket statement like "sharing reduces bugs" is full of crap.
Good and clear interfaces reduce bugs. Avoiding complexity reduces bugs.
Using your brain before you code something up reduces bugs.
But making a very complex driver that handles ten different variations on
the same hardware? No. That does _not_ reduce bugs. It's quite often more
efficient to have two people work on two drivers that are independent of
each other, than to have two persons working on the same driver. Alan put
it well at some point: the way to create working open source software is
to minimize the amount of communication needed.
Make good interfaces. THAT will reduce bugs.
Linus
Alan Cox
> drivers/media/dri as well?
You can put everything under there which doesnt help.
fbdev is under video now which seems sensible, if anything drm is a subdir
of that
Pauline Middelink
> On Mon, 21 Aug 2000 around 17:46:54 +0100, Alan Cox wrote:
> > > I'd rather not have the "video4linux" there - it doesn't make sense to me
> > > except as a group name. But perhaps a plain "drivers/radio" thing?
> > > Possibly under a "drivers/media" hierarchy?
> >
> > drivers/media/video drivers/media/radio would work yes
Well, for general consumption, the patch.
After patching there is a file called 'move-drivers' in
/drivers. Please run it so the actual drivers are moved
to their proper location.
The patch itself consists mainly of changing the
required Config.in and Makefile files.
Oh, I added 'source drivers/media/Config.in' to
every arch which already contained drivers/char,
since that is where these drivers come from afterall.
Met vriendelijke groet,
Pauline Middelink
--
PGP Key fingerprint = DE 6B D0 D9 19 AD A7 A0 58 A3 06 9D B6 34 39 E2
For more details look at my website http://www.polyware.nl/~middelink
Kai Henningsen
> Does this sound reasonable ?
Yes, but does it work in practice?
Let's try to make it in a set of rules.
1. General layout:
drivers/<bus> (PCI, USB) vs. drivers/<type> (net, block).
Subdirectories as necessary. Hierarchical subdirectories: step back and
see if you shouldn't introduce a new drivers subdir instead.
2. If it's something that drives a bus as such, it belongs in drivers/
<bus>.
3. If it's arch specific but you can't really point at a bus, take <arch>
or something like it as a bus name. (atari/amiga, for example? For s390,
you *could* use "channel".)
4. If it drives a specific kind of kernel interface instead of specific
hardware, it probably doesn't belong into drivers/ (vfs in fs/ or
networking in net/ for example).
5. If it drives something available on more than one bus (and you can
actually do that with a single driver), it belongs in drivers/<type>,
where type is usually a specific kind of kernel-internal interface (block,
char, net, say). Possibly something more specific according to rule 1.
6. If it drives something only available on a certain bus, you have the
option of having it under drivers/<bus> or drivers/<type>. drivers/<type>
may well be the better choice, so people looking for this type of driver
will find it, assuming the type isn't unique to your bus.
Hmm. That doesn't leave all that much under drivers/<bus>.
MfG Kai
Eric S. Raymond
> It is NOT true that "shared code means less bugs". People, wake up!
You've ignored what I see as Rogier's main point. It's not "shared
code means less bugs" per se, it's "shared code means better test
coverage".
Think of each user as testing testing a semi-random sample of the
driver's state space for correctness. Then coverage on each line of
driver code is proportional to the number of users per driver.
Sharing code is a way to increase the test population for the shared
parts, which increases expected test coverage on the shared parts,
which is good. It's especially good because the shared parts tend
to have subtler bug signatures than the unshared parts (data structure
corruption is harder to diagnose than a device lockup), so the better
test coverage happens exactly where it's most needed.
Clean APIs also reduce bugs, of course, but that effect is orthogonal
to the one Rogier was trying to describe. IMHO, we should strive for
both.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"...quemadmodum gladius neminem occidit, occidentis telum est."
[...a sword never kills anybody; it's a tool in the killer's hand.]
-- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),
Linus Torvalds
On Tue, 22 Aug 2000, Alan Cox wrote:
> > kernel: while I know that things like GPM etc use mouse devices directly,
> > I'm personally convinced that in the bigger picture the only thing that
> > really matters is X.
>
> For those of us working on embedded platforms X is not the answer. In fact
> X is a cause of much mirth merriment and laughter when you try and mix even
> the tinyX works memory foot print with such devices.
I agree - but the embedded market is completely different anyway, and
isn't interested in nice generalizations. In embedded products you know
exactly what your hardware is, and you code for it.
Linus
Linus Torvalds
On Tue, 22 Aug 2000, Bjorn Wesen wrote:
>
> SOmething similar to the skb's would be preferable - so I can just take
> write blocks and chain them into the DMA hardware. Incoming data can go
> into "skb's" as well up to the tty.
No. That is just horrible. What's so wrong with simple flip-buffers that
they wouldn't work for you? Simple, and you can fill them up as fast as
you can and then flip. Sure, if nobody reads the buffers fast enough
you'll have trouble, but that's independent of how you do things. It's a
basic law of the universe (called the "if nobody is listening, it doesn't
matter how loudly or slowly you talk" law).
If you don't like the circular queues, you can just get rid of those.
Although I don't see what the difference between a circular queue and two
buffers you flip between really is. The circular queues work well for many
things, and are there because that's how the original tty layer worked..
Linus Torvalds
On Tue, 22 Aug 2000, Eric S. Raymond wrote:
>
> You've ignored what I see as Rogier's main point. It's not "shared
> code means less bugs" per se, it's "shared code means better test
> coverage".
Testing only gets you so far.
And having a driver that handles everything under the sun can easily get
too complex - to the point where testing only shows that something is
wrong, and actually _fixing_ the bugs is getting to be the problem.
See Windows.
Or see the IDE driver. It's actually on it's second generation, and people
have talked about a third one. Supporting every IDE controller, whether it
is PCI or not, whether it can do DMA or not, is just fairly painful. To
the point where trying to fix one case tends to break another.
No, the serial driver is not there yet. Probably never will be. There just
isn't enough incentive for hardware people to do new things.
But the "common code helps" thing is WRONG. Face it. It can hurt. A lot.
And people shouldn't think it is the God of CS.
Eric S. Raymond
> But the "common code helps" thing is WRONG. Face it. It can hurt. A lot.
> And people shouldn't think it is the God of CS.
I think you're mistaken about this. Or, to be more precise, I think
your remarkable native talent as an implementor has given you some
unhelpful design biases that are only going to be cured by more
experience.
I'm fairly sure that experience will prove survivable for the Linux
kernel and the rest of us -- but when you say things like the above, I
start worrying a bit...
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The common argument that crime is caused by poverty is a kind of
slander on the poor.
-- H. L. Mencken
Jes Sorensen
Linus> It is NOT true that "shared code means less bugs". People, wake
Linus> up!
Linus> It's true that "simple and tested code means less bugs". And
Linus> quite often, code sharing will imply that the code gets (a)
Linus> more complex and (b) has cases that people who make changes
Linus> will never be able to test.
Linus> No, I'm not saying that sharing is bad. Sharing is good. But
Linus> anybody who makes a blanket statement like "sharing reduces
Linus> bugs" is full of crap.
I agree with you that we should not try to share code at any price.
However, we have seen many many times that someone copies a driver,
changes a couple of lines of code such as the device detection code
and possibly the register access macros and adds him/her-self as the
author and voila we have a `new' driver.
This type of programming is bad since bug fixes to the original driver
rarely propagate to the new one. A bit of extra work to generalize the
register access macros often pays off very well in the long run.
Jes
Linus Torvalds
On Tue, 22 Aug 2000, Eric S. Raymond wrote:
>
> Linus Torvalds <torv...@transmeta.com>:
> > But the "common code helps" thing is WRONG. Face it. It can hurt. A lot.
> > And people shouldn't think it is the God of CS.
>
> I think you're mistaken about this.
I'll give you a rule of thumb, and I can back it up with historical fact.
You can back up yours with nada.
Simple rule of thumb:
- sharing is good when it is true 100% sharing, no special cases, and
there is nothing that has reason to avoid the sharing.
Example: the VM layer. TCP/IP. The VFS layer.
- sharing is bad when it's done to 90%, and people work at trying to
avoid using the functionality that some other people want.
Example: the SCSI layer. Parts of the IDE driver. Glibc vs kernel
header files.
Quite frankly, the mentality that "we must share all common problems,
whether it makes sense or not" has resulted in untold woes. Usually it
starts out small. You add one more device. It obviously makes sense to
just tweak the code a bit. You add one more. You'll add some special case
code that only really matters for that one, and you hope that you got the
other cases right.
Eventually, you'll have code that spans 5 generations of hardware, where
the first generation and the last one basically share _no_ commonality
except for the common heritage. And they share a lot of the code, because
they have been written to do things the same way, even if it really
wouldn't make much sense any more.
End result: bad organization for the new hardware, inability to sanely
take advantage of the full features of the new hardware. Forcing people to
leave old code in place, because it is work-arounds for bugs in hardware
three generations gone. People end up having to thread very lightly
because the developer probably has access to all the new stuff, but
doesn't even have a way to test the old stuff any more - except by having
users holler when he broke it by mistake when he added code to handle new
cases.
Face it. Every once in a while, you have to start afresh. Tell people that
"Ok, we can't share this code any more, it's getting to be a major
disaster".
We've done this quite successfully several times. Each time it resulted in
a better product. Which is exactly the reverse of what you advocate.
Example 1: "hd.c" was left alone, "ide.c" was created. Some day, we'll
hopefully leave "ide.c" alone, and create a "ata100.c" that only handles
modern hardware.
Example 2: 53c8xx driver. Which broke from the 53c7xx driver and just said
"Screw it. That driver is too limited by the hardware it supports. I don't
want to deal with it". See also the u14-34f driver vs ultrastor.c.
Example 3: ne2k driver. Nope, the ne.c file was not just expanded to
handle yet another card type. Yes, it shares the basic 8390 code anyway.
This goes on and on and on. According to your logic, none of the above
improvements should ever have happened. You're wrong.
Linus
Roman Zippel
> Now, currently, most of the recieve handling is postponed to the
> bottom half. I question the usefulness of this optimization. It
> certainly adds latency. What is it that needs to be done on reception
> of a few chars? Copy the data to userspace, and hit the waitq of the
> process that's waiting for data. If you want to prevent the races, use
> a kernel-space circular buffer, and do the processing (copy to
> userspace) in the context of the wokenup process.
The input line handling in n_tty.c should IMO not be done on interrupt
level. AFAIK it's the only reason put_char can't sleep and you can get the
input line handling with a simple (but admittingly not very realistic)
example to overflow, because it has to echo chars back and at some point
it simply has to drop characters.
bye, Roman
yoda...@fsmlabs.com
>
>
> On Tue, 22 Aug 2000, Eric S. Raymond wrote:
> >
> > code means less bugs" per se, it's "shared code means better test
> > coverage".
>
> Testing only gets you so far.
>
> And having a driver that handles everything under the sun can easily get
> too complex - to the point where testing only shows that something is
> wrong, and actually _fixing_ the bugs is getting to be the problem.
>
> See Windows.
See IBM MVS. Note documents where there are hundreds of pages of information
on different parameters: if you are calling Z to move data ..., if you
are calling Z to encrypt commands to a 10234-T tape robot ... ... and so on.
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
Ingo Molnar
On Tue, 22 Aug 2000, Eric S. Raymond wrote:
> Sharing code is a way to increase the test population for the shared
> parts, which increases expected test coverage on the shared parts,
> which is good. It's especially good because the shared parts tend to
> have subtler bug signatures than the unshared parts (data structure
> corruption is harder to diagnose than a device lockup), so the better
> test coverage happens exactly where it's most needed.
this argument is flawed because it assumes a constant (static)
'requirements space'. But in RL (such as Linux) requirements change
dynamically, new CPUs, new hardware (new users :-) arrive at an ever
increasing rate.
for a static requirements space what you say is 100% correct. Sharing must
be maximized to get maximum test coverage - end of story. But in an OS
that tries to be practical in an ever changing world governed by the laws
of physics, it's more important to reduce algorithmical complexity, to
speed up debugging and other time-constained activity that does not happen
in an 'ideal world'. Part of the requirements are that we should both
support new hardware, new hardware features, and should stay stable on old
hardware, and we should be the fastest on the planet.
as you might notice if you check out the kernel code, there are parts that
are less affected by external forces (a process is a process is a
process), there we have very good code sharing. But in subsystems where
requirements are more dynamic, we tend to create 'snapshots' of code, let
the old code around and thus free the new code of the burden of having to
support old stuff - instead of trying to support everything at once.
this is analogous to what happens in the real world as well - water over
time flows to the lowest spot and becomes a lake - still we have
'seemingly impossible' things like rivers and waterfalls, which do not
make sense in a static-only environment.
Ingo
Bjorn Wesen
> > SOmething similar to the skb's would be preferable - so I can just take
> > write blocks and chain them into the DMA hardware. Incoming data can go
> > into "skb's" as well up to the tty.
>
> No. That is just horrible. What's so wrong with simple flip-buffers that
> they wouldn't work for you? Simple, and you can fill them up as fast as
> you can and then flip. Sure, if nobody reads the buffers fast enough
> you'll have trouble, but that's independent of how you do things. It's a
> basic law of the universe (called the "if nobody is listening, it doesn't
> matter how loudly or slowly you talk" law).
Ok a flip-buffer on receive which I DMA into is of course equivalent to
"skb"'s with a max outstanding count of 1 but without the allocation/free
code. So as long as the consumer eats the data quickly or the data is not
bursty that will work fine (and the other cases are probably to instable
to work with anyway, depending on if for example scheduling latencies are
a concern or not).
It was more on the output side I was thinking something more efficient
could be used than a copy into the write-buffer - but now that I think
about it, if we're to avoid pinning down user-pages, we still need to do
that copy somewhere so skb's wouldn't help there anyway...
Anyway, my main point was that I still hope to being able to DMA directly
into the tty flipbuffer etc. even if serial.c is split up, and I think
Rogier agreed there so all is well.. (ok actually we have our own
"serial.c" anyway but it would be nice to not having to duplicate all that
device-independant code eventually)
-Bjorn
Linus Torvalds
On Wed, 23 Aug 2000, Rogier Wolff wrote:
>
> However, (for example:) the fact that every serial driver in Linux has
> to do its own hangup and carrier detect logic stinks.
Oh, I agree.
But this is a code interface issue, in my opinion. I suspect the
interfaces in the serial case are just not very good, and a bad interface
will force people to duplicate code (possibly with small changes) just
because it's a bad interface.
Getting to a good interface is non-trivial, but in the end it's the most
important thing anybody can do. Once you have good interfaces, you can
then get to the point where sharing is easy without having the potential
downsides.
I definitely wouldn't argue about some tty layer and serial code changes.
Linus
Wolfgang Walter
> Linus Torvalds <torv...@transmeta.com>:
>
> You've ignored what I see as Rogier's main point. It's not "shared
> code means less bugs" per se, it's "shared code means better test
> coverage".
>
> driver's state space for correctness. Then coverage on each line of
> driver code is proportional to the number of users per driver.
>
> parts, which increases expected test coverage on the shared parts,
> which is good. It's especially good because the shared parts tend
> to have subtler bug signatures than the unshared parts (data structure
> corruption is harder to diagnose than a device lockup), so the better
> test coverage happens exactly where it's most needed.
>
I don't think this is true for drivers. It is ok if the difference between
the hardware is really small.
But often this is not the case, at least after some "generations". Code gets
more complex then necessary.
Sharing code for drivers then often means that somebody detecting a bug can't
fix it. And even for maintainers it is difficult to exclude side-effects.
An example is tulip.c in 2.2. It has several bugs which don't get fixed.
One bug i.e. is for DC21041 the interface does not work any more if
it loose the connection for several minutes to the switch/hardware. This bug
is described often. And probably some people detected the reason (it's an error
in the autoconfiguration, every time it detects a tx-link it is switched
to back to bnc).
I have a fix which works for me, but I have no real idea what will do for
other dec chips where autoconfiguration works rather differently.
As a version change of tulip.c affects so many different cards the version
of 2.2.16 is not replaced by a newer version of Donald Becker.
If you have a look at tulip.c you will realise that most code is not really
shared. It was an error to have one big driver for DC21040, DC21041, DS21140,
DS21143, "Lite-On 82c168 PNIC, ...
And I claim that this is a typical situation for hardware. Hardware evolves.
After some time the really shared code is small.
Greetings,
Wolfgang Walter
Rogier Wolff
> End result: bad organization for the new hardware, inability to sanely
> take advantage of the full features of the new hardware. Forcing people to
> leave old code in place, because it is work-arounds for bugs in hardware
> three generations gone. People end up having to thread very lightly
> because the developer probably has access to all the new stuff, but
> doesn't even have a way to test the old stuff any more - except by having
> users holler when he broke it by mistake when he added code to handle new
> cases.
>
> Face it. Every once in a while, you have to start afresh. Tell people that
> "Ok, we can't share this code any more, it's getting to be a major
> disaster".
Linus,
You're right. Starting afresh helps a lot. Everytime!
However, (for example:) the fact that every serial driver in Linux has
to do its own hangup and carrier detect logic stinks.
You've designed good interfaces that allow us to efficiently call the
"write" routine of whatever device we're talking to.
Similarly, I don't think we should have a quantum.c to talk to Quantum
drives. Talking to quantum drives is similar enough to talking to
maxtor drives that one driver should be able to handle it.
So, it's all a question of degree.
I think that we need to share more code in the serial driver. Have a
clean interface that reduces most serial drivers by 2000 lines-of-code
or so. Are we at 1 bug per 600 LOC yet? That's three less bugs.
I agree, maybe we should rethink the IDE driver. But NCR53c875 and
SYM53C895 are close enough to be handled by one driver. So it's a
matter of degree.
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* Common sense is the collection of *
****** prejudices acquired by age eighteen. -- Albert Einstein ********
Andre Hedrick
> Similarly, I don't think we should have a quantum.c to talk to Quantum
> drives. Talking to quantum drives is similar enough to talking to
> maxtor drives that one driver should be able to handle it.
Unless you are asking about uniqueness in feature design.
> So, it's all a question of degree.
>
> I think that we need to share more code in the serial driver. Have a
> clean interface that reduces most serial drivers by 2000 lines-of-code
> or so. Are we at 1 bug per 600 LOC yet? That's three less bugs.
>
> I agree, maybe we should rethink the IDE driver. But NCR53c875 and
Yes/No just allow for correctness to data-phase and setups to allow
command completion by default and allow ways to handle exceptions if it is
known how to, also provide the needed override-jerk code for people with
root-hang-overs.
> SYM53C895 are close enough to be handled by one driver. So it's a
> matter of degree.
Andre Hedrick
The Linux ATA/IDE guy
Eric S. Raymond
> > > And people shouldn't think it is the God of CS.
> >
> > I think you're mistaken about this.
>
> I'll give you a rule of thumb, and I can back it up with historical fact.
> You can back up yours with nada.
Yes, if twenty-seven years of engineering experience with complex
software in over fourteen languages and across a dozen operating
systems at every level from kernel out to applications is nada :-).
Now you listen to grandpa for a few minutes. He may be an old fart,
but he was programming when you were in diapers and he's learned a few
tricks...
> Face it. Every once in a while, you have to start afresh. Tell people that
> "Ok, we can't share this code any more, it's getting to be a major
> disaster".
I'm not arguing that splitting a driver is always wrong -- I can
easily imagine making that call myself in your shoes, and for the
exact reasons you give. I'm arguing that the perspective from which
you approach this issue causes you to underweight the benefits of
sharing code, and to not look for ways to do it as carefully and
systematically as you ought.
When you were in college, did you ever meet bright kids who graduated
top of their class in high-school and then floundered freshman year
in college because they had never learned how to study? It's a common
trap. A friend of mine calls it "the curse of the gifted" -- a tendency
to lean on your native ability too much, because you've always been
rewarded for doing that and self-discipline would take actual work.
You are a brilliant implementor, more able than me and possibly (I say
this after consideration, and in all seriousness) the best one in the
Unix tradition since Ken Thompson himself. As a consequence, you
suffer the curse of the gifted programmer -- you lean on your ability
so much that you've never learned to value certain kinds of coding
self-discipline and design craftsmanship that lesser mortals *must*
develop in order to handle the kind of problem complexity you eat for
breakfast.
Your tendency to undervalue modularization and code-sharing is one
symptom. Another is your refusal to use systematic version-control or
release-engineering practices. To you, these things seem mostly like
overhead and a way of needlessly complicating your life. And so far,
your strategy has worked; your natural if relatively undisciplined
ability has proved more than equal to the problems you have set it.
That success predisposes you to relatively sloppy tactics like
splitting drivers before you ought to and using your inbox as a patch
queue.
But you make some of your more senior colleagues nervous. See, we've
seen the curse of the gifted before. Some of us were those kids in
college. We learned the hard way that the bill always comes due --
the scale of the problems always increases to a point where your
native talent alone doesn't cut it any more. The smarter you are, the
longer it takes to hit that crunch point -- and the harder the
adjustment when you finally do. And we can see that *you*, poor damn
genius that you are, are cruising for a serious bruising.
As Linux grows, there will come a time when your raw talent is not
enough. What happens then will depend on how much discipline about
coding and release practices and fastidiousness about clean design you
developed *before* you needed it, back when your talent was sufficient
to let you get away without. The code-sharing issue -- more
specifically, your tendency to abandon modularization and re-use
before you probably ought to -- is part of this. Andy Tanenbaum's
charge against you was not entirely without justice.
The larger problem is a chronic topic of face-to-face conversation
whenever two or more senior lkml people get together and you aren't
around. You're our chosen benevolent dictator and maybe the second
coming of Ken, and we respect you and like you, but that doesn't mean
we're willing to close our eyes. And when you react to cogent and
well-founded arguments like Rogier Wolff's as you have -- well, it
makes us more nervous.
I used to worry about what would happen if Linus got hit by a truck.
With all respect, I still worry about what will happen if the
complexity of the kernel exceeds the scope of your astonishing native
talent before you grow up.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"...The Bill of Rights is a literal and absolute document. The First
Amendment doesn't say you have a right to speak out unless the
government has a 'compelling interest' in censoring the Internet. The
Second Amendment doesn't say you have the right to keep and bear arms
until some madman plants a bomb. The Fourth Amendment doesn't say you
have the right to be secure from search and seizure unless some FBI
agent thinks you fit the profile of a terrorist. The government has no
right to interfere with any of these freedoms under any circumstances."
-- Harry Browne, 1996 USA presidential candidate, Libertarian Party
Linus Torvalds
On 22 Aug 2000, Jes Sorensen wrote:
>
> I agree with you that we should not try to share code at any price.
> However, we have seen many many times that someone copies a driver,
> changes a couple of lines of code such as the device detection code
> and possibly the register access macros and adds him/her-self as the
> author and voila we have a `new' driver.
Note that this too can be beneficial.
Not for technical reasons, but for purely psychological ones. Which can
often be as important as the technical ones in the end.
The reason? People feel uncomfortable modifying other peoples drivers.
This is often true even if the original author hasn't even been a very
active maintainer for the last few years. So you find somebody new come
in, who cares about the new cards, but is not willing to maintain the old
stuff.
So he creates a "new" driver that works for him, and in the end he may end
up maintaining it a lot better than the non-existent maintenance that the
old driver gets. The old driver ends up working with the old cards, and
the new one gets the new ones. And in some cases this eventually gets the
old maintainer involved again and things work out.
Yes, this has happened.
And yes, it can go the other way too. It can become a source of painful
and unnecessary duplication.
On the whole, people tend to _want_ to share, because it ends up being the
easier "quick hack" in many cases. So I'm not worried about that part
overmuch. I'm worried about people who share even when it doesn't make
sense. And I'm worried about people having bad interfaces, which makes
even sensible sharing end up as a experiment in horror.
That's why I'm so un-interested in the "let's share" argument. I don't
think that is where the problems are.
Linus
Linus Torvalds
On Tue, 22 Aug 2000, Roman Zippel wrote:
>
> The input line handling in n_tty.c should IMO not be done on interrupt
> level. AFAIK it's the only reason put_char can't sleep and you can get the
> input line handling with a simple (but admittingly not very realistic)
> example to overflow, because it has to echo chars back and at some point
> it simply has to drop characters.
The ECHO thing is the single worst thing in the whole UNIX tty handling.
If it wasn't for ECHO, tty's would be a lot simpler, and a lot saner.
The original Linux tty layer actually didn't echo. Echo was handled
entirely in the user context when the user did a "read()". It worked 99%
of the time, and some of the time it worked a lot better than the silly
UNIX echo semantics.
For example, the "echo in user context at read()-time" approach did the
right thing with passwords automatically - it would not end up echoing
stuff that was supposed to be hidden by mistake, the way a simplistic
"login" program will do (paging activity leading to ECHO clearing being
delayed -> fast typist sees the first few characters of the password end
up on the screen).
It also simplified the code a _lot_.
But eventually (very early on, in fact - I don't know if this was fixed
even before 0.01 was released, but I suspect not), Linux started doing
ECHO the traditional way, because of the 1% of the time when it didn't do
the right thing. People expect to see what they type even when nobody is
reading at the console. Too bad.
I'd love to go back to the "good old days", but I don't think it's an
option. Oh, well.
Paul Jackson
Eric wrote:
|> Or, to be more precise, I think your remarkable native talent
I'd guess it's just the other way around -- that it is
Eric's remarkable native talent as an implementor that
is biasing things.
|> that are only going to be cured by more experience.
Again, perhaps it is the other way around, that more
experience favors Linus' position here (or, in my case,
perhaps it is just that creeping senility renders me
less able to grok special case ridden code').
In any case, striving to increase common code, and reduce
repetitions of similar code, is a curse and a blessing.
It is one of the more powerful forces, for both good and
evil, available to coders.
Long live the clean interface ...
--
--
I won't rest till it's the best ... Software Production Engineer
Paul Jackson (p...@sgi.com; p...@usa.net) 3x1373 http://sam.engr.sgi.com/pj
Matthias Andree
following that one up in AOL style. I second Eric mentioning the "curse
of the gifted" from own experience. You start something without design,
it succeeds for your talent, experience, whatever, it evolves and grows
and eventually disembogues into a rewrite from scratch, that time with a
design before the implementation.)
On Tue, 22 Aug 2000, Linus Torvalds wrote:
> On Wed, 23 Aug 2000, Rogier Wolff wrote:
> >
> > However, (for example:) the fact that every serial driver in Linux has
> > to do its own hangup and carrier detect logic stinks.
>
> Oh, I agree.
>
> But this is a code interface issue, in my opinion. I suspect the
> interfaces in the serial case are just not very good, and a bad interface
> will force people to duplicate code (possibly with small changes) just
> because it's a bad interface.
So, what does it boil down to? The need for an additional, well-defined
interface, encapsulating and hiding common functions. Effectively, once
the good interface is there, you will have an improved percentage of
shared code. That's what Eric is after, you wrap it up nicely into a
gift paper called interface.
Please: both of you, step back and hold a single second. You're not of
different opinions, basically.
> Getting to a good interface is non-trivial, but in the end it's the most
> important thing anybody can do. Once you have good interfaces, you can
> then get to the point where sharing is easy without having the potential
> downsides.
That's what encapsulation and sharing that encapsulated code only via
its interface are all about.
--
Matthias Andree
Kai Henningsen
> as you might notice if you check out the kernel code, there are parts that
> are less affected by external forces (a process is a process is a
> process), there we have very good code sharing. But in subsystems where
> requirements are more dynamic, we tend to create 'snapshots' of code, let
> the old code around and thus free the new code of the burden of having to
> support old stuff - instead of trying to support everything at once.
That's one aspect.
Another is finding out *how* to do that sharing right.
When your code is riddled with #ifdefs, most people will agree that
something's wrong here.
However, when all those #ifdefs get converted to if()s, something's
*still* wrong here. It's just wrong at runtime instead of wrong at compile
time.
The point here is that when something like that happens, one needs to sit
back and think about abstractions. A new, better abstraction is usually
what is needed in this situation - something that makes most of those
conditionals go away, *stay* away, and possible also take care of a number
of forseeable future ones.
Unfortunately, sometimes the best new abstraction one can come up with is
a driver split. In that case, can we have common subroutines/macros/
definitions at least? Or maybe change macros and leave the rest the same?
Those are also ways to abstract change.
Maybe we can't, or at least we don't know how. Too bad.
Then again, maybe we *can* find ways to handle this without giving up on
common source, and without producing code riddled with conditionals.
*That* is the ideal case.
MfG Kai
Alan Cox
> they wouldn't work for you? Simple, and you can fill them up as fast as
Our flip buffers dont work at 1Mbit or higher unless you hack HZ. However Ted
thought of this ages ago. You don't have to use flip buffers on receive you
can store frames however you like and the feed them directly to the tty input
layer. Several smart interfaces do this
Alan Cox
> interface, encapsulating and hiding common functions. Effectively, once
It isnt that simple
> the good interface is there, you will have an improved percentage of
> shared code. That's what Eric is after, you wrap it up nicely into a
> gift paper called interface.
You have to build -optional- interfaces. Instead of thinking about a layer
above the drivers think about a layer of support code _below_ the drivers
that can be shared and used when it fits. Now drivers that have odd needs
can skip pieces that dont fit. With a conventional view of layering they
end up fighting a pile of crap above them that does things they dont want
and eventually all the people trying to bend the layer above different ways
break it
Paul Gortmaker
Linus Torvalds wrote:
> Right now, drivers/net is pretty horrible, for example, and we've started
> separating things out a bit (ie drivers/net/tulip, drivers/net/pcmcia etc
[...]
> I'm eager to add new directories if they help make for finer-granularity
> hierarchy.
Might be able to help the drivers/net case a bit:
/mnt/2400-t7-p7/linux/drivers/net> grep -l 8390 *.[ch]|wc -l
30
/mnt/2400-t7-p7/linux/drivers/net>
Some of those may not actually use the 8390.c core - but say at least 25
could be put into drivers/net/8390/ - comments?
Note that a Config.in for such a dir wouldn't be good as entries make
more sense where they are (e.g. entry for 3c503 belongs with 3Com cards,
vs. asking user if they want to pick from list of 8390 based cards when
nobody outside this list has a clue what an 8390 is & what cards use it).
Paul.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Paul Gortmaker
Linus Torvalds wrote:
> Face it. Every once in a while, you have to start afresh. Tell people that
> "Ok, we can't share this code any more, it's getting to be a major
> disaster".
Agreed.
> We've done this quite successfully several times. Each time it resulted in
> a better product. Which is exactly the reverse of what you advocate.
>
> Example 1: "hd.c" was left alone, "ide.c" was created. Some day, we'll
Well, 90% true - some ide stuff went into hd.c before ide.c was spawned.
The hd.c now is essentially the same as in linux-1.0.9 as I took the ide
stuff back out again.
> Example 3: ne2k driver. Nope, the ne.c file was not just expanded to
> handle yet another card type. Yes, it shares the basic 8390 code anyway.
Actually I did expand ne.c to handle PCI versions prior to ne2k-pci.c
Seemed appropriate when a PCI NE2000 was just an anomaly - who knew a brain
fart from some misguided designer would result in a plague of these things.
But having ne2k-pci separate is a win - it gets to drop legacy code like
the bad clone list and 8 bit I/O support. And it will allow me (in 2.5)
to eject all the PCI code from ne.c - returning it to an ISA only state
like early 2.0 kernels.
Point being something like it may not be obvious that starting afresh
is the Right Thing until you've tried too hard to share - and once the
fresh start has proved itself, go back and clean up the mess made of the
old one while bending over backwards trying to support everything...