On Thu, Sep 25, 2014 at 1:57 AM, Rob Jones <rob.jones@xxxxxxxxxxxxxxx> wrote: > > > On 24/09/14 19:06, Kees Cook wrote: >> >> On Wed, Sep 24, 2014 at 4:15 AM, Rob Jones <rob.jones@xxxxxxxxxxxxxxx> >> wrote: >>> >>> Series resubmitted due to a typo in an email address. >>> >>> This patch series implements and documents a new interface function for >>> seq_file. >>> >>> The existing set of open functions: seq_open(), seq_open_private() and >>> __seq_open_private() satisfy the majority of use cases however there is >>> one more use case that is also very common that this new function >>> addresses. >>> >>> This case is where the iterator needs information that is available only >>> at >>> the time the seq_file is opened but does not need any space allocated, >>> e.g. >>> access to the inode structure. This type of open occurs, by my best >>> estimate, >>> in well over 40 places. >>> >>> Using the new function saves at least two lines of boilerplate code per >>> instance as well as making the code easier to follow. The additional code >>> in seq_file.c to implement the function is minimal as the first place >>> that >>> code can be removed is within seq_file.c itself. >>> >>> Once this patch is accepted, the instances of boilerplate code can be >>> addressed. >> >> >> Would it be possible to write a coccinelle patch for the replacements? > > > I'm afraid I don't know what that means. It's a very flexible tool that should be able to find all the places where this pattern is being used, and you can replace it with the new function call: http://lwn.net/Articles/315686/ -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html