Messages in this thread | | | Date | Thu, 21 Oct 1999 21:29:19 +0100 (GMT) | From | Riley Williams <> | Subject | Re: serial.c (half duplex support) |
| |
Hi Ted.
>> Ted, I know you're against adding variables to the Config.in >> trees, but to me, this sounds like some sort of "Enable half >> duplex serial support" variable would be the best way to go, as >> that would provide the best of both ways:
>> 1. If (as it normally would be) the kernel is compiled with > the said option set to "n", then the serial driver would > remain as it currently is.
>> 2. For those (like Kees) who need it, the kernel could be >> compiled with the said option set to "y". In this case, >> it would define an additional pair of routines to handle >> the switching from send to receive and back again.
>> Since these additional routines are neither defined nor called >> in the first case, it would be possible for those needing half >> duplex support to develop it without impacting on those who >> don't need it.
> Given that in my experience almost everyone who turns this on is > going to need to modify serial.c to make the half-duplex support > routines work correctly given the vagrencies of their > half-duplex devices --- which remember are NOT standardized --- > I don't see the point of adding the variable in the Config.in > tree.
> You're going to have to muck with serial.c after the fact > anyway, and I don't want to deal with the support questions from > clueless users that try to turn on the feature, watch it fail, > and then send me mail complaining about the fact. Sorry, but > that's a support nightmare that I'd rather not have to deal > with....
I have to admit that I hadn't envisioned that feature in quite the way you appear to have, so would ask you to consider the following explanation of how I would see such a feature envisioned. I'll use the variable CONFIG_SERIAL_HALFDUPLEX as the one in question, for want of a better one:
1. If the kernel is compiled with CONFIG_SERIAL_HALFDUPLEX="n" then we would get exactly what we have now: A kernel that has no support for half duplex serial links at all.
2. If the kernel is compiled with CONFIG_SERIAL_HALFDUPLEX="y" then we would get a kernel which has support for facilities to enable half duplex support - in other words, we would have hooks where support for one particular method of doing half duplex (or simplex) communications can be implemented.
In other words, we would get something similar to the way IrDA support is implemented for the various serial IrDA transceivers - the ones that plug into serial ports.
This stage of the procedure is thus no more than an enabler that allows for separate modules to be developed for the various half duplex or simplex protocols, similar to what has already been implemented both in the IrDA case mentioned above, and in other subsystems such as the Ham Radio.
Dealing with your comments:
> Given that in my experience almost everyone who turns this on is > going to need to modify serial.c to make the half-duplex support > routines work correctly given the vagrencies of their > half-duplex devices --- which remember are NOT standardized --- > I don't see the point of adding the variable in the Config.in > tree.
1. You say "almost everybody ... need to modify serial.c"
That is precicely what they will NOT need to do. What they WILL need to do is to write THEIR OWN MODULE to implement the particular protocol they need to use, preferably based on a skeleton module that shows how to use the hooks that are built into the standard serial API.
2. You say "their half duplex devices ... are NOT standardized"
It is my understanding that such is exactly the argument that was used to get the standard device drivers split from the standard protocol drivers in (a) the Ham Radio subsystem, (b) the IrDA subsystem, (c) the sound subsystem, and (unless I'm mistaken here) the ISDN subsystem. Why not do the same here?
> You're going to have to muck with serial.c after the fact > anyway, and I don't want to deal with the support questions from > clueless users that try to turn on the feature, watch it fail, > and then send me mail complaining about the fact. Sorry, but > that's a support nightmare that I'd rather not have to deal > with....
3. You say "You're going to have to muck with serial.c after the fact anyway."
Your way, sure they are. My way, not that I can see.
4. You say "I don't want to deal with support questions from clueless users that try to turn on that feature..."
As envisaged above, the ONLY support questions you'd be likely to deal with would be in one of two cases:
a. A bug exists in how a particular hook is implemented.
If there's a bug, it needs to be squashed. That is true now, and would be just as true then.
b. The person trying to implement some particular half duplex protocol finds that they need a hook that is not currently provided.
Isn't that how we find out just what hooks are required?
Remember, you're the maintainer of serial.c and NOT of any protocol modules that get written to use the hooks you provide. Therefore, any emails from "clueless users" about the various protocols that get aimed your way, you just point out that you're not the maintainer of the relevant protocol module (unless you are, of course), and in the process, you turn that "clueless user" into a slightly less clueless user - at least they know that driver and protocol are different, which they didn't before.
Best wishes from Riley.
PS: The kernel versions page is now back online at the URL below, and includes separate sublists both for each kernel series, and for each year of development.
+----------------------------------------------------------------------+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this XXXX feature, but I bet someone | | else has already done so and is just about to release their patch. | +----------------------------------------------------------------------+ * http://www.memalpha.cx/Linux/Kernel/
- 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/
| |