From: Harvey Harrison <harvey.harrison@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: torvalds@linux-foundation.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH 1/2] byteorder: add a new include/linux/swab.h to define byteswapping functions
Date: Thu, 17 Jul 2008 16:23:03 -0700 [thread overview]
Message-ID: <1216336983.6029.62.camel@brick> (raw)
In-Reply-To: <20080717155953.5cddc48d.akpm@linux-foundation.org>
On Thu, 2008-07-17 at 15:59 -0700, Andrew Morton wrote:
> On Tue, 15 Jul 2008 12:01:49 -0700
> Harvey Harrison <harvey.harrison@gmail.com> wrote:
>
> > Collect the implementations from include/linux/byteorder/swab.h, swabb.h
> > in swab.h
>
> I'm afraid I've been basically ignoring the storm of byteorder and
> related patches simply because I do not have a large enough brain to
> work out wth is going on.
>
> I get the impression that there's a great storm of random patches, some
> of which are repeats, with a distressing number of updates all with no
> overall plan. Probably I'm wrong about that, but making it all not
> _look_ like that would really help.
>
> So ho hum. I merged these two into -mm, at the tail of the queue, in a
> new "byteorder" "tree", probably for 2.6.28. We could bump them up
> into 2.6.27-rc1 if that would help merging followup stuff out into the
> subsystem trees during the 2.6.27-rcX cycle.
>
> But please be aware that this ongoing patchstorm is quite confusing
> from where I sit, and I just haven't been able to justify expending all
> the time which it seems that it requires for me to work out just what
> the heck is going on.
>
> So please, send the patches less frequently, in larger batches, after
> lots of testing. Each series should have some overall theme which is
> clearly explained in an easy-to-follow fashion.
A little context then:
With these two merged, I can start moving each arch over to the new byteorder
headers one at a time through the arch maintainers, so I would appreciate it
if they went upstream soonish.
The new headers are not used, and nothing at all changes for arches than do
not opt-in.
The advantage of the new headers are that:
1) there is a _standard_ way for each arch to provide optimized byteswapping
routines (swab etc), and all of the endian-dependant helpers cpu_to_* are
pulled up into linux/byteorder.h
2) we can now rely on __LITTLE_ENDIAN/_BIG_ENDIAN being defined in one place
and the checks for setting both/neither are unified in the linux/ header.
3) The linux/byteorder/ folder is consolidated now and removed, with a few
includes that were directly including byteorder/swabb.h removed as the implementation
now unconditionally provides this functionality.
4) With the implementation all moving to linux/byteorder, asm/byteorder no longer
is the best include, so I have a series that replaces all asm/ with linux/
compatibly, there is no flag day, once all the asm/ includes are gone
we can remove one include in the linux/ header.
5) The new implementation of cpu_to_*, etc does compile-time constant folding,
removing the need for all of the __constant_* versions which another series
then removes. Again, no flag day, can proceed at its own pace without breaking anything.
6) Checks throughout the tree for __BIG_ENDIAN/__LITTLE_ENDIAN can be removed/simplified
as the linux header now does this check centrally.
I've been rebasing the 65 patch series against linux-next each day, let me know when you
want it, but it breaks down to:
2 patches which you just merged
1 patch wiring all the arches...can be easily split.
<nothing further until all arches have moved over>
1 patch removing direct includes of linux/byteorder/swabb.h
1 patch removing linux/byteorder/*
2 patches consolidating endian tests/adding an include to linux/byteorder.h to make
_either_ asm or linux/ ok to include directly
36 patches changing asm/byteorder to linux/byteorder throughout the tree and
finally making linux/byteorder.h the intended header for direct includes.
The rest of the patches are removals of the __constant_* endian helpers
replacing them with the regular versions that now do compile-time
folding, and finally removing the __constant versions entirely.
Cheers,
Harvey
prev parent reply other threads:[~2008-07-17 23:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-15 19:01 [PATCH 1/2] byteorder: add a new include/linux/swab.h to define byteswapping functions Harvey Harrison
2008-07-17 22:59 ` Andrew Morton
2008-07-17 23:23 ` Harvey Harrison [this message]
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=1216336983.6029.62.camel@brick \
--to=harvey.harrison@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).