Messages in this thread |  | | Date | Mon, 21 Aug 2000 14:01:59 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH] Re: Move of input drivers, some word needed from you |
| |
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/
|  |