Douglas, thanks for that overview of the structure of the SCSI
subsystem -- I needed one, that was better than I'd suspected
I'd find!
It seemed to me that something was missing in that stack though;
the layers above (4), specifically filesystems, that would also need
to know about new devices that were added. When everything is
working smoothly, users need to see filesystems get mounted as
a direct consequence of hotplugging such storage units.
One way to look at that issue is to ask what user mode notifications
will be used to address that part of the hotplug problem. Devfsd
is what some folk like, but it's not universally accepted. GUI
driven solutions don't seem right in all cases either.
Eric:
> As far as the mid-layer is concerned, hotplugging more or less consists
> of two independent tasks. Addition of new devices, and removal of devices.
Exactly. That is, if you will, one of the first architectural requirements.
Once that's addressed, everything else starts to fall into place.
As I understand things, USB-to-SCSI adapters (like most usb-storage devices)
will also have "bus" add/remove events to deal with. Likewise with cases
like hotplugging a SCSI controller on a Cardbus laptop, or on a CompactPCI
(or HotplugPCI) enterprise level server. Presumably those cases aren't
as troublesome?
You commented that "hot unplugging a device is a bit trickier" ... yes!
The notion of a "pending remove" state has crossed my mind too. "New style"
networking drivers seem to have something like this, and USB has analagous
issues. Re tying it into the module subsystem, I'll have to try that idea
on for size; the module system doesn't really know about "devices" as such,
and maybe it should. (Something needs to.)
> Anyways, my initial question reallly has to do with exactly how one is
> notified that a new device has appeared and whether a bus scan needs to be
> initiated or not. That will control the degree to which we have to screw
> with things in the mid-layer to support this.
Reasoning by analogy for a moment ... USB and Cardbus both have kernel
threads (khubd, and the cardbus watcher) tasked with detecting such stuff.
Also, it's plausible to me to require "add new device" processing to have
a thread context to work with, like "remove device"; again, USB and Cardbus
both have that requirement. So it seems to me that having some thread(s)
involved here will be the typical case. Presumably that means that the
mid-layer code would need to accomodate that model.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
