Re: SCSI Patches - mostly on/off-line stuff

[Miles Lane <miles@megapathdsl.net>]

Douglas Gilbert wrote:
> 
> David Brownell wrote:
> >
> > 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.
> > [snip]
> 
> Devfs has the useful property that only devices that are
> present and have their drivers ready appear in the /dev
> hierarchy. In the case of SCSI devices, devfs maintains
> this dynamically via calls in the _attach() and _detach()
> functions within the upper level drivers. The new
> directory notification capability in lk 2.4 (see
> Documentation/dnotify.txt) could then be used to detect
> changes in the /dev directory (or below).

Wouldn't we need to implement two SCSI hotplugging solutions, then --
one for when devfs is available and another when it isn't?  If so, there
might still be enough benefit to devfs users to justify the extra work.
Would there be any problem getting identical behavior from both
implementations?  Would we consider supporting only one configuration
(devfs only)?  That would seem like a bad idea.

Perhaps we'd have a situation where hotplugging works a little better
when the installation uses devfs.  That would provide some incentive 
to distributions to ship with devfs preconfigured. 

	Miles

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel