From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4cba074ff1f8f3d1e1270f4f67fbe065@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: usbd - revision (Was: [9fans] USB developments)
From: Charles Forsyth <forsyth@terzarima.net>
In-Reply-To: <20040115134756.F25947@cackle.proxima.alt.za>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Thu, 15 Jan 2004 12:11:38 +0000
Topicbox-Message-UUID: b94cd00e-eacc-11e9-9e20-41e7f4b1d025

certainly before writing the original devusb.c,
my impression on inspecting the mess that was USB
implementation in other systems is that one ended up with
a fair number of little drivers in the kernel to handle the
peculiar dances required for each new (or broken) device.
for instance, i fail to see why talking to a Palm on USB
should need anything in the kernel, but there it is in other systems.
to paraphrase hume, crud that is dynamically-loaded is still crud.

i therefore deliberately put enumeration outside the kernel because it is (potentially)
non-trivial and recursive (so is PCI enumeration but it has
rather less to do, placing less of a strain on KSTACK).

i still think a kernel would need to interact
with a configurable user-level process (or processes) to do
enumeration properly in general.  the state required to do that
seemed to be split between kernel and process, which seemed
clumsy, compared to putting it all in user-mode.

that code still seems to me to belong beyond the `much-needed gap'.