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