On Wed, Aug 15, 2012 at 10:29:27PM +0100, Al Viro wrote:
> This, BTW, is too convoluted for its own good. What you need is
> something like
> struct whatever {
> struct seq_file *m;
> struct file *f;
> int flags;
> };
> with single allocation of that sucker in your ->open(). Set
On Wed, Aug 15, 2012 at 10:29:27PM +0100, Al Viro wrote:
>
> This, BTW, is too convoluted for its own good. What you need is
> something like
> struct whatever {
> struct seq_file *m;
> struct file *f;
> int flags;
> };
> with single allocation of that sucker in your ->open().
On Wed, Aug 15, 2012 at 10:16:28PM +0100, Al Viro wrote:
> On Wed, Aug 15, 2012 at 01:21:19PM +0400, Cyrill Gorcunov wrote:
> > -static int fdinfo_open_helper(struct inode *inode, int *f_flags, struct
> > path *path)
> > +static int fdinfo_open_helper(struct inode *inode, int *f_flags, struct
> >
On Wed, Aug 15, 2012 at 01:21:19PM +0400, Cyrill Gorcunov wrote:
> struct proc_fdinfo {
> - loff_t f_pos;
> - int f_flags;
> + struct file *f_file;
> + int f_flags;
> };
> + struct proc_fdinfo *fdinfo;
> + struct seq_file *m;
> + int ret;
>
>
On Wed, Aug 15, 2012 at 01:21:19PM +0400, Cyrill Gorcunov wrote:
> -static int fdinfo_open_helper(struct inode *inode, int *f_flags, struct path
> *path)
> +static int fdinfo_open_helper(struct inode *inode, int *f_flags, struct file
> **f_file, struct path *path)
Bloody bad taste, that... This
On Wed, Aug 15, 2012 at 01:07:03AM +0100, Al Viro wrote:
> On Wed, Aug 15, 2012 at 02:21:47AM +0400, Cyrill Gorcunov wrote:
> > > Hmm, in very first versions I've been using one ->show method, but
> > > then I thought that this is not very correlate with seq-files idea
> > > where for each record s
On Wed, Aug 15, 2012 at 02:21:47AM +0400, Cyrill Gorcunov wrote:
> > Hmm, in very first versions I've been using one ->show method, but
> > then I thought that this is not very correlate with seq-files idea
> > where for each record show/next sequence is called. I'll update (this
> > for sure will
On Wed, Aug 15, 2012 at 01:56:16AM +0400, Cyrill Gorcunov wrote:
> > > struct file_operations {
> > > struct module *owner;
> > > + struct seq_operations *fdinfo_ops;
> >
> > IDGI. Why on the earth do you need the whole iterator? All it takes
> > is show_fdinfo(struct seq_file *m, struct file
On Tue, Aug 14, 2012 at 10:27:21PM +0100, Al Viro wrote:
> On Tue, Aug 14, 2012 at 11:56:49PM +0400, Cyrill Gorcunov wrote:
> > Al, does the patch below looks better? If so I'll fix up the rest.
>
> > struct file_operations {
> > struct module *owner;
> > + struct seq_operations *fdinfo_ops
On Tue, Aug 14, 2012 at 11:56:49PM +0400, Cyrill Gorcunov wrote:
> Al, does the patch below looks better? If so I'll fix up the rest.
> struct file_operations {
> struct module *owner;
> + struct seq_operations *fdinfo_ops;
IDGI. Why on the earth do you need the whole iterator? All i
On Tue, Aug 14, 2012 at 10:35:58PM +0400, Cyrill Gorcunov wrote:
> On Tue, Aug 14, 2012 at 07:31:42PM +0100, Al Viro wrote:
> > > Initially we considered to inject some "show" metod to
> > > file_operations but since there really a number of
> > > file_operations declared inside kernel (and in real
On Tue, Aug 14, 2012 at 07:31:42PM +0100, Al Viro wrote:
> > Initially we considered to inject some "show" metod to
> > file_operations but since there really a number of
> > file_operations declared inside kernel (and in real the
> > further patches cover onle eventfd/epoll/inotify) the
> > waste
On Tue, Aug 14, 2012 at 06:03:45PM +0400, Cyrill Gorcunov wrote:
> This patch brings ability to plug in auxiliary fdinfo providers.
> For example in further patches eventfd, evenpoll and fsnotify
> will print out information associated with files.
>
> This feature is CONFIG_CHECKPOINT_RESTORE guar
On 08/14/2012 06:03 PM, Cyrill Gorcunov wrote:
> This patch brings ability to plug in auxiliary fdinfo providers.
> For example in further patches eventfd, evenpoll and fsnotify
> will print out information associated with files.
>
> This feature is CONFIG_CHECKPOINT_RESTORE guarded to eliminate
>
14 matches
Mail list logo
