> > devfsd is at least already here. The existing /sbin/hotplug architecture
> > can't handle it. A new kind of event would be needed.
>
> A new event type doesn't change the architecture ... if
> that's all that's needed, the architecture is unchanged!
Ok, so we don't call an extension a change ;-)
But the required changes to other subsystems would be
larger. You'd need to call the helper at
- SCSI bus scanning
- Partition detection
- disk change detection
- module insertation/removal
at least. Possibly at other places too.
And you'd begin to get some issues, like
disk change -> helper script -> open device file -> disk change -> helper
script -> etc ...
This is starting to get messy, IMHO.
I am not sure whether you can run these scripts in paralel.
And by the way some of this is needed for scsi<->usb bridges.
> To some folk, it won't even matter if the event comes from
> a devfsd thread or a kernel thread. Implementation detail.
> Except maybe to the US Patent Office ... sigh. (One
> iteration of USB hotplugging did just that: devfsd called
> the same policy scripts as the kernel thread version.)
Devfs can give you a name to work on.
The kernel thread'll give you major/minor at best.
But that's a small difference.
> > Even so, you'll probably won't make the user happy if it works only
> > on plugging in and not when he puts in a new medium.
> > A look at supermount might be in order.
>
> Yep, lots of tools to choose from. But again, not everyone
> runs supermount (or wants to) -- Yet Another Daemon, as I
> recall the situation.
It's a proper filesystem without a demon.
Why would a requirement to use a filesystem to enjoy a feature
be unreasonable ? If you can require usbdevfs you can require
supermount, too, IMHO.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
