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

Al Viro <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• References:
  • [PATCH 3/18] allow callers of seq_open do allocation themselves
    • From: Al Viro <[email protected]>

• Prev by Date: [PATCH] backup timer for UARTs that lose interrupts
• Next by Date: Re: [PATCH] fix de_thread() vs send_group_sigqueue() race
• Previous by thread: Re: [OT] Re: [PATCH 3/18] allow callers of seq_open do allocation themselves
• Next by thread: [PATCH 2/18] cleanups and bug fix in do_loopback()
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]