From: Andi Kleen <ak@muc.de>
To: Tom Zanussi <zanussi@us.ibm.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Greg KH <greg@kroah.com>, Andrew Morton <akpm@osdl.org>,
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 3
Date: 4 Feb 2005 23:12:30 +0100
Date: Fri, 4 Feb 2005 23:12:30 +0100 [thread overview]
Message-ID: <20050204221230.GA97506@muc.de> (raw)
In-Reply-To: <16899.55393.651042.627079@tut.ibm.com>
Just a minor comment, not reading it all.
On Fri, Feb 04, 2005 at 02:17:37PM -0600, Tom Zanussi wrote:
_write - write data into the channel
> + * @chan: relay channel
> + * @data: data to be written
> + * @length: number of bytes to write
> + *
> + * Returns the number of bytes written, 0 if full.
> + *
> + * Writes data into the current cpu's channel buffer. irq safe.
This needs a better comment on the allowed contexts.
> + */
> +static inline unsigned relay_write(struct rchan *chan,
> + const void *data,
> + unsigned length)
> +{
> + unsigned long flags;
> + struct rchan_buf *buf = relay_get_buf(chan, smp_processor_id());
Needs to be inside the local_irq_save of course.
> +
> + local_irq_save(flags);
> + if (unlikely(buf->offset + length > chan->subbuf_size))
> + length = relay_switch_subbuf(buf, length);
> + memcpy(buf->data + buf->offset, data, length);
> + buf->offset += length;
> + local_irq_restore(flags);
> +
> + return length;
Is there any useful user case for returning length here?
(e.g. are users likely to handle errors? I doubt it somehow)
If not I would eliminate it.
> +}
> +
> +/**
> + * __relay_write - write data into the channel
> + * @chan: relay channel
> + * @data: data to be written
> + * @length: number of bytes to write
> + *
> + * Returns the number of bytes written, 0 if full.
> + *
> + * Writes data into the current cpu's channel buffer. Preempt safe.
And this needs more comments on the context too.
-Andi
next prev parent reply other threads:[~2005-02-04 22:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-04 20:17 [PATCH] relayfs redux, part 3 Tom Zanussi
2005-02-04 21:10 ` Christoph Hellwig
2005-02-04 22:00 ` Tom Zanussi
2005-02-04 21:39 ` Christoph Hellwig
2005-02-04 22:06 ` Tom Zanussi
2005-02-04 22:12 ` Andi Kleen [this message]
2005-02-04 22:22 ` Tom Zanussi
2005-02-05 6:57 ` Andi Kleen
2005-02-05 9:54 ` [PATCH] relayfs redux, part 3 II - another comment Andi Kleen
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=20050204221230.GA97506@muc.de \
--to=ak@muc.de \
--cc=akpm@osdl.org \
--cc=bob@watson.ibm.com \
--cc=greg@kroah.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.