[klibc] [PATCH 0/1] Porting klibc to AArch64

[H. Peter Anvin]

On 10/09/2013 08:49 AM, Neil Williams wrote:
> 
>>> usr/klibc/arch/aarch64/Kbuild usr/klibc/arch/aarch64/MCONFIG 
>>> usr/klibc/arch/aarch64/crt0.S usr/klibc/arch/aarch64/link.c 
>>> usr/klibc/arch/aarch64/mknod.c usr/klibc/arch/aarch64/select.c 
>>> usr/klibc/arch/aarch64/setjmp.S 
>>> usr/klibc/arch/aarch64/symlink.c 
>>> usr/klibc/arch/aarch64/syscall.S 
>>> usr/klibc/arch/aarch64/sysstub.ph 
>>> usr/klibc/arch/aarch64/vfork.S
>> 
>> This looks very fishy! No other arch bothers to do such a rework 
>> of those standard calls, what happens here?
> 
> ARM took the chance with a brand new architecture to drop a range
> of deprecated calls. As well as dropping a range of 32bit support
> (like Thumb), ARM took the opportunity of having a clean start
> without support for deprecated calls.
> 

I wouldn't call these calls "deprecated", but nevertheless, see below.

> e.g. one part of the patch is: -int _newselect,select::select(int,
> fd_set *, fd_set *, fd_set *, struct timeval *); +<!aarch64> int
> _newselect,select::select(int, fd_set *, fd_set *, fd_set *, struct
> timeval *);
> 
> Others include: dup2, lchown32, chown32, stat64, lstat64, readlink,
> symlink, rmdir, mkdir, mknod ...
> 
> There was a talk at FOSDEM 2013 which covered these changes. There
> is also documentation available from ARM, if you would like it.
> 
> http://people.linaro.org/~rikuvoipio/aarch64-talk/#/
> 
> http://people.linaro.org/~rikuvoipio/aarch64-talk/#/18/1
> 
> http://people.linaro.org/~rikuvoipio/aarch64-talk/#/18/2
> 
> Anil & I are working with Riku (the author of that paper) in
> Linaro.
> 
> (I'm using my debian.org email address because I started working
> on klibc support for Aarch64 before I started working at Linaro.)
> 
>> I do have slight sympathies for vfork, but symlink, link, mknod
>> and select!?
> 
> Yes. The system calls are already deprecated, so the new
> architecture simply doesn't implement what is already deprecated.
> 
> pre-at system calls are also removed and calls like pipe have been 
> removed in favour of only providing pipe2. etc.
> 

That is not how we handle that in klibc.

Instead put the emulation code in the specific kernel area, and put a
<?> in front of the system call (meaning optional).

The emulation code then is fenced with:

#ifndef __NR_foo

#endif /* __NR_foo */

... which means the emulation code compiles to 0 bytes on systems
which already have that.

Look at how time() is handled for a very simple example.

Also, Linux calls this architecture "arm64", please use that name.

	-hpa