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@xxxxxxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
