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@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
