From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [PATCH] seq_file: Allow private data to be supplied on seq_open
Date: Wed, 6 Aug 2014 17:02:59 +0100
Message-ID: <20140806160259.GR18016@ZenIV.linux.org.uk>
References: <1406655593-12626-1-git-send-email-rob.jones@codethink.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kernel@lists.codethink.co.uk,
	ebiederm@xmission.com, ian.molton@codethink.co.uk
To: Rob Jones <rob.jones@codethink.co.uk>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <1406655593-12626-1-git-send-email-rob.jones@codethink.co.uk>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Tue, Jul 29, 2014 at 06:39:53PM +0100, Rob Jones wrote:

> At the moment these consumers have to obtain the struct seq_file pointer
> (stored by seq_open() in file->private_data) and then store a pointer to
> their own data in the private field of the struct seq_file so that it
> can be accessed by the iterator functions.
> 
> Although this is not a long piece of code it is unneccessary boilerplate.

How many of those do we actually have?

> seq_open() remains in place and its behaviour remains unchanged so no
> existing code should be broken by this patch.

I have no objections against such helper, but I's rather have it
implemented via seq_open() (and as a static inline, not an export),
not the other way round.  Oh, and conversion of at least some users would
be nice to have as well...