Re: FreeBSD port (60): system calls

[Roland McGrath <roland at redhat dot com>]

> I don't agree. A libc should provide access to all system calls,
> whether they are useful to many programs or to just one. 

I didn't say anything to contradict that.  By "implicit" I mean things that
are not declared anyhere or clearly defined as intentionally being part of
the ABI.

> The version definitions will come in the last patch of the series. 

Please don't do that.  Either just send it now or include the Versions
patches for each bit of code along with the code.  I examine each feature
on its own, and I need to consider the related exports at the same time I
see the code.

> The exported nonstandard syscalls are all prefixed with __ in there.

Are those __ names what's used on BSD?  We do not want the user API or ABI
to include __ names unless it's unavoidable.  If these are just extensions,
then just give them new nonstandard names.

> The difference between the existing sysdeps/unix/i386/fork.S and the
> freebsd/i386/fork.S is that the latter defines the function under the
> primary name __libc_fork. This is needed for linuxthreads (which
> overrides __fork).

Please include a patch for sysdeps/unix/i386/fork.S instead of the new file.

> About vfork.S: I don't understand sysdeps/unix/i386/vfork.S; if you
> want to replace it with freebsd/i386/vfork.S, I see no problem.

That is certainly just some old cruft, not what I thought was there.  Would
you mind including your replacement file as a patch against that along with
a new patch that fixes the other issues?

Of course I really just want you to do the edits instead of me because I am
lazy, but I will rationalize by claiming that I would like to have you test
a freebsd build with these changes in their final form before they go in.

> The vfork functions must be implemented in different code, so as not
> to use the stack. The alpha/vfork.S is therefore wrong; I withdraw it.

What you just sent was identical.

> And rfork should not be unified with fork, because one has a __libc_
> primary name, and the other one doesn't.

Defining these extra names never hurts.  They are reserved for exactly that
use should it be required in the future, and there is no actual effect on
the shared object since they don't go into a Versions file unless we need them.

> OK, I'm applying your last week's change also to this new sysdep.S. I
> would have noticed during rebuilding later...

One should always rebuild against current glibc cvs sources and fix any
problems immediately before sending patches.

> Doesn't work: we cannot reuse the Linux SYSCALL_ERROR_HANDLER for
> FreeBSD, because after syscall return, on Linux %eax contains the
> negated errno value, whereas on BSD %eax contains the positive errno
> value.

Oops, oh well.

> > In alpha/sysdep.h the INLINE_SYSCALL redefinition should not be necessary,
> > that should be the generic definition you get from sysdeps/unix/sysdep.h.
> 
> The generic definition is overridden by the one in
> sysdeps/unix/alpha/sysdep.h, which uses __NR_ prefix for syscall
> numbers. Whereas BSD uses the prefix SYS_. So removing the
> INLINE_SYSCALL redefinition will cause a compilation failure.

Oh, that is bogus.  That stuff belongs in the linux/alpha file.
I moved it.

> Here's the updated patch. Not taking into account any file moves that
> you might want to do.

Please do the file moves, verify the build really works for you (at least
on i386 if alpha is not handy), and send a new patch that gets it to the
state that built successfully.