All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.