From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: usbd - revision (Was: [9fans] USB developments) From: Fco.J.Ballesteros In-Reply-To: <20040115123004.D25947@cackle.proxima.alt.za> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-mimtrovhlfvtmzsmjmrzokxbyq" Date: Thu, 15 Jan 2004 11:46:53 +0100 Topicbox-Message-UUID: b93c478e-eacc-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-mimtrovhlfvtmzsmjmrzokxbyq Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think the #U work is just to setup the bus and also to hardwire the endpoints (i.e. to service real usb interrupts as it's doing now, for performance). It should not depend on user programs, although they can for sure setup the endpoints and the like. Usbd is probably where the enumeration belongs, but I'd say that just that. The driver is the one who knows how to configure the device, once it has been started by usbd (which only needs to look at usbdb). So, should we start perhaps by reworking the relationship between usbd and the drivers? I don't really know. --upas-mimtrovhlfvtmzsmjmrzokxbyq Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by aquamar; Thu Jan 15 12:36:30 MET 2004 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 5471B19C79; Thu, 15 Jan 2004 05:31:32 -0500 (EST) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id E8CB919CB6; Thu, 15 Jan 2004 05:31:10 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 3624B19CB6; Thu, 15 Jan 2004 05:30:29 -0500 (EST) Received: from cackle.proxima.alt.za (cackle.proxima.alt.za [196.30.44.141]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 62B9819AD9 for <9fans@cse.psu.edu>; Thu, 15 Jan 2004 05:30:16 -0500 (EST) Received: from cackle.proxima.alt.za (localhost [127.0.0.1]) by cackle.proxima.alt.za (8.12.8/8.12.3) with ESMTP id i0FAUEER026622 for <9fans@cse.psu.edu>; Thu, 15 Jan 2004 12:30:14 +0200 (SAST) Received: (from lucio@localhost) by cackle.proxima.alt.za (8.12.8/8.12.3/Submit) id i0FAUDIs026617 for 9fans@cse.psu.edu; Thu, 15 Jan 2004 12:30:13 +0200 (SAST) From: Lucio De Re To: 9fans@cse.psu.edu Subject: usbd - revision (Was: [9fans] USB developments) Message-ID: <20040115123004.D25947@cackle.proxima.alt.za> Mail-Followup-To: 9fans@cse.psu.edu References: <20040115104258.A25947@cackle.proxima.alt.za> <1bc4a83f021e1f3542be7e8c1d0233e4@plan9.escet.urjc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <1bc4a83f021e1f3542be7e8c1d0233e4@plan9.escet.urjc.es>; from Fco.J.Ballesteros on Thu, Jan 15, 2004 at 10:13:10AM +0100 Organization: Proxima Research & Development Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu X-Reply-To: lucio@proxima.alt.za List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Thu, 15 Jan 2004 12:30:09 +0200 X-Spam-Status: No, hits=-2.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Thu, Jan 15, 2004 at 10:13:10AM +0100, Fco.J.Ballesteros wrote: > > #U, does mostly what it does, but stays appart of csp definitions. I presume we'll look at this later, I'm sure there's a bit of work needed here. > usbd: simply configures the device and reads a usbdb file to > learn which program is to be used for each csp. > usbd: starts those programs when a new csp is noticed. Let me see if I understand this correctly. I would remove the initial configuration from the kernel driver (#U) and delay it until usbd is activated, although it's not (yet) clear to me whether the code needs to reside in the kernel, in which case an "enumerate" function would be implemented in #U and would return, through the control or status file, the list of enumerated devices, each uniquely identifiable (by numeric index seems good enough). Let me stop here. Have I explained how I see things properly? How do others suggest I tackle the above? Next, we need to looks at /lib/usbdb, establish s tentative format and a set of routines to read it. Is that what aux/vga does? How much can we copy from there? I then expect the ipconfig-like operation that Richard Miller suggest could use /dev/sdctl needs to be implemented. As Richard suggests, this need not happen in a first phase, although I find it hard to implement something knowing I'll do it differently soon enough. My vote with Nemo about the plumber, which is not to say that plumbing is not the right principle to employ. Here I pause. I think I need some input before proceeding, so feel free to mail me, privately or publicly. If private, make sure you let me know if you don't want to be quoted in public. And don't count on me not making mistakes, with advance apologies right now :-) ++L --upas-mimtrovhlfvtmzsmjmrzokxbyq--