[PATCH 3/18] allow callers of seq_open do allocation themselves

[PATCH 3/18] allow callers of seq_open do allocation themselves

[Al Viro]

From: Al Viro <viro@zeniv.linux.org.uk>
Date: 1131401734 -0500

Allows caller of seq_open() to kmalloc() seq_file + whatever else they want
and set ->private_data to it.  seq_open() will then abstain from doing
allocation itself.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

---

 fs/seq_file.c |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

57865a0565080cc56de9aa5369ea1fc2b6477398
diff --git a/fs/seq_file.c b/fs/seq_file.c
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -28,13 +28,17 @@
  */
 int seq_open(struct file *file, struct seq_operations *op)
 {
-	struct seq_file *p = kmalloc(sizeof(*p), GFP_KERNEL);
-	if (!p)
-		return -ENOMEM;
+	struct seq_file *p = file->private_data;
+
+	if (!p) {
+		p = kmalloc(sizeof(*p), GFP_KERNEL);
+		if (!p)
+			return -ENOMEM;
+		file->private_data = p;
+	}
 	memset(p, 0, sizeof(*p));
 	sema_init(&p->sem, 1);
 	p->op = op;
-	file->private_data = p;
 
 	/*
 	 * Wrappers around seq_open(e.g. swaps_open) need to be

[OT] Re: [PATCH 3/18] allow callers of seq_open do allocation themselves

[Randy.Dunlap]

On Tue, 08 Nov 2005 02:01:31 +0000 Al Viro wrote:

> From: Al Viro <viro@zeniv.linux.org.uk>
> Date: 1131401734 -0500

What format is that date in, please?

> Allows caller of seq_open() to kmalloc() seq_file + whatever else they want
> and set ->private_data to it.  seq_open() will then abstain from doing
> allocation itself.
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

---
~Randy

Re: [OT] Re: [PATCH 3/18] allow callers of seq_open do allocation themselves

[Randy.Dunlap]

On Tue, 8 Nov 2005 14:24:33 +1100 Neil Brown wrote:

> On Monday November 7, rdunlap@xenotime.net wrote:
> > On Tue, 08 Nov 2005 02:01:31 +0000 Al Viro wrote:
> > 
> > > From: Al Viro <viro@zeniv.linux.org.uk>
> > > Date: 1131401734 -0500
> > 
> > What format is that date in, please?
> > 
> 
>  %s %z
> 
> (as date(1) understands it).

Thanks.  I sorta guessed that after I sent the mail.

> Or was this a rhetorical question, meaning to say "Who in their right
> mind would used that sort of date format on a public mailing list?" :-)

nope  8:)

---
~Randy

Re: [OT] Re: [PATCH 3/18] allow callers of seq_open do allocation themselves

[Neil Brown]

On Monday November 7, rdunlap@xenotime.net wrote:
> On Tue, 08 Nov 2005 02:01:31 +0000 Al Viro wrote:
> 
> > From: Al Viro <viro@zeniv.linux.org.uk>
> > Date: 1131401734 -0500
> 
> What format is that date in, please?
> 

 %s %z

(as date(1) understands it).

Or was this a rhetorical question, meaning to say "Who in their right
mind would used that sort of date format on a public mailing list?" :-)

NeilBrown

Re: [OT] Re: [PATCH 3/18] allow callers of seq_open do allocation themselves

[Al Viro]

On Tue, Nov 08, 2005 at 02:24:33PM +1100, Neil Brown wrote:
> On Monday November 7, rdunlap@xenotime.net wrote:
> > On Tue, 08 Nov 2005 02:01:31 +0000 Al Viro wrote:
> > 
> > > From: Al Viro <viro@zeniv.linux.org.uk>
> > > Date: 1131401734 -0500
> > 
> > What format is that date in, please?
> > 
> 
>  %s %z
> 
> (as date(1) understands it).
> 
> Or was this a rhetorical question, meaning to say "Who in their right
> mind would used that sort of date format on a public mailing list?" :-)

git format-patch and used by git applymbox and friends...

Re: [OT] Re: [PATCH 3/18] allow callers of seq_open do allocation themselves

[Linus Torvalds]

On Tue, 8 Nov 2005, Neil Brown wrote:
> On Monday November 7, rdunlap@xenotime.net wrote:
> > 
> > What format is that date in, please?
> 
>  %s %z
> 
> (as date(1) understands it).

Yes. It happens to be one of the formats git understands, and is also 
the least ambiguous. 

> Or was this a rhetorical question, meaning to say "Who in their right
> mind would used that sort of date format on a public mailing list?" :-)

Yeah, it's really only machine-readable. In this case git-readable, 
although git will accept dates in almost any format.

It happens to be the format internally used by git, since it's easy to 
parse and you can't get it wrong.

It may be a mistake to expose it outside in that format, though. The git 
"format patch as email" script will just use the internal date format, 
which is nice from a "you can't get it wrong" angle, but arguably not very 
human-friendly.

Not being able to get it wrong by converting it to a human-readable format 
and then converting it back is a pretty big advantage, though (it's damn 
easy to screw up summer-time and timezone when converting to/from UTC: 
the "%s %z" format doesn't leave any confusion: the seconds is always 
since the epoch in UTC, and the %z is purely informational to tell in 
which timezone the change was made).

			Linus

Re: [OT] Re: [PATCH 3/18] allow callers of seq_open do allocation themselves

[Linus Torvalds]

On Tue, 8 Nov 2005, Al Viro wrote:
> 
> git format-patch and used by git applymbox and friends...

Note that git applymbox can (and normally does) take the date in regular 
RFC 822 email format too, so it's really git format-patch that is the 
culprit here. It _could_ try to turn it back into a regular date, but just 
uses the git internal format because it's easy, lazy, and unambigious.

The easy and lazy parts are probably not very strong arguments. The 
unambigious part is the thing that makes it a killer format.

		Linus

Re: [PATCH 3/18] allow callers of seq_open do allocation themselves

[Jonathan Corbet]

Al Viro <viro@ftp.linux.org.uk> wrote:

> Allows caller of seq_open() to kmalloc() seq_file + whatever else they want
> and set ->private_data to it.  seq_open() will then abstain from doing
> allocation itself.

It looks like seq_release() frees the structure regardless of where it
came from.  So the seq_file structure must be the first field in
whatever structure contains it, and one has to hope that won't change in
the future.  Is that really the way the interface was meant to work?

jon