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. -- 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
