> Not quite true. The line discplines make call backs to the driver for
> things like tty->driver.throttle, tty->driver.unthrottle on the input
> side. (Which is actually not as bad as I thought it would be; it's much
> worse if you're following the line discpline ---> tty driver path for
> tty output.)
Which is fine. a) I dont have to pass the real tty object to the second
discipline and b)if Im careful i can swap driver.throttle/unthrottle too
What was that about "nice" and "clean" again? :-)
You do need to pass a fairly real tty object, since the tty line
discpline does operate on the data fields of the tty object. You could
swap around tty->driver (not tty->driver.throttle, since tty->driver
points to a shared constant object), but then you'd better be careful
about other things calling the tty->driver.* functions, since the
high-level tty layer calls tty->driver, too.
Most of the callbacks for a keyboard addin wont apply - input throttles
pass through and we are shrinking the data, output Im assuming doesnt occur
(capslock ?)
I'd be willing to believe that you could kludge around enough it to make
it work, but I'd be hard-pressed to call the result "clean". :-)
Instead of trying to kludge it in as a line discpline calling a line
discpline, we'd probably either be better off designing a new filtering
interface which the line discipline could call.
(although we still have to deal with the keycode dispatching issue).
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu