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

[Hannes Reinecke]

Am Fr 21.07.2006 13:55 schrieb Mike Christie <michaelc at cs.wisc.edu>:

> Mike Christie wrote:
> > Hannes Reinecke wrote:
> >>> The patch below begins to push the scsi hw handler code down to
> >>> the
> >>> scsi
> >>> layer. I only began to covert dm-emc.c and it only hooks in at the
> >>> sense
> >>> decoding in scsi_error.c. I wanted to make sure I was going about
> >>> the
> >>> module loading and binding correctly. With a new target bus we
> >>> could
> >>> do
> >>> some driver model stuff instead, but I was not sure if that was
> >>> appropriate for this?
> >>>
> >> Why don't we use scsi_devinfo for this?
> > 
> > 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.

But we can always ask James B. :-)

Cheers,

Hannes