Re: [Lsf-pc] [LSF/MM TOPIC] Unifying the LIO and SCST target drivers

[Bart Van Assche <bart.vanassche@sandisk.com>]

On 03/05/15 14:23, Christoph Hellwig wrote:
> This is exactly why I didn't want to put this topic onto the LSF agenda.
> 
> There are tons of very useful fixes and cleanus in Barts series, and I'd
> really like to get them in ASAP.
> 
> As Nic pointed out (in a slightly unhelpful tone) we're not interested
> in adding any hooks for out of tree code.  But if SCST needs hooks it
> should eithe switch to the in-kerel way of doing it, or if has a clearly
> better way of doing it merge that into the kernel.  I'm pretty sure
> there are various pieces that would make a lot of sense to merge either
> way, and getting towards a single target with a broad maintainer and
> user base seem like a way better approach that adding weird hooks.  But
> I don't think that's even on the table for LSF this year, maybe next
> year if everyone involved works hard on it.

Hello Christoph,

If we would do what Nic proposed - modify SCST such that it uses
configfs instead of sysfs - then that would result in the removal of at
least one SCST feature that is important to its users, namely automatic
population of the configuration filesystem with hardware target port
information. Apparently Nic does not want to convert LIO from configfs
to sysfs. The reason I proposed to add empty transport_register_wwn()
and transport_unregister_wwn() functions in the LIO core is because this
allows LIO to keep using configfs and does not require to remove
features from SCST. BTW, a message that was posted four years ago on the
linux-scsi mailing list contains an excellent explanation of why sysfs
has been chosen for the SCST user space API. From
http://thread.gmane.org/gmane.linux.scsi/65615/focus=65618: <quote>
I think the overall philosophical point here, and it's a good one
because I've heard it from several sources, is that it's not possible to
separate configuration from status completely.  The classic example is
where the kernel has to validate and adjust config information, but the
storage specific one is where events alter the topology.  In either
case, the configfs tree gets out of sync with reality if the kernel does
the adjustment..  Just saying we have to use a user space tool to fix it
up is a bit of a cop out because the kernel has already adjusted its own
configuration, so getting userspace to work out what the kernel's done
and adjust configfs is a bit sub optimal.</quote>

Bart.