Prefixing system calls to eliminate namespace collisions between kernel and libc

[Julian Elischer]

On 8/28/11 5:05 AM, K. Macy wrote:
> This change was motivated by a library that I have written which is,
> in effect, a run-time environment for running the freebsd kernel
> network stack in userspace. With the exception of a small change to
> makesyscalls.sh, this change is entirely mechanical. All
> non-compatibility kernel entry points (e.g. not linux_, freebsd32_,
> freebsd6_, etc.) are prefixed with sys_ to eliminate collisions
> between system call implementations and their libc names.
>
> NetBSD long ago made this change as well. and for linux this may
> always have been the case. Linking POSIX programs against parts of the
> kernel can actually be done just by mangling things during dynamic
> linking, so doesn't require the above, but it is certainly easier and
> more portable with the above. Ultimately I would like my userspace
> network stack to be able to run on windows as well. I don't think that
> I have the same flexibility there with regards to linker scripts.
>
> My userspace stack could ease networking code development by allowing
> initial work to take place in userspace.
>
> syscalls.master is unchanged:
> 97      AUE_SOCKET      STD     { int socket(int domain, int type, \
>                                      int protocol); }
>
> Only the source function changes name:
> diff --git a/sys/kern/uipc_syscalls.c b/sys/kern/uipc_syscalls.c
> index 0e5efe6..3b83e1c 100644
> --- a/sys/kern/uipc_syscalls.c
> +++ b/sys/kern/uipc_syscalls.c
> @@ -171,7 +171,7 @@ getsock_cap(struct filedesc *fdp, int fd,
> cap_rights_t rights,
>   #endif
>
>   int
> -socket(td, uap)
> +sys_socket(td, uap)
>          struct thread *td;
>          struct socket_args /* {
>                  int     domain;
> @@ -210,7 +210,7 @@ socket(td, uap)
>
>
>
> Please see:
>
> http://pastebin.com/PpC5uThs
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>
I see no reason to not make this change.. actually I'd be happy making 
in 9.