linuxconsole-dev

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Eric S. R. <es...@th...>]

Rogier Wolff <R.E...@Bi...>:
> 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

Re: [PATCH] Re: Move of input drivers, some word needed from you

[<R.E...@Bi...>]

Linus Torvalds wrote:
> 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...@Bi... ** 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 ********

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Linus T. <tor...@tr...>]

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.

		Linus

Re: [patch] The input move patch without moving to input

[Linus T. <tor...@tr...>]

On Tue, 22 Aug 2000, Vojtech Pavlik wrote:
> 
> This one moves just the non-USB stuff of the input drivers out of
> drivers/usb. That is, the bus-independent userland interface (char
> device) modules. It places them in drivers/char. And modifies the
> Makefiles and Config.in's accordingly.

I'd actually prefer drivers/input.

The argument I had against drivers/input was not an argument against a new
subdirectory. It was an argument against moving the things like hid.c and
the like to drivers/input, like the email I replied to tried to do.

hid.c is something USB-specific. It had better _not_ be a part of any
"generic input layer". The same is true of usbkbd.c and friends. They are
_usb_ drivers, and shall belong in drivers/usb.

		Linus

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Vojtech P. <vo...@su...>]

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. 

-- 
Vojtech Pavlik
SuSE Labs

[patch] The input move patch without moving to input

[Vojtech P. <vo...@su...>]

Hi!

This patch tries to accomplish the same what the previous one did,
basically to clean up the building of the input drivers.

The older one did move all the currently present input drivers in the
kernel, which now only includes joystick and usb ones. With time, the
list will grow (ADB, busmice, PS/2+AT keyb driver, ...). It'd have
been neat to have all that out of drivers/char.

This one moves just the non-USB stuff of the input drivers out of
drivers/usb. That is, the bus-independent userland interface (char
device) modules. It places them in drivers/char. And modifies the
Makefiles and Config.in's accordingly.

Everything after this patch compiles OK. (Current kernel breaks if you
select joysticks and not USB.)

Again, to keep the size down, it's a shell script and a patch. Run the
first, apply the second.

Is this OK? If not, what should I change?

-- 
Vojtech Pavlik
SuSE Labs

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Theodore Y. Ts'o <ty...@MI...>]

   Date: 	Mon, 21 Aug 2000 14:01:59 -0700 (PDT)
   From: Linus Torvalds <tor...@tr...>

   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

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Linus T. <tor...@tr...>]

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

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Philipp R. <pr...@pa...>]

On Mon, Aug 21, 2000 at 02:01:59PM -0700, Linus Torvalds wrote:
> 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

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Alan C. <al...@lx...>]

> 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.

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.

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Linus T. <tor...@tr...>]

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

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Alan C. <al...@lx...>]

> > 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 ?

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

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Philipp R. <pr...@pa...>]

On Mon, Aug 21, 2000 at 12:02:03PM -0700, Linus Torvalds wrote:
> 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

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Linus T. <tor...@tr...>]

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

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Russell K. <rm...@ar...>]

Linus Torvalds writes:
> 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        rm...@ar...      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Linus T. <tor...@tr...>]

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

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Philipp R. <pr...@pa...>]

On Mon, Aug 21, 2000 at 08:51:57AM -0700, Linus Torvalds wrote:
> On Mon, 21 Aug 2000, Philipp Rumpf 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
> 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

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Roman Z. <zi...@fh...>]

Hi,

> 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

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Jes S. <je...@li...>]

>>>>> "Roman" == Roman Zippel <zi...@fh...> writes:

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

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Alan C. <al...@lx...>]

> 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)

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Linus T. <tor...@tr...>]

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?

		Linus

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Matthew W. <ma...@wi...>]

On Mon, Aug 21, 2000 at 08:51:57AM -0700, Linus Torvalds wrote:
> > 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).

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.

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Roman Z. <zi...@fh...>]

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?

bye, Roman

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Alan C. <al...@lx...>]

> I'm eager to add new directories if they help make for finer-granularity
> 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)

> 

Re: [PATCH] Re: Move of input drivers, some word needed from you

[Linus T. <tor...@tr...>]

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