From owner-freebsd-arch@FreeBSD.ORG Tue May 23 10:11:58 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19E7516A425; Tue, 23 May 2006 10:11:58 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.swipnet.se [212.247.155.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE45643D45; Tue, 23 May 2006 10:11:56 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== X-Cloudmark-Score: 0.000000 [] Received: from mp-217-36-191.daxnet.no ([193.217.36.191] verified) by mailfe13.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 32073808; Tue, 23 May 2006 12:11:54 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Tue, 23 May 2006 12:11:52 +0200 User-Agent: KMail/1.7 References: <86y7wum9ow.fsf@xps.des.no> <200605221518.03687.mistry.7@osu.edu> <20060522.164641.74674575.imp@bsdimp.com> In-Reply-To: <20060522.164641.74674575.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605231211.55151.hselasky@c2i.net> Cc: mistry.7@osu.edu, Arch@freebsd.org, rwatson@freebsd.org, freebsd-usb@freebsd.org, des@des.no Subject: Re: Resend with subject: No more non-MPSAFE network device drivers, please! 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, 23 May 2006 10:11:58 -0000 On Tuesday 23 May 2006 00:46, Warner Losh wrote: > > I'd be willing to help convert drivers if we can get the code into the > > tree (maybe as usb-ng?). Setting up a bounty for this stuff may be > > worthwhile since having a solid USB stack would be a boon for > > everyone. > > I'm not sure if it's possible with the HPS driver, but it would be > > nice if every USB device could expose ugen endpoints along with their > > device specific nodes. This is not impossible with my USB stack, but one will have to make ugen a special USB device driver then, hence every time the configuration value is changed, the device nodes , /dev/ugenX.Y, must be re-created. Two drivers can set the configuration value, ugen and the device specific driver. Maybe one has got to put some restrictions here, like disabling ugen from changing the configuration value if a USB device driver is attached. Else changing the configuration value can lead to a detach of attached device drivers. That is the problem from what I can see. > > Since I've been reviewing the HPS usb stack for a while now, I'd be > happy to act as coordinator for efforts in this area. > One question is wether we should have the emulation layer for the old USB system or not. I mean it is not very solid, hence it can suddenly sleep due to memory allocations, when it is not allowed to sleep. And then the system will issue a panic(). Everything that is there to support the old USB API has been enclosed with: #ifdef USB_COMPAT_OLD #endif You might consider it for removal. I have volunteered to do some work on the USB stack and drivers as a part of summer of code, but it is not sure yet wether my project will be accepted or not. --HPS