On Thursday 24 March 2011, Jonathan Cameron wrote: > Advantages I can see from this experiement > > 1) Simple drivers are more consise. > 2) It is infact possible to do this for a lot of cases (I had > my doubts ;) > 3) It gives us many of the rigid constraints that the many > attribute macros now handle in a nice clean form. Very nice! > Disadvantages: > > 1) The core code is rather more complex than I'd like. Yes, but I think not overly so. Moving complexity from the drivers into the core should almost always be worth it in the long run. Remember that people who write the drivers should not need to worry about many of the complexities of kernel hacking, such as sysfs attributes or character devices. The more of that you can do in the core, the less work you have helping your downstream developers. > 2) There are cases I haven't yet worked out how to handle properly > - for example, our lis3l02dq used to output accel_mag_value > as the threshold value is shared across all high and low threshold > interrupts. Right now I have no way of specifying this level > of control for the events lines. > Also the use of shared event handlers is clunky to say the least. > This may go away when we rethink the event system though. I think reworking the way that event buffers work is quite central here, although mostly orthogonal to the rework of the internal API. > 3) Putting hard requirements on numeric formatting of some > parameters is a pain. If nothing else I need to write a fixed point > input function. Yes, but at least you only need to write it once ;-) > p.s. Despite Arnd's original thread going to lkml I've kept this > on list for now (+ Arnd of course!) because I want to pin it down > a bit more before throwing it out more generally. Fair enough. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
