>> 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/