Messages in this thread | | | Date | Wed, 24 Sep 2014 11:06:37 -0700 | Subject | Re: [PATCH RESUBMIT 0/2] fs/seq_file: Add seq_open_init() | From | Kees Cook <> |
| |
On Wed, Sep 24, 2014 at 4:15 AM, Rob Jones <rob.jones@codethink.co.uk> 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@chromium.org>
-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
| |