From owner-freebsd-arch@FreeBSD.ORG Tue Apr 8 19:06:20 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32C621065671 for ; Tue, 8 Apr 2008 19:06:20 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id EA0B88FC1C for ; Tue, 8 Apr 2008 19:06:19 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9D69A17108; Tue, 8 Apr 2008 19:06:18 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m38J6IeJ040915; Tue, 8 Apr 2008 19:06:18 GMT (envelope-from phk@critter.freebsd.dk) To: John Hein From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 08 Apr 2008 11:38:58 CST." <18427.44466.423562.510257@gromit.timing.com> Date: Tue, 08 Apr 2008 19:06:18 +0000 Message-ID: <40914.1207681578@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: tt_ioctl X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2008 19:06:20 -0000 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.