Re: How to add/drop SCSI drives from within the driver?

[Matt Domsch]

On Wed, Dec 15, 2004 at 01:49:18PM -0500, James Bottomley wrote:
> On Wed, 2004-12-15 at 01:24 -0600, Matt Domsch wrote:
> > James, I've been thinking about this a little more, and you may be on
> > to something here. Let each driver add files as such:
> > 
> > /sys/class/scsi_host
> >  |-- host0
> >  |   |-- add_logical_drive
> >  |   |-- remove_logical_drive
> >  |   `-- rescan_logical_drive
> > 
> > Then we can go 2 ways with this.
> > 1) driver functions directly call scsi_add_device(),
> > scsi_remove_device(), and something for rescan (option 2 handles this
> > one cleanly for us).  ATM, megaraid_mbox doesn't implement a rescan
> > function, so this point may be moot. 
> > 
> > 2) driver functions call a midlayer library function, which invokes
> >    /sbin/hotplug with appropriate data, and add a new /etc/hotplug.d
> >    helper app which would then write to these files:
> > to do likewise.
> 
> I'll buy this (option 2).. it seems like a good way to export the
> megaraid specific information and at the same time integrate it more
> fully into the evolving hotplug infrastructure.

Great, I think that's the right long-term solution.  Can we consider
other paths for the short term, while we evolve the hotplug
infrastructure?  I don't know all the details involved in jumping
straight to option 2 today.

Do you plan to apply LSI's driver patch which adds the driver-private
ioctl to provide the mapping from logical drive address to HCTL value?
Both Dell and LSI have products which are lined up to use this new
ioctl because it's the most expedient thing to do, maintains internal
project schedules, etc, which delaying until this sysfs mechanism hits
will greatly impact those schedules. (I know, many folks on this list
don't care about business-side impacts of choices made on-list.)

If you were to apply LSI's ioctl patch, then that patch becomes stage
0.

Stage 1 is what I posted last night, once tested, and the mgmt apps
convert to use that.

The above can happen pretty quickly I think, i.e. before the holidays.

Stage 2 is option 2 above, which removes the driver calling
scsi_add_device() and friends directly.  Userspace apps converted for
stage 1 are none-the-wiser, as their interface hasn't changed.

This is a Jan-Feb kind of thing, to give proper time for all concerns
to be voiced and included in the kernel-internal APIs, /sbin/hotplug
environment, and userspace helper.

Stage 3, convert all other drivers who need a similar mechanism over
to the new helper functions added in stage 2.

This would be ongoing.


Thoughts?

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/