tt_ioctl

[John E Hein]

Poul-Henning Kamp wrote at 19:06 +0000 on Apr  8, 2008:
 > In message <18427.44466.423562.510257 at 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.