Messages in this thread | | | Date | Wed, 3 Nov 1999 08:43:11 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: Bogus serialP.h patch? |
| |
On Wed, 3 Nov 1999, Theodore Y. Ts'o wrote: > > If that's all they really need out of serialP.h, then perhaps that 10 > lines of code should just be included into that driver's .c file instead > of put in a public header file. I'm *really* nervous about that, since > the whole point of serial.h versus serialP.h is to keep the documented > public interfaces separate from the internal private implementation > types and #define's.
Actually, I've always hated the notion of "public" versus "private", and I think "serialP.h" is just a band-aid around a real problem which is that there is quite a lot of incestuous knowledge about the tty layer and serial devices all over the place.
First off, if it's really a _private_ header file, then it shouldn't be in <linux/serialP.h> in the first place. It should be in drivers/char, and you should use #include "16550.h" to make it clear that (a) it's not about "serial devices", it's about a specific _class_ of serial devices and (b) it's really just private to a specific driver (or two similar drivers), and not a generic Linux header file.
Btw, calling the dang thing "16550.h" may be technically inaccurate (it obviously is used a lot more chips than the 16550), but I think it is _psychologically_ a lot closer to what you seem to have in mind for the use. It would tell people what the file is about - which the current name does not at all. The current name probably makes most people think that the programmer was spastic and wrote an extra 'P' by mistake.
But I don't care all that much. I think that either we should do the one-liner to make existing things happy as things stand (which is basically what Alan did), or we should just fix the thing _right_, in which case the "serialP.h" file goes away - moved or integrated, I don't much think there is all that much of a difference (the integration should be much more complete, with a "serial device layer" kind of support structure etc).
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |