Messages in this thread | | | Date | Fri, 03 Jul 2009 07:55:13 +0200 | From | Michal Simek <> | Subject | Re: [microblaze-uclinux] [PATCH 03/11] microblaze: fall back on generic header files for the ABI |
| |
Arnd Bergmann wrote: > On Thursday 02 July 2009, John Williams wrote: >> However, we've just "broken" the ABI in 2.6.31, if we merge further >> ABI breakage in 2.6.32 it's more pain and confusion. >> >> So, unless we can merge and validate this ABI breakage during the >> 2.6.31-rc cycle, I think we need to hold on changes that would break >> the ABI again, so soon. >> >> Longer term there will be a complete redo of glibc up to the latest >> version, which will obviously require a new toolchain for users - I >> think that is the right place to do the next round of ABI breakage. >> >> Any thoughts? > > Normally the rule is to never break the ABI at all, even in a major > update of glibc. > > Initially I had hoped that we could do the change before 2.6.30 and > I worked hard on getting the ABI patches to you early enough for > that. After that failed, I made sure that you had everything in > place for 2.6.31 and I believed that Michal said he would integrate > that in the microblaze-mmu merge, before you actually start seeing > users on the mainline kernel.
we are talking about minor change - I know it break ABI a little bit but don't be scared with it. Two changes - first ssize_t is no problem - just warning messages Second change kernel_mode_t from short to int breaks only ipc structures. We are working on solving problem about another IPC trouble. I found a problem with some syscalls which needs to be fixed in kernel and glibc - we will need newest toolchain for it in any case. John just wanted to be sure that we will have working correct version. I added most of your patches to my next branch for testing. I expect that Stephen merge it to next soon.
Thanks for your work, Michal
> > If we don't get that into 2.6.31 any more (and the chances > have slimmed down a lot after the end of the merge window), I > think we should just declare complete failure and not touch > the ABI any more, however broken it may be. > > In over 14 months, not even the most basic fixes to the ABI > that I mentioned in the first review have been applied: > > On Tuesday 15 April 2008, Michal Simek wrote: >> Arnd Bergmann wrote: >>> * Your syscall ABI is largely obsolete. A third of the syscalls you >>> define should not even be there in the first place as they have been >>> replaced by newer versions. E.g. you have select, _newselect and pselect6, >>> where just pselect6 would be sufficient -- you don't need to worry about >>> backwards compatibility if you don't have existing code. A good start >>> would be to take the arch/blackfin syscall list and further reduce it >>> from there. Further examples are: >>> - replace socketcall with separate syscall entry points >>> - replace ipc with a separate entry points >>> - remove all the legacy signal handling from arch/microblaze/kernel/signal.c >>> - remove sys_mmap, sys_olduname and sys_vfork >>> - finally define a generic sys_mmap2 and sys_uname in kernel/ so you don't >>> need another copy in arch/microblaze/kernel >>> - Use 64 bit off_t, and 32 bit uid_t, gid_t etc. >> This kernel don't need to keep backward compatibility. No one will port to >> previous version. I'll look at your points and I'll send you what I do. > > Arnd <>< > ___________________________ > microblaze-uclinux mailing list > microblaze-uclinux@itee.uq.edu.au > Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux > Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/ > >
-- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854
| |