tt_ioctl

[John Hein]

Poul-Henning Kamp wrote at 16:16 +0000 on Apr  8, 2008:
 > In message <18427.36758.266944.74378 at gromit.timing.com>, John E Hein writes:
 > >tt_ioctl remains unused.
 > 
 > That was sort of deliberate, based on a theory that our ttys should
 > behave as much the same as possible, no matter what driver was behind
 > them, and therefore all ioctls should be handled as linedisc.
 > 
 > If a driver needs a special ioctl to do something like load firmware,
 > that should, IMO, not happen on a tty but on a special control device
 > which is not used for login-sessions.
 > 
 > If for no other reason, then for purely security reasons.

The old 'call it a security issue' to end all debate ploy ;)


 > As always, I'm prepared to be persuaded by good examples :-)

Well this started out as an exercise to allow us to put FTDI parts
(USB-to-serial chips, specifically using the dual port variety here)
into so-called "bit bang" modes (for writing to parts via SPI, JTAG,
and similar connections).

The FreeBSD uftdi driver supports the uart emulation mode through the
ucom(4) driver but not the former.  The ucom(4) driver has a hook to
to allow ucom-based drivers to be called via struct tty's t_ioctl.
Currently that will never get called through the tty infrastructure
since tp->t_ioctl is not called from ttyioctl (which is what prompted
the patch).

I'm not sure if that counts as a good example.


At the risk of expanding this conversation beyond its original scope...

To support the different mode, there are a couple generic USB commands
you can send to these devices.

To that end, this could also be considered a more general question of
supporting pass-through of generic USB commands on USB serial devices
(as you could do if it was attached as a ugen device instead of a cuaU
device).  Should that be supported (via separate dev node or some
other way) generically?  However, even if that were supported, that
would put the ball in userland's court to send the right USB commands
to put the device into the right mode.  I like the idea of keeping the
knowledge how to do that in the uftdi driver (and not having specific
usb devices pass through to ugen).  One thing I have noticed is that
it's hard to switch between ugen and ucom (via kldunload/kldload)
without rebooting.  I haven't tracked down whether that's by design.


Unless someone else votes toward supporting driver-specific ioctls
through the tty layer, adding a control device is okay with me.  As
far as naming, it could be cuaU0.ctl or uftdi0.ctl or something else.
I guess I'd lean toward the second choice.


And if we decide driver-specific ioctls via tty layer should not be
used, then perhaps we should just remove t_ioctl from struct tty?
It's not called from anywhere right now, although it is set it a few
places...

./dev/usb/ucom.c:       tp->t_ioctl = ucomioctl;
./dev/digi/digi.c:              tp->t_ioctl = digiioctl;
./sys/tty.h:    t_ioctl_t *t_ioctl;             /* Set ioctl handling (optional). */
./sys/tty.h:    if (t->t_ioctl == NULL)
./sys/tty.h:    return (t->t_ioctl(t, cmd, data, fflag, td));

digiioctl also seems to want to do some real things, and I can't see
how it gets called right now.  That became connected to the tty layer
(and thus effectively not connected to anything - correct me if that's
wrong) in 2004-10.  I guess no one missed those knobs?

Currently ucomioctl just calls back to ucom-based drivers that have
registered their ioctls with it.

There is one ucom-based driver that wants to do real things in its
ioctl callback (umodem).  And two others (uvscom, uplcom) that appear
to want to in the future (commented out with "TODO").