Messages in this thread | | | Date | Wed, 3 Nov 1999 08:06:31 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: Bogus serialP.h patch? |
| |
Date: Wed, 3 Nov 1999 12:15:16 +0000 (GMT) From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Umm, the following patch in 2.3.25 is bogus. SERIAL_XMIT_SIZE and > async_icount are both internal serial structures that should *not* be > exposed outside of the serial driver; they're not part of the exported > interface.
They are not internal structures to your serial driver. They are internal structures to a pile of serial drivers.
> stolen from serial.c and worked into other drivers; but they should > include serialP.h instead of moving this into serial.h.
Then the drivers pick up all the other junk too. If you want to split serial.h 3 ways according to whether an item is private to your driver, private to the kernel serial drivers or public to the whole kernel sure.
Making a new header file for 10 lines of common declarations seems a bit silly, especially since there's no reason why those drivers have to use the same internal structure.
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.
But if 3 header files is the way Linus wants to go, that's fine. We can call it serialPstolen.h, I suppose, or something like that. I think it's silly though. If they're going to steal code out of serial.c, they can either #include serialP.h, or copy what they need out of serialP.h to their own .c file. Putting private declarations in the public serial.h is Just Wrong.
Eventually, we can talk about ways of making the tty layer have more support for this kind of thing, so that (for example) async_icounter is in the struct tty, and the ioctl handling is done in tty_ioctl.c. The difference is, that would be a cleanly implemented change. What we're doing right now isn't clean at all.
- Ted
- 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/
| |