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? This seems like a good idea. Thanks! Acked-by: Kees Cook <keescook@xxxxxxxxxxxx> -Kees > > The documentation of seq_open() and its variants has been re-worked to try > to guide users towards the most appropriate variant for their application. > > Rob Jones (2): > fs/seq_file: Create new function seq_open_init() > Documentation/filesystem/seq_file: document seq_open_init() > > Documentation/filesystems/seq_file.txt | 58 +++++++++++++++++++++----------- > fs/seq_file.c | 34 ++++++++++++------- > include/linux/seq_file.h | 1 + > 3 files changed, 62 insertions(+), 31 deletions(-) > > -- > 1.7.10.4 > -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
