On Wed, 2015-05-06 at 16:52 +0200, Christoph Hellwig wrote: > On Sun, May 03, 2015 at 10:25:11PM -0700, Nicholas A. Bellinger wrote: > > 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[]. > > Actually we're doing that for fabric modules now, with the patch > originally from Bart that I sent you for 4.1, and it works just fine. > We don't even need different config groups in that case. > Yes, please. > > 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. > > Actually the model fabric drives follow now is very similar to the > one this patch tries to introduce, that what it is based on. Note that > this isn't about saving lines of code. It's about: > > a) making it hard to mess up setting up the attributes correctly. > All the attributes for backends at the moment aren't backend-specific, > they expose core attributes. > b) provide an as simple as possible interface for backends > c) save binary size > > Less source code is just an artefact of the overall better design. Isn't there a better way to do this without have to use multiple config_item_type in target_core_configfs.c code..? Hard-coding specific backend driver type config_item_type still seems like a hack to me. --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
