[pnfs] [PATCH 05/28] pnfsblock: expose scsi interface

[Fredric Isaman]

On Wed, 12 Mar 2008, Jason Glasgow wrote:

> Christoph,
>
> Putting device discovery in user space a valid alternative implementation,
> and we will pursue that model.
>
> -Jason
>
>
> On Wed, Mar 12, 2008 at 12:43 PM, Christoph Hellwig <hch at infradead.org>
> wrote:
>
>> On Wed, Mar 12, 2008 at 06:33:34PM +0200, Benny Halevy wrote:
>>> This calls for a layering violation.
>>>
>>> To fill-in more context, here's an excerpt from the next patch,
>>> showing how you use shost_class to scan all scsi disks:
>>

The referenced code is an adhoc hack that does what we need it to for now. 
We would *love* to be able to just call in to some scsi function that fits 
our needs

>> Yes, absolutely.  No one outside of few places in the core scsi code
>> should ever iterate over the scsi disks.
>>

Is this for locking reasons?

>>> My question is how should a proper API between the scsi layer and
>>> the block layout driver look like?
>>>
>>> Can you list your requirements, e.g.:
>>> - scanning all available devices,
>>>
>>> - discovering new devices on the fly
>>>
>>> - getting notified for new devices?
>>
>> Neither.  pnfs shouldn't open block devices from kernelspace at all,
>> but do it's disovery in userspace.
>>


Basically, we are given a disk signature, (an array of offset, byte
sequence pairs) and want to match it against some visible disk (ignoring
partitions), or know that it is not currently visible.

Thus our requirement are:

Scan all available block devices (though all available SCSI devices is a
workable substitute).

Notification of new devices would be a helpful in optimizing rescans for 
unmapped disk signatures.


As Jason mentions, we will pursue doing this in userspace.

 	Fred