[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071231193801.GS13821@ca-server1.us.oracle.com>
Date: Mon, 31 Dec 2007 11:38:01 -0800
From: Mark Fasheh <mark.fasheh@...cle.com>
To: Marcin Slusarz <marcin.slusarz@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
kernel-janitors <kernel-janitors@...r.kernel.org>,
ocfs2-devel@....oracle.com
Subject: Re: [RFC][PATCH] byteorder: introduce le32_add_cpu & friends to
core
On Sun, Dec 30, 2007 at 08:06:34PM +0100, Marcin Slusarz wrote:
> There are many places where these functions would be useful.
> (just look at: grep -r 'cpu_to_[ble12346]*([ble12346]*_to_cpu.*[-+]' linux-src/)
> What do you think?
>
> ps: this patch depends on http://lkml.org/lkml/2007/12/25/35
> --
>
> add inline functions which add native byte order variable to
> little/big endian variable to core header and as an example
> convert ext3 to use them
You might want to note where you got these functions from in your message.
Also, it would be easier to follow these changes if you had broken things up
into two patches - one which moved stuff from ocfs2 into generic helpers and
a 2nd one to convert ext3.
Looking into my crystal ball, I see a bunch of "convert to using byteorder
math macros" patches coming down the pipe. Since we're talking about disk
fields where a mistake could be costly, I suggest that any patch more than a
couple of lines should be tested by the submitter with sparse. A statement
that sparse didn't produce any new warnings (with the patch applied) could
be included in the description.
--Mark
--
Mark Fasheh
Principal Software Developer, Oracle
mark.fasheh@...cle.com
--
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