lkml.org 
[lkml]   [2008]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: microblaze syscall list
Hi All,

>>> How about this strategy then:
>>> * Change all the data types and syscall numbers in the -for-2.6.27
>>> branch to only include the minimal set, and a modern ABI
>>> * Add the old interfaces as an out-of-tree patch that adds source
>>> level compatibility with the old libc, but does not modify any
>>> of the new interfaces, so that a patched kernel can run all binaries
>>> built for the upstream version.
>>> * phase out the old source interface gradually, as all users update
>>> their libc source code.
>>
>>
>> Any news on this from the microblaze people? Have you made up your mind
>> on what route you want to go?
>
> I think we're still digesting it. I need to sync up with Michal and the
> Xilinx people. The libc and kernel API changes have to happen in
> tandem, otherwise Michal can't properly test the kernel he's pushing.
>
> I am the defacto MicroBlaze uClibc and toolchain "builder" but somewhat
> reluctantly - am trying to convince Xilnx to hand that over to someone
> who is expert at it.
>
> Michal, John L, any thoughts?
>
> John

I am convinced we need to change syscall table. I don't want to maintain old
syscalls. It will be easier to test smaller amount of syscalls. I would like to
talk about with you (John W) via Skype. (Can you send me private email where you
have time?) I talked with Steve about this week. After that I will publish our
proposed way.

Michal






\
 
 \ /
  Last update: 2008-05-02 10:19    [W:0.071 / U:0.560 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site