public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Tom Zanussi <zanussi@us.ibm.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Andi Kleen <ak@muc.de>,
	Roman Zippel <zippel@linux-m68k.org>,
	Robert Wisniewski <bob@watson.ibm.com>,
	Tim Bird <tim.bird@AM.SONY.COM>,
	karim@opersys.com
Subject: Re: [PATCH] relayfs redux, part 2
Date: Sat, 29 Jan 2005 00:15:27 -0800	[thread overview]
Message-ID: <20050129081527.GD7738@kroah.com> (raw)
In-Reply-To: <16890.38062.477373.644205@tut.ibm.com>

On Fri, Jan 28, 2005 at 01:38:22PM -0600, Tom Zanussi wrote:
> +extern void * alloc_rchan_buf(unsigned long size,
> +			      struct page ***page_array,
> +			      int *page_count);
> +extern void free_rchan_buf(void *buf,
> +			   struct page **page_array,
> +			   int page_count);

As these will be "polluting" the global namespace of the kernel, could
you add "relayfs_" to the front of them?

Also, any reason why you haven't exported the fops of relayfs so that
others can use this in their filesystems (like proc and debugfs)?

> +/**
> + *	rchan_create_file - create relay file, including parent directories
> + *	@chanpath: path to file, including filename
> + *	@dentry: result dentry
> + *	@data: data to associate with the file
> + *
> + *	Returns 0 if successful, negative otherwise.
> + */
> +static inline int rchan_create_file(const char *chanpath,
> +				    struct dentry **dentry,
> +				    struct rchan_buf *data)
> +{
> +	int err;
> +	const char * fname;
> +	struct dentry *topdir;
> +
> +	err = rchan_create_dir(chanpath, &fname, &topdir);
> +	if (err && (err != -EEXIST))
> +		return err;
> +
> +	err = relayfs_create_file(fname, topdir, dentry, data, S_IRUSR);
> +
> +	return err;
> +}

Why not just return the * to the dentry?  Gets rid of one paramater...

Also, if a path is passed to this function, when the "channel" is
finally torn down, that path is not removed, right?  Or did I miss that
in the code somewhere?

> +/**
> + *	check_attribute_flags - check sanity of channel attributes
> + *	@flags: channel attributes
> + *
> + *	Returns 0 if successful, negative otherwise.
> + */
> +static inline int check_attribute_flags(u32 *attribute_flags)
> +{
> +	u32 flags = *attribute_flags;
> +
> +	if ((flags & RELAY_MODE_CONTINUOUS) &&
> +	    (flags & RELAY_MODE_NO_OVERWRITE))
> +		return -EINVAL; /* Can't have it both ways */
> +
> +	if (!(flags & RELAY_MODE_CONTINUOUS) &&
> +	    !(flags & RELAY_MODE_NO_OVERWRITE))
> +		*attribute_flags |= RELAY_MODE_CONTINUOUS; /* Default */
> +
> +	return 0;
> +}

Why be nice to your caller?  Just force them to get the flags right, and
if not, error out, you don't have to provide a "default" as this is a
required parameter to start up a channel, right?

> +/*
> + * Per-cpu relay channel buffer
> + */
> +struct rchan_buf
> +{
> +	void *start;			/* start of channel buffer */
> +	void *data;			/* start of current sub-buffer */
> +	local_t offset;			/* current offset into sub-buffer */
> +	unsigned bufsize;		/* sub-buffer size */
> +	unsigned alloc_size;		/* total buffer size allocated */
> +	unsigned nbufs;			/* number of sub-buffers */
> +	unsigned bufs_produced;		/* count of sub-buffers produced */
> +	unsigned bufs_consumed;		/* count of sub-buffers consumed */
> +	wait_queue_head_t read_wait;	/* reader wait queue */
> +	struct work_struct wake_readers; /* reader wake-up work struct */
> +	struct rchan_callbacks *cb;	/* client callbacks */
> +	struct work_struct work;	/* remove file work struct */
> +	u32 flags;			/* relay channel attributes */
> +	struct dentry *dentry;		/* channel file dentry */
> +	atomic_t refcount;		/* channel refcount */

Please use struct kref for this.

> +	struct page **page_array;	/* array of current buffer pages */
> +	int page_count;			/* number of current buffer pages */
> +	unsigned *padding;		/* padding counts per sub-buffer */
> +	unsigned *commit;		/* commit counts per sub-buffer */
> +	int finalized;			/* buffer has been finalized */
> +} ____cacheline_aligned;

thanks,

greg k-h

  parent reply	other threads:[~2005-01-29  8:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-28 19:38 [PATCH] relayfs redux, part 2 Tom Zanussi
2005-01-28 20:48 ` Tim Bird
2005-01-28 22:24 ` Andrew Morton
2005-01-29  8:08 ` Andi Kleen
2005-01-30  4:58   ` Tom Zanussi
2005-01-31 12:57     ` Andi Kleen
2005-01-31 16:26       ` Tom Zanussi
2005-01-31 19:41         ` Karim Yaghmour
2005-01-31 21:03           ` Tom Zanussi
2005-01-31 21:12             ` Karim Yaghmour
2005-01-31 19:38       ` Karim Yaghmour
2005-01-29  8:15 ` Greg KH [this message]
2005-01-30  5:02   ` Tom Zanussi
2005-01-31 22:10   ` Karim Yaghmour
2005-01-31 22:33     ` Greg KH
2005-01-31 22:35       ` Karim Yaghmour
2005-01-31 23:12 ` Roman Zippel
2005-02-01 15:44   ` Tom Zanussi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050129081527.GD7738@kroah.com \
    --to=greg@kroah.com \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=bob@watson.ibm.com \
    --cc=karim@opersys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tim.bird@AM.SONY.COM \
    --cc=zanussi@us.ibm.com \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox