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