allow callers of seq_open do allocation themselves

From: Al Viro <[email protected]>
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.

---

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

57865a0565080cc56de9aa5369ea1fc2b6477398

@@ -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

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

nope 8:)

---
~Randy

What format is that date in, please?

---
~Randy

%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

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

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

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

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

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