Date: Tue, 08 Apr 2008 19:06:18 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: John Hein <jhein@timing.com> Cc: arch@freebsd.org Subject: Re: tt_ioctl Message-ID: <40914.1207681578@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 08 Apr 2008 11:38:58 CST." <18427.44466.423562.510257@gromit.timing.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <18427.44466.423562.510257@gromit.timing.com>, John Hein writes: > > 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 ;) No, not really. Try to read how far POSIX went, to make sure that ttys were non-compromised and un-compromising. Then consider the price we pay for an extra /dev/mumble.ctl device. There is really no excuse for overlaying non-per-tty functionality on a random tty device. If the functionality is per-tty, IOC_TRANSLATE_TO_HINDU and such, then this argument does not apply, I'm only talking about "out-of-band" ioctls, which were the ones I faced when I did this. > > 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). Is there an existing defined API for this ? ie: does linux have some ioctls defined already ? If so, we should stay compatible with that. If this is a new API we're defining, we should think carefully about how general we make it, it should hopefully not be private to one particular kind/brand/type of USB-SERIAL chip. >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). That is another option, but in general, passing USB through TTY, GEOM or any other high-level subsystem is a troubling and bad idea, if for nothing else, for code complexity reasons. >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. Yes, sounds trivial, but then again: I put a USB dongle on my dial-in modem and suddenly a user can diddle it at USB level ? I think not... So we would have to restrict these ioctls to /dev/cua* devices instead of /dev/tty* devices. And then we would have to teach our uses the difference between the two kinds. And who besides me (and bde ?) have a dial-in modem anyway ? It is a fair comment that the POSIX model for a tty is totally out of whack with what people use them for these days. Summary: If there is a well established ioctl for such bit-banging already, and you restrict it properly (/dev/cua* I would say), then go for it. Otherwise, use ugen, it's easier, simpler and likely faster. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40914.1207681578>