Re: Feature request: building musl in a portable way

[ardi <ardillasdelmonte@gmail.com>]

On Fri, Dec 22, 2017 at 5:43 PM, Rich Felker <dalias@libc.org> wrote:
> [...] You can change the syscall layer just by
> making a new arch that defines (in syscall_arch.h and bits/syscall.h)
> your mechanism. See the recent wasm thread or midipix for examples of
> more exotic ways this can be done.

Thanks a lot!! I'll try to follow this path. It looks clean.


> But be aware that the ability to
> get a POSIX-conforming implementation where EINTR and thread
> cancellation work requires some sort of atomic boundary that
> determines when a syscall has passed the point of having successful
> side effects, which makes implementing the syscalls just as functions
> hard.

I'm not sure if I can hit this scenario but I'll research this. Thanks!


> Stepping back a bit, I suspect what you want is to just be able to
> implement functions like open(), read(), etc. on your own instead of
> implement something like actual syscalls, based on a notion that
> open(), read(), etc. "are the syscalls".

Not based on that notion, but thinking that the number of functions
issuing syscalls would be reduced, and substituting such functions
would be less work than translating syscalls. But the approach you
suggested above is better.


> [...]
> As long as you do it the way that acknowledges the above, the "heavy
> editing" is isolated to the arch directories you add.

That's really what I want!


> [...]
> There are indeed a small number of places where workarounds or other
> considerations for Linux-specific parts of the syscall interface
> boundary are in general source files rather than in the syscall glue
> layer, but I think the number is quite small. If there are
> particularly egregious ones that you think could be improved upon,
> please let me know.

Yes, I believe that whenever there are assembly source files in some
directory in the musl tree, there're functions there that make
syscalls without going through the interface you defined above. I'll
look at this and I'll see if it can be improved somehow.

Thanks a lot!

ardi