Re: microblaze syscall list

[Michal Simek]

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




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/