Date: Tue, 8 Apr 2008 11:38:58 -0600 From: John Hein <jhein@timing.com> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: arch@freebsd.org Subject: Re: tt_ioctl Message-ID: <18427.44466.423562.510257@gromit.timing.com> In-Reply-To: <40373.1207671393@critter.freebsd.dk> References: <18427.36758.266944.74378@gromit.timing.com> <40373.1207671393@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote at 16:16 +0000 on Apr 8, 2008: > In message <18427.36758.266944.74378@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").
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18427.44466.423562.510257>