From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 29 14:17:07 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63B21106566B for ; Fri, 29 Feb 2008 14:17:07 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id C12B28FC1A for ; Fri, 29 Feb 2008 14:17:06 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m1TEH4AI062983; Fri, 29 Feb 2008 15:17:04 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id m1TEGqlb062308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Feb 2008 15:16:52 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id m1TEGpMs011921; Fri, 29 Feb 2008 15:16:51 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id m1TEGp9g011920; Fri, 29 Feb 2008 15:16:51 +0100 (CET) (envelope-from ticso) Date: Fri, 29 Feb 2008 15:16:51 +0100 From: Bernd Walter To: Ivan Voras Message-ID: <20080229141650.GM7101@cicely12.cicely.de> References: <47C73262.1020805@rawbw.com> <20080229074208.GT83599@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on cicely12.cicely.de Cc: freebsd-hackers@freebsd.org Subject: Re: umass: should the device specific information be moved from C code to the text file? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Feb 2008 14:17:07 -0000 On Fri, Feb 29, 2008 at 12:44:44PM +0100, Ivan Voras wrote: > Peter Jeremy wrote: > > > This sounds like a nice idea - it's also a nuisance having to recompile > > the kernel just to support a weird new USB device you've acquired. > > You can probably keep USB support as a module if you need to recompile > it often :) > > On the original topic: please don't do that. Recent ultra-modern Linux > systems have started offloading such critical kernel functionalities to > the userland, making it almost impossible to deal with when things go > bad (e.g. in single user mode). See also trouble ZFS has in single user > mode because it relies on files in the file system and a userland rc.d > script (hostid). It doesn't work anyway, since umass doesn't attach to device/vendor-ID. umass(4) is a interface class driver and attaches to each device containg a umass class interface independend of vendor/device-ID. There may be some exeptions for devices, which fail to supply the correct decriptor tables however, but the majority of supported devices are unknown to the driver. If you need ugen and umass, then fix ugen to attach even if another driver(s) already controls the device or some interfaces. This may be tricky, since ugen allows things that may break the expectations of other drivers, but we should have a solution for this problem anyway. Maybe we can live with this risk, while ugen is enhanced to do dafety catches - we have much more dangerous risks with USB right now, such as detaching mounted umass media. Not sure if HPS stack already handles the ugen vs. other driver problematic. AFAIK under Linux the generic userland interface allows claiming devices/interfaces from userland. It could be good idea for us as well and it would be good for libusb support as well. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de