The Linux System Call Interface

Software & Operating Systems Linux
,
1

Hi guys,

I am currently working on an alternative to the C standard library and therefore glibc - I don't want to go too much into details here, since they don't belong to my question.

Since a C library of that type requires a layer which maps the system calls provided by the kernel through its system call interface (SCI) and that SCI can vary from architecture to architecture, it is important to understand how the SCI for a specific architecture looks like.

I am going to develop stuff only for 64-bit Linux systems. Therefore the only thing I need to care about is the 64-bit version of the Linux SCI.

Here comes my question: Although most calls seem to work for AMD64 as well as ARM64, I've seen that sys_stat seems to use different implementations of struct stat per architecture. Is there a standard type which would mean that my library is immediately portable to other 64-bit architectures or do I need to implement the entire thing architecture dependent and build a platform independent API on top of those APIs?

In case of sys_stat, I am currently using: http://lxr.free-electrons.com/source/arch/x86/include/uapi/asm/stat.h#L82 on AMD64 and it works like a charm.

I also found this file and tried that struct but that does not work: http://lxr.free-electrons.com/source/include/uapi/asm-generic/stat.h

For ARM64 (which I want to port my library to in the future) I found this file: http://lxr.free-electrons.com/source/arch/arm64/include/asm/stat.h

Now I am quite a bit confused and worried about portability. I don't want my library to end up like glibc where everything is full of #ifdefs and #ifndefs for all that porting stuff. That is horrible code to read. Any advice?
(and no: "just use glibc" is not an advice - glibc is monolithic beast of horribly structured code)

I know that there are other implementations of the standard library but since I just fucking hate the standard library, I'll build a completely new one. My library will also work with the standard library but doesn't depend on it. So you can use it together with the standard library if you just want to have some functions of it.

Also note, I am working on kernel version 4.5
The SCIs of older versions might vary, too.

2

In case this is still relevant:
There aren't just different versions of the struct stat, there are corresponding versions of the sys_stat syscall as well.

3

I already know that but thanks anyway.

I've played around with the interface, also on my Raspberry Pi, and to me it seems like every architecture has its own interface. Some parts are actually the same on multiple architectures like struct poll, but since there is no real architecture independent interface, I just create architecture specific interfaces and create mapping functions that transform that stuff into architecture independent structures. Those functions are then internally called by an architecture independent API. Users of my APIs can then decide if they want to use the faster platform dependent API (eg if they know their software is only going to run on AMD64) or use the platform independent API which is a bit slower but makes the code directly portable to multiple 64-bit architectures.