From owner-freebsd-hackers Fri Jun 20 17:33:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA04769 for hackers-outgoing; Fri, 20 Jun 1997 17:33:23 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04764 for ; Fri, 20 Jun 1997 17:33:19 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA07690; Sat, 21 Jun 1997 10:03:11 +0930 (CST) From: Michael Smith Message-Id: <199706210033.KAA07690@genesis.atrad.adelaide.edu.au> Subject: Re: USB -- How tricky will it be to support? In-Reply-To: from Troy Curtiss at "Jun 20, 97 08:38:46 am" To: troyc@sandy.merix.com (Troy Curtiss) Date: Sat, 21 Jun 1997 10:03:10 +0930 (CST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Troy Curtiss stands accused of saying: > Hackers, > How tricky is USB going to be to support? >From my reading, quite. It's very heavy on the software side. > Some of the mechanisms > such as hot plug/unplug, auto-detection and driver allocation, addressing, > and etc. don't look easy... The paradigm feels like a cross between the > PC-Card stuff (for the plug/unplug) and a PCI-bus (for addressing and > detection). Yup. It needs to be developed in the context of a generalised demand-loaded/unloaded device driver model, and it'll need to make heavy use of devfs. You should have a look at Doug R.'s new ISA code as well, as providing he has the time to keep working on it, it's the best place to start. ` The generalised driver framework is the infrastrucrure required; things like USB will come "almost" (ha!) for free once it's in place. > Anybody toyed with supporting USB yet? I'm curious what angle to > attack this subsystem from. I read through several of the spec documents and decided I just didn't have the time to spend on it (and no USB hardware to try with either). If you wanted to do _something_ in the current context, I'd humbly suggest developing the various functional components in a very black-box fashion, so that you can reuse them later; concetrate on the protocol and detection code, that sort of stuff. > | Troy Curtiss, HW/SW Engineer | Email: troyc@merix.com | -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[