On Fri, 2015-03-06 at 11:15 -0800, Andy Grover wrote: <SNIP> > This isn't a problem, because having a configuration for a device's WWNs > in configfs does not mean the device must be present. When the device > shows up then the target config will be used for it, and if the device > is removed the configuration no longer does anything, but still remains. > > What's in configfs reflects only the config, which is why I'm wondering > if adding sysfs support might also be a good thing. sysfs would let LIO > create entries to better reflect actual running state, and be less > limited in reporting status on only "things that have config". > > For example, LIO requires an ACL for all initiators but has a setting to > autogenerate these if per-ACL lun-mapping & auth is not desired. There's > no way for userspace to get a list of generated ACLs -- Thanks for the reminder. Just posted a small series for allowing fabric drivers to expose this using a new 'dynamic_session' TPG attribute, so that user-space can optionally perform dynamic -> explicit se_node_acl conversion ... > maybe userspace > wants to make it easy to convert generated ACLs to actual ACLs. LIO > can't create configfs nodes in-kernel and each configfs file is limited > to PAGE_SIZE so we can't just have a configfs entry that lists all of > them. ... which yes, like all sysfs + configfs attrs is currently limited to a PAGE_SIZE of output. However, given iSCSI IQNs are on average ~64 bytes (max 224 bytes), that is still enough for listing 64 (or 18 worst case) sessions created by dynamically generated se_node_acls . For FC, this is 18 bytes per FC initiator WWPN string using physical port addressing. So for most folk's purposes on a per target endpoint basis, they won't have enough active sessions to run out of buffer here. > That's what I was getting at above: configfs works great for > exactly what we're using it for, but there are other things sysfs does > better so we may want to use both. > Not sure what you had in mind, but I did attempt using both in the early days.. Eg: using /sys/block/$BDEV/ as sysfs symlink source for passing struct block_device into /sys/kernel/config/target/core/$IBLOCK/$DEV/. IIRC, Greg-KH's response back then was along the lines of 'thanks, but please stop now and walk away slowly'. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
