From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 10:44:27 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 72A0810656CA for ; Wed, 9 Apr 2008 10:44:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2D40B8FC27 for ; Wed, 9 Apr 2008 10:44:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m39AfXS6073899; Wed, 9 Apr 2008 04:41:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 09 Apr 2008 04:42:28 -0600 (MDT) Message-Id: <20080409.044228.-201314267.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <40914.1207681578@critter.freebsd.dk> References: <18427.44466.423562.510257@gromit.timing.com> <40914.1207681578@critter.freebsd.dk> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, jhein@timing.com 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: Wed, 09 Apr 2008 10:44:27 -0000 In message: <40914.1207681578@critter.freebsd.dk> "Poul-Henning Kamp" 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