lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 24 Sep 2014 14:39:04 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Rob Jones <rob.jones@...ethink.co.uk>
Cc:	rdunlap@...radead.org, viro@...iv.linux.org.uk,
	linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-kernel@...ethink.co.uk,
	keescook@...omium.org, penguin-kernel@...ove.SAKURA.ne.jp
Subject: Re: [PATCH RESUBMIT 1/2] fs/seq_file: Create new function
 seq_open_init()

On Wed, 24 Sep 2014 12:15:55 +0100 Rob Jones <rob.jones@...ethink.co.uk> wrote:

> Add a new function to help reduce boilerplate code.
> 
> This is a wrapper function for seq_open() that will simplify the code in a
> significant number of cases where seq_open() is currently called.
> 
> It's first use is in __seq_open_private(), thereby recovering most of
> the code space used by the new function.

It would be nice to include one or more of the conversions in this patch
series so we can see what the effects look like.

> --- a/fs/seq_file.c
> +++ b/fs/seq_file.c
> @@ -639,28 +639,38 @@ int seq_release_private(struct inode *inode, struct file *file)
>  }
>  EXPORT_SYMBOL(seq_release_private);
>  
> +int seq_open_init(struct file *f, const struct seq_operations *ops, void *p)
> +{
> +	struct seq_file *s;
> +	int rc;
> +
> +	rc = seq_open(f, ops);
> +	if (rc)
> +		return rc;
> +
> +	s = f->private_data;
> +	s->private = p;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(seq_open_init);

A global exported-to-modules interface should be documented, please. 
Especially when it has a void* argument.  seq_file.c is patchy - some
of it is documented, some of it uses the read-programmers-mind
approach.


__seq_open_private() has
	void *private;

single_open() has
	void *data

And now seq_open_init() has
	void *p

but these all refer to the same thing.  Can we have a bit of
consistency in the naming please?  I suggest "private", to match
the seq_file field.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ