Re: unlinkat

On Fri, Dec 23, 2011 at 11:23 AM, Indan Zupancic <[email protected]> wrote:
>
> In my opinion libc's task is to give access to all system calls.
> Linux has had *at() system calls for a while now, and in 5 years
> it will had it for ages. Please add the system call stubs.
>
> I wouldn't go glibc's way of adding emulator code in case the
> system calls are not supported by the kernel.
>
> Dietlibc is linux-only, it should at least try to support all
> (sensible) Linux system calls. And it's not worth a compile-time
> option as barely any code is added.
>
Most programs are made by people for their own use, only a small minority is of
general interest and worth of distribution (that's what I read, anyway it
makes sense). For me (and, I'm guessing, for most home-users), the advantage of
dietlibc (besides efficiency and small footprint) is the compile-and-forget
feature, that is, the immunity to general software upgradings that can go
wrong. I don't care much for the portability, I always recompile before using
in another computer, just for the small benefit of specific CFLAGS. So, either
it compiles or it doesn't. In case one just copies a program to another
computer (assuming the program was compiled with generic flags) and it crashes
or worse, that's the programmer's fault. He should make sure his program exits
when a syscall fails.

So, I also think dietlibc should support system calls that are supported by the
kernel, but might just ignore the ones the kernel does not support.

Jorge Almeida