[dm-devel] Re: [PATCH RFC] move scsi parts of dm hw handlers to scsi layer

[Patrick Mansfield]

On Fri, Jul 21, 2006 at 08:16:56AM -0700, Mike Anderson wrote:
> Mike Christie <michaelc at cs.wisc.edu> wrote:
> > Hannes Reinecke wrote:
> > > Am Fr 21.07.2006 13:55 schrieb Mike Christie <michaelc at cs.wisc.edu>:
> > > 
> > >> Mike Christie wrote:
> > >>> Hannes Reinecke wrote:

> > >>> I was adding my fields when I noticed this comment:
> > >>>
> > >>>
> > >>> * Do not add to this list, use the command line or proc interface to
> > >>>  add
> > >>>  * to the scsi_dev_info_list. This table will eventually go away.
> > >>>
> > >>>
> > >>>> We have to have some sort of device table anyway as these handlers
> > >>>> are
> > >>>> far from being generic, so any sense code which triggers action on
> > >>>> one
> > >>>> device might be perfectly ok for others.
> > >>> When I was looking for the history of that commet, I thought I read
> > >>> that
> > >>> we are supposed to be moving to some userspace approach that pushes
> > >>> that
> > >>> info down via some magic interface.
> > >>>
> > >> I added this comment at the wrong place. I meant to say I thought we
> > >> are
> > >> supposed to be moving away from the kernel devinfo list to some
> > >> userspace one that gets sent down via the module_param or some new
> > >> magic
> > >> interface.
> > > 
> > > Or so they claim. I seem to remember some discussion about it; the net
> > > result was the scsi_devinfo will stay with us for the time being.
> > > 
> > > Otherwise you'll end up having to configure your kernel / module during
> > > startup. With parameters which are static anyway. Can't say I like it.
> > > And the tricky bit is that these information has to be present prior
> > > to any initialisation, so you basically have to feed it during
> > > modprobe time. Not really clever.

I would think distros would like the user space method so they would not
have to release a new kernel to add items to the devinfo / blacklist.

> > He He fun :)
> > 
> > Sticking what we need in devinfo is a lot easier. And I think it makes
> > sense since the devices info we want to bind with is in there already.
> > If nobody says anything, I will send the next version of the path with
> > devinfo integration.
> 
> I think Patrick added the comment and the interface so he can add the
> history. One can use the module or proc interface to pass update devinfo
> information in (the sysfs migration never was done). Well it has the
> drawback stated above it can address the issue that certain devices can be
> supported without a kernel recompile.

I just thought that we should not be putting black lists in the kernel,
and AFAIR thought everyone wanted this type of data in user space (even
back then). The comment in the code has never been enforced. I never did
think of a decent (space efficient) method to access a link list or array
in sysfs.

I didn't look close at the other patches in this thread.

I am attaching some simple user space code I wrote some time ago, feel
free to use it. There is a script version and C version. I don't know
devinfo-current is really current :) 

There should also be a corresponding kernel patch (if distros wanted to
use this) to allow disabling the in-kernel devinfo table.

The script (bload.sh) needs indirection (pointer like reference, this:
${!i}), I don't think nash supports indirection, otherwise the script is
very simple.

Like Hannes said, you need some /etc/modprobe.conf juju to load scsi_mod,
run the attached script or program, and only then allow other scsi modules
to load. Plus similar code in the initrd/ramfs. I actually tried out the
modprobe.conf change at some time, I don't recall the exact modprobe
lines, AFAIR it needed to use the --ignore-install option.

> Post storage summit I started creating a hardware handler in SCSI, but for
> some reason that I do not recall I started working on SDEV state model
> change integrated into devinfo. The thought being that devices would come
> up in a standby state and then all the varied commands to determine path
> state could be executed from user space.
> 
> Well it did solve the issue I was trying to address (passive paths
> generating errors on startup), it would need user space assistance with all
> the plus / minus issues that brings.

-- Patrick Mansfield
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scsi_blacklist.tar.gz
Type: application/x-gzip
Size: 7390 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20060721/5849f1d4/attachment.bin>