Anyone who really needs this kind of support is probably going to end up
writing their own driver which uses the serial port hardware directly, like
the irport one already does.
These new drivers will tend to only support a 16550A, and not benefit from the
updated support which is available in serial.c for new ports, and also not be
able to drive the various intelligent multi-port cards which are available.
So, would it make more sense to abstract the hardware support in some way, like
we've already done for parallel ports?
Obviously we'd have to take a close look at the latency which extra indirect
function calls might introduce, which is particularly important with serial
ports, but we may be able to produce something which is workable, and allows
these half-duplex/RS485/HDLC/IrDA/etc. drivers to work on any serial hardware
which is physically capable of working with their protocol.
Ted, I'm not asking you to do this - I have somewhere on my TODO list a kernel
implementation of a random RS485-based fieldbus protocol¹ which is likely to be
done on company time, and such a driver reorganisation can justifiably be
considered part of that task. But I'd appreciate your input and guidance on the
details of the functions provided by this hardware abstraction, if indeed it's
a sensible suggestion in the first place.
¹ Profibus, if anyone's interested.
---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302
Project Leader, Process Information Systems Mobile: (+44) 7976 658355
Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
-
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/