Messages in this thread |  | | Date | Mon, 21 Aug 2000 21:43:11 +0100 | From | Philipp Rumpf <> | Subject | Re: [PATCH] Re: Move of input drivers, some word needed from you |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |