Re: simplify procfs code for seq_file instances V3

On Wed, May 16, 2018 at 11:43:04AM +0200, Christoph Hellwig wrote: > We currently have hundreds of proc files that implement plain, read-only > seq_file based interfaces. This series consolidates them using new > procfs helpers that take the seq_operations or simple show callback > directly. > >

Re: simplify procfs code for seq_file instances V3

On Wed, May 16, 2018 at 11:43:04AM +0200, Christoph Hellwig wrote: > We currently have hundreds of proc files that implement plain, read-only > seq_file based interfaces. This series consolidates them using new > procfs helpers that take the seq_operations or simple show callback > directly. > >

simplify procfs code for seq_file instances V3

We currently have hundreds of proc files that implement plain, read-only seq_file based interfaces. This series consolidates them using new procfs helpers that take the seq_operations or simple show callback directly. A git tree is available at: git://git.infradead.org/users/hch/misc.git

simplify procfs code for seq_file instances V3

We currently have hundreds of proc files that implement plain, read-only seq_file based interfaces. This series consolidates them using new procfs helpers that take the seq_operations or simple show callback directly. A git tree is available at: git://git.infradead.org/users/hch/misc.git

Re: simplify procfs code for seq_file instances V2

On Sun, May 06, 2018 at 08:19:49PM +0300, Alexey Dobriyan wrote: > On Wed, Apr 25, 2018 at 05:47:47PM +0200, Christoph Hellwig wrote: > > Changes since V1: > > - open code proc_create_data to avoid setting not fully initialized > >entries live > > - use unsigned int for state_size > > Need

Re: simplify procfs code for seq_file instances V2

On Sun, May 06, 2018 at 08:19:49PM +0300, Alexey Dobriyan wrote: > On Wed, Apr 25, 2018 at 05:47:47PM +0200, Christoph Hellwig wrote: > > Changes since V1: > > - open code proc_create_data to avoid setting not fully initialized > >entries live > > - use unsigned int for state_size > > Need

Re: simplify procfs code for seq_file instances V2

On Sun, May 06, 2018 at 06:45:31PM +0100, Al Viro wrote: > On Sun, May 06, 2018 at 08:19:49PM +0300, Alexey Dobriyan wrote: > > @@ -62,9 +62,9 @@ struct proc_dir_entry { > > umode_t mode; > > u8 namelen; > > #ifdef CONFIG_64BIT > > -#define SIZEOF_PDE_INLINE_NAME (192-139) > >

Re: simplify procfs code for seq_file instances V2

On Sun, May 06, 2018 at 06:45:31PM +0100, Al Viro wrote: > On Sun, May 06, 2018 at 08:19:49PM +0300, Alexey Dobriyan wrote: > > @@ -62,9 +62,9 @@ struct proc_dir_entry { > > umode_t mode; > > u8 namelen; > > #ifdef CONFIG_64BIT > > -#define SIZEOF_PDE_INLINE_NAME (192-139) > >

Re: simplify procfs code for seq_file instances V2

On Sun, May 06, 2018 at 08:19:49PM +0300, Alexey Dobriyan wrote: > +++ b/fs/proc/internal.h > @@ -48,8 +48,8 @@ struct proc_dir_entry { > const struct seq_operations *seq_ops; > int (*single_show)(struct seq_file *, void *); > }; > - unsigned int state_size; >

Re: simplify procfs code for seq_file instances V2

On Sun, May 06, 2018 at 08:19:49PM +0300, Alexey Dobriyan wrote: > +++ b/fs/proc/internal.h > @@ -48,8 +48,8 @@ struct proc_dir_entry { > const struct seq_operations *seq_ops; > int (*single_show)(struct seq_file *, void *); > }; > - unsigned int state_size; >

Re: simplify procfs code for seq_file instances V2

On Wed, Apr 25, 2018 at 05:47:47PM +0200, Christoph Hellwig wrote: > Changes since V1: > - open code proc_create_data to avoid setting not fully initialized >entries live > - use unsigned int for state_size Need this to maintain sizeof(struct proc_dir_entry): Otherwise ACK fs/proc/ part.

Re: simplify procfs code for seq_file instances V2

On Wed, Apr 25, 2018 at 05:47:47PM +0200, Christoph Hellwig wrote: > Changes since V1: > - open code proc_create_data to avoid setting not fully initialized >entries live > - use unsigned int for state_size Need this to maintain sizeof(struct proc_dir_entry): Otherwise ACK fs/proc/ part.

Re: simplify procfs code for seq_file instances V2

Note that your kernel hits the: inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes: (ptrval) (fs_reclaim){?.+.}, at: fs_reclaim_acquire+0x12/0x35 {HARDIRQ-ON-W} state was registered at:

Re: simplify procfs code for seq_file instances V2

Note that your kernel hits the: inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes: (ptrval) (fs_reclaim){?.+.}, at: fs_reclaim_acquire+0x12/0x35 {HARDIRQ-ON-W} state was registered at:

Re: simplify procfs code for seq_file instances

On Tue, Apr 24, 2018 at 06:06:53PM +0200, Christoph Hellwig wrote: > On Tue, Apr 24, 2018 at 08:19:16AM -0700, Andrew Morton wrote: > > > > I want to ask if it is time to start using poorman function overloading > > > > with _b_c_e(). There are millions of allocation functions for example, > > > >

Re: simplify procfs code for seq_file instances

On Tue, Apr 24, 2018 at 06:06:53PM +0200, Christoph Hellwig wrote: > On Tue, Apr 24, 2018 at 08:19:16AM -0700, Andrew Morton wrote: > > > > I want to ask if it is time to start using poorman function overloading > > > > with _b_c_e(). There are millions of allocation functions for example, > > > >

simplify procfs code for seq_file instances V2

We currently have hundreds of proc files that implement plain, read-only seq_file based interfaces. This series consolidates them using new procfs helpers that take the seq_operations or simple show callback directly. A git tree is available at: git://git.infradead.org/users/hch/misc.git

simplify procfs code for seq_file instances V2

We currently have hundreds of proc files that implement plain, read-only seq_file based interfaces. This series consolidates them using new procfs helpers that take the seq_operations or simple show callback directly. A git tree is available at: git://git.infradead.org/users/hch/misc.git

Re: simplify procfs code for seq_file instances

On Tue, Apr 24, 2018 at 08:19:16AM -0700, Andrew Morton wrote: > > > I want to ask if it is time to start using poorman function overloading > > > with _b_c_e(). There are millions of allocation functions for example, > > > all slightly difference, and people will add more. Seeing /proc interfaces

Re: simplify procfs code for seq_file instances

On Tue, Apr 24, 2018 at 08:19:16AM -0700, Andrew Morton wrote: > > > I want to ask if it is time to start using poorman function overloading > > > with _b_c_e(). There are millions of allocation functions for example, > > > all slightly difference, and people will add more. Seeing /proc interfaces

Re: simplify procfs code for seq_file instances

On Tue, 24 Apr 2018 16:23:04 +0200 Christoph Hellwig wrote: > On Thu, Apr 19, 2018 at 09:57:50PM +0300, Alexey Dobriyan wrote: > > > git://git.infradead.org/users/hch/misc.git proc_create > > > > > > I want to ask if it is time to start using poorman function overloading > >

Re: simplify procfs code for seq_file instances

On Tue, 24 Apr 2018 16:23:04 +0200 Christoph Hellwig wrote: > On Thu, Apr 19, 2018 at 09:57:50PM +0300, Alexey Dobriyan wrote: > > > git://git.infradead.org/users/hch/misc.git proc_create > > > > > > I want to ask if it is time to start using poorman function overloading > > with _b_c_e().

Re: simplify procfs code for seq_file instances

On Thu, Apr 19, 2018 at 09:57:50PM +0300, Alexey Dobriyan wrote: > > git://git.infradead.org/users/hch/misc.git proc_create > > > I want to ask if it is time to start using poorman function overloading > with _b_c_e(). There are millions of allocation functions for example, > all slightly

Re: simplify procfs code for seq_file instances

On Thu, Apr 19, 2018 at 09:57:50PM +0300, Alexey Dobriyan wrote: > > git://git.infradead.org/users/hch/misc.git proc_create > > > I want to ask if it is time to start using poorman function overloading > with _b_c_e(). There are millions of allocation functions for example, > all slightly

Re: simplify procfs code for seq_file instances

> git://git.infradead.org/users/hch/misc.git proc_create I want to ask if it is time to start using poorman function overloading with _b_c_e(). There are millions of allocation functions for example, all slightly difference, and people will add more. Seeing /proc interfaces doubled like this

Re: simplify procfs code for seq_file instances

> git://git.infradead.org/users/hch/misc.git proc_create I want to ask if it is time to start using poorman function overloading with _b_c_e(). There are millions of allocation functions for example, all slightly difference, and people will add more. Seeing /proc interfaces doubled like this

simplify procfs code for seq_file instances

We currently have hundreds of proc files that implement plain, read-only seq_file based interfaces. This series consolidates them using new procfs helpers that take the seq_operations or simple show callback directly. A git tree is available at: git://git.infradead.org/users/hch/misc.git

simplify procfs code for seq_file instances

We currently have hundreds of proc files that implement plain, read-only seq_file based interfaces. This series consolidates them using new procfs helpers that take the seq_operations or simple show callback directly. A git tree is available at: git://git.infradead.org/users/hch/misc.git