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
-
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/
This archive was generated by hypermail 2b29 : Wed Aug 23 2000 - 21:00:05 EST