Date: Wed, 09 Apr 2008 04:42:28 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: phk@phk.freebsd.dk Cc: arch@freebsd.org, jhein@timing.com Subject: Re: tt_ioctl Message-ID: <20080409.044228.-201314267.imp@bsdimp.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
In message: <40914.1207681578@critter.freebsd.dk>
"Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:
: 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.
I disagree here. There's real problems using ugen. I isn't easier
and it isn't faster to do what John needs to do with ugen. The whole
point of making it an ioctl was so that we could use all the
infrastructure in ucom without having to reinvent the wheel. Were we
to do what you suggest, we'd need some of the ftdi devices to attach
to ugen, and others to uftdi. This isn't possible in the current
state of the world. It just isn't. It is more problematical than
adding the ioctl to control the mode.
I think I may have originally added the code that John proposed to the
tsc tree (or maybe just my private tree when I was investigating the
problem for others at TSC). I think it is the right way to go, and
that the ioctl vs security argument is a bit specious. There's
already a number of ways that a badly written driver can cause
security problems on the system, why call this one out specially? I
do agree that you don't want the ioctl to give the ability to send out
raw USB packets, but the ioctls that he's talking about are at a
higher level: Set the device into this mode or that mode rather than
'send this arbitrary packet'.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080409.044228.-201314267.imp>