Messages in this thread |  | | | Date | Thu, 30 Apr 2009 16:51:29 +0200 | | From | Michal Simek <> | | Subject | Re: [PATCH 29/30] microblaze_mmu_v1: stat.h MMU update |
| |
Arnd Bergmann wrote: > On Thursday 30 April 2009, Michal Simek wrote: > >> 2. header cleanup -> some of them is pain because I have to recompile toolchain >> that's should be a big deal but after recompilation kernel, user apps I am getting some problems. > > Yes, I understand that you have a circular dependency there, but fixing > the ABI can only become harder with time, as more people start using > the current kernel/toolchain combination.
Here is the one advantage that in mainline are only some drivers for Microblaze and the rest is in petalinux. And people can use whole distribution.
> >> 3. syscall cleanup -> we still have old libc and I can't simple remove ancient syscalls > > I had hoped that the way I set __ARCH_WANT_SYSCALL_* in the microblaze > unistd.h would provide an easy way to migrate, because this still defines > almost all traditional system calls (I haven't double-checked if some more > are currently used on microblaze, but they would be easy to add). > This means that as a first step, rebuilding the tool chain (as above) should > be sufficient and not require source-level changes to libc. From that point, > you can remove the remaining __ARCH_WANT_SYSCALL_* defintions one by one, > and change the libc accordingly. > > I could also try building uclibc with the generic headers if I find the > time. Which version do you use, just upstream or do you have a private > libc tree with more changes?
That's good question but harder answer. Glibc is any ancient 3-4 years non mainline version. There are some backports too. I have some comments to it but it is better not to write them.
uclibc version is a little bit better. I had functional port half year mainline version + some private fixes. Currently John W is working on it to get working version with gcc 4.1.2. He has some troubles with it but I hope he solve it soon.
We have troubles because none have taken care about. I hope that we are able to update all the things and repair everything what wrong it.
Michal
> > Arnd <><
-- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854
|  |