On Sun, Jun 04, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> > > 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.)
load-on-present is in direct conflict with load-on-use obviously.
Determining which one is desired is probably the hardest part.
load-on-present for all PCI devices is not desirable.
> > Because Unix, and more importantly Linux, is dumb with respect to
> > dynamic hardware configurations.
>
> These are fixable issues.
Yes they are fixable. But at the current rate, not anytime soon.
> > 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.
He has said that we can't depend on the code that is needed. Since he
has not offered up an alternative solution, it seems he's not interested
in allowing a sane solution to be developed.
> > > 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.
Linux is not Unix, remember that. It happens to have many things in
common, but they are quite different and will grow increasingly
different in the future.
We are not at all interested in what traditional UNIX systems may do in
the future wrt dynamic device insertion and removal.
> 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.
No, the example isn't broken. The example was that you need someone to
specify that a particular name is linked to a particular physical
device. This needs to be configured somewhere regardless. That is the
point.
> > > 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).
Exactly. Like I said, I was confused by what you have said earlier. I
think you've done a good job clarifying it.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
