Date: Tue, 8 Apr 2008 17:40:32 -0600 From: John E Hein <jhein@timing.com> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: arch@freebsd.org Subject: Re: tt_ioctl Message-ID: <18428.624.490619.248235@gromit.timing.com> In-Reply-To: <40914.1207681578@critter.freebsd.dk> References: <18427.44466.423562.510257@gromit.timing.com> <40914.1207681578@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote at 19:06 +0000 on Apr 8, 2008: > 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. Fair enough. I didn't mean to trivialize the concern with a joke. > Is there an existing defined API for this ? > > ie: does linux have some ioctls defined already ? Yes. They use ioctls on top of the sio device in the latest driver on sourceforge (from 2003)... http://sourceforge.net/projects/ftdi-usb-sio/ In fact it just uses a different ioctl command character to separate the bit bang ioctls from the sio ioctls. That is not the driver that comes with the linux kernel source, however. That driver does not support bit bang mode. It seems they have not pulled in the support into their repository. So the bit bang driver for linux is somewhat renegade. Netbsd does not have support for bit bang mode in cvs. But there was one email inquiring about it on tech-kern recently. And for more existing precedent, FTDI looks like they have separate windows drivers for "virtual com port" access and for "direct via usb" access. Not that we want to base our work on what windows does, of course. But it's more information. > 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. Yes. So there are two questions here. One which opened this thread: Do we want to allow tty sub-devices to get to device-specific ioctls through the tty layer? Second (which is larger than the scope of the first question), how to integrate the non-tty functionality of certain usb serial devices into FreeBSD. We can do the first without having usb serial devices use it, so the questions are somewhat separable. I also have two motivations: one to get it done quickly in my local tree. But I'd like to see it implemented cleanly and into FreeBSD. I can do the former easily enough, but need the help from opinions on arch@ for the latter. I guess I'm leaning toward a separate uftdi0.ctl minor device despite what the sourceforge linux driver does. > >To that end, this could also be considered a more general question of > >supporting pass-through of generic USB commands on USB serial devices > > 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. Agreed. I almost deleted that comment before I sent it in the last email. I should have. Forget I mentioned it. > And who besides me (and bde ?) have a dial-in modem anyway ? You'd be surprised. > 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. Well established? From my research, I can't say there is a well established ioctl for this. Lots of example code I've seen is using libusb & libftdi with ugen rather than the device driver. But I'd like to get support for bit bang mode into driverland. > Otherwise, use ugen, it's easier, simpler and likely faster. You can't use ugen, for instance, for the dual ftdi chip where you want one port to be uart and the other to be jtag. And you can't use it if you want to switch between ucom and ugen without rebooting (at least not in 6.x or 7.x). As I said, I haven't figured out if that is by design or not. I don't have a problem with opening two different devices for the two different modes, but requiring an intervening reboot is out of the question.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18428.624.490619.248235>