> > As I said, the USB subsystem can be initialized by "modprobe usbcore"
> > (with post-installs for usbd and usbdevfs). So don't do the modprobe
> > until/unless you need the USB subsystem to work, and you'll get the
> > "hardware exists, subsystem unitialized" non-PNP case you want.
>
> Where does your PCI probing come into effect? I'm just a bit confused on
> that point.
>
> usbcore will use PCI probing? "usbd" will use PCI probing?
The PCI subsystem would, if anything. The thing is that
one needs such probing to happen after the root filesystem
is mounted. I'll not be modifying the PCI subsystem to try
this (at least not at this time) so likely it won't happen.
The PCMCIA subsystem sort of runs that way, though. When one
adds a PCMCIA USB controller, typically OHCI, PCMCIA services
effectively will have probed PCI to determine that, and would
then "modprobe usb-ohci". (UHCI is an exercise ... ;-)
However, "usbcore" can indeed just modprobe for the modular
host controller drivers, when it's a module itself. (If the
USB core is compiled into the kernel, it initializes before
there's a root filesystem to modprobe from, so it does no
good to try modprobing there.)
> Because Unix, and more importantly Linux, is dumb with respect to
> dynamic hardware configurations.
These are fixable issues.
> Since people like Linus are uninterested in a sane solution supporting
> dynamic device insertion and removal some other kludge must be developed.
I'm certain Linus wouldn't put it that way at all.
> > I guess what I'm saying is that in that /dev/sda example, I can't
> > see that load-on-use could ever work; what'd be needed is a facility
> > to reserve names, which doesn't exist in the absence of actually
> > allocating them.
>
> Exactly. This is all apart of the whole mess with dynamic device
> insertion and removal with Linux.
I'd actually say "UNIX" there. One must recall that UNIX came from the
minicomputer environment. The Macintosh was the first widely available
bit of hardware to be designed with "Plug'n'Play" in mind, but the UNIX
community has been rather slow applying its lessons to desktop UNIXes.
That heritage of reliance on expert sysadmins/gurus can be troublesome.
... but given that you acknowledge your /dev/sda example is broken, I
don't see what you meant to show by it.
> > The HCDs won't load if there's no matching controller. While I
> > agree with you about not loading drivers, that's a policy that
> > reasonable folk might disagree on.
>
> I must have misunderstood when you said usbcore would modprobe all of the
> HCD's since we know which ones exist because it can statically link them
> into the kernel.
In my book, needing to statically link the HCDs (into kernel or usbcore)
is undesirable. Linux is not supposed to be bloatware that spends pages
of memory on code that can never get called.
"We" do not know which controllers exist if we're building one kernel to
run on a variety of different hardware configurations. "We" need to work
with OHCI, UHCI, both, and neither ... consuming minimal resources in all
cases and configurations (modular, non-modular, etc).
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
