tt_ioctl

[Poul-Henning Kamp]

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.

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 at 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.