On Wed, 2016-06-29 at 18:50 +0530, Rajneesh Bhardwaj wrote: > On Wed, Jun 29, 2016 at 03:48:25PM +0300, Andy Shevchenko wrote: > > On Wed, 2016-06-29 at 17:46 +0530, Rajneesh Bhardwaj wrote: > > > On Wed, Jun 29, 2016 at 02:49:45PM +0300, Andy Shevchenko wrote: > > > > On Wed, 2016-06-29 at 13:33 +0530, Rajneesh Bhardwaj wrote: > > > > > On Tue, Jun 28, 2016 at 01:05:07PM +0300, Andy Shevchenko > > > > > wrote: > > > > > > > > > If it touches the same attribute it needs to be seen first before > > applying this one. > > > > No, this attribute wont be touched. So, if there is no objections (taking into consideration minors you mentioned) I think the patch can be applied. > Can we have seq_printf for such cases and use > > > DEFINE_DEBUGFS_ATTRIBUTE > > > for > > > other simple attributes? Doing this might raise some coding style > > > consistency > > > concerns though so lets wait to hear Darren's opinion on this > > > patch. > > > > For the rest we have to see the implementation and decide how to > > proceed > > (since it's a debugfs dedicated for _debugging_) we might change it > > in > > the way we like. Though I don't encourage people to do this. I like > > interfaces on which people thought before implementing. > > > > Sure, i am fine with DEFINE_DEBUGFS_ATTRIBUTE but would like to leave > the scope > for having seq_printf for future patches i.e. linux/seq_file.h and > thus would > have a dependency on struct file_operations for seq_read. Of course! No-one is insisting to use only the macro and simple attributes. -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
