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: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 patch brings ability to print out auxiliary data associated
with file in procfs interface /proc/pid/fdinfo/fd.
In particular further patches make eventfd, evenpoll, signalfd
and fsnotify to print additional information complete enough
to restore these objects after checkpoint.
To simplify
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
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 show/next
This patch brings ability to print out auxiliary data associated
with file in procfs interface /proc/pid/fdinfo/fd.
In particular further patches make eventfd, evenpoll, signalfd
and fsnotify to print additional information complete enough
to restore these objects after checkpoint.
To simplify
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: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;
fdinfo
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
file
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 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
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
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
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
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
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
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
overhead for those who don't need it at all (this
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
overhead for those who don't need it at all (this
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
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 guarded
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 of memory
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 the
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 it
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 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 *f); have
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 make
32 matches
Mail list logo
