On Sun, 2015-05-03 at 08:50 +0200, Christoph Hellwig wrote: > On Sat, May 02, 2015 at 06:01:03PM -0700, Nicholas A. Bellinger wrote: > > I want to keep the ability for individual backends to define their own > > attributes at runtime. > > > > That said, I'd rather move the original two types (IBLOCK, FILEIO, > > RAMDISK type + PSCSI type) into a common set of macros to reduce > > duplication, but still leave enough flexibility for new TCMU attributes > > or a future NVMe backend driver. > > I think there is two cases to considere here: > > (1) a backend or set of backends with a very different set of attributes. > These should have a new transport_type assigned and a different set > of attributes in the core > (2) a backend adding additional attributes. Just like in the fabric > driver case we should define new attribute groups to add them. > > Even with these patches we're ready for (1), and (2) will require a > bit of work when needed. Historically the issue has been there is not a straight-forward way to mix attributes provided by core and provided by a module at run time into the same config_item_type->ct_attrs[]. I don't want to add a new config_group that's just for driver specific attributes, which ends up being confusing for user-space. And I really don't like the idea of going back to hard-coding (into core) which attributes are exposed for different backend driver types. There's no case today where core registers different hard-coded config_item_types based on a module provided flag, and I don't see this series as a good enough reason to start doing that now. > But at the same time we have a huge reduction > in code size and complexity, and a even bigger reduction in binary size > and a much cleaner interface right now. I don't see this series reducing complexity significantly for new drivers, or providing a much cleaner interface. We've always allowed fabric drivers to populate their own attributes at runtime, and it's never been a problem for people writing new fabric drivers. The backend drivers should have operated the same way since day one, but they didn't. Now that they do, I don't see the benefit of going back to the old way that limits flexibility just to save LOC. --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
