Re: [PATCH] Add finit_module syscall for Linux

[David Miller <davem at davemloft dot net>]

From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Wed, 23 Jan 2013 17:59:28 +0000

> On Wed, 23 Jan 2013, Mike Frysinger wrote:
> 
>> > The kexec_load discussion suggested that the init_module export should be
>> > considered a historical bad decision; because it was exported from shared
>> > libc long ago, it can't now be removed, but that doesn't mean its example
>> > should be followed for any new related syscalls, if the "syscall" function
>> > is sufficient to use them from user code and they are extremely
>> > specialized.
>> 
>> we can stop exporting it so new apps stop linking against it (but continue to 
>> provide the versioned symbol for old apps).  if we think including the module 
>> funcs is a historical mistake, then let's make that more explicit by breaking 
>> code that tries to link against it.
>> 
>> that said, i think it is useful to have a centralized location for syscall 
>> wrappers.  everyone having to implement their own init_module() { syscall() } 
>> wrapper means packages can easily introduce their own subtle bug (in terms of 
>> the # of parameters the func takes).
> 
> I don't think the kexec_load discussion completely settled the issue.  
> Perhaps someone would like to list what architecture-independent syscalls 
> in current kernels do not have glibc wrappers, excluding syscalls that are 
> clearly obsolete and only for backwards compatibility and should never be 
> used by new programs?  Then we can see how big the issue is.

FWIW my vote is for GLIBC to provide a bonafide interface, as well as a header
declaration, for these syscalls.

We get into trouble, like the double definitions of "struct in6_addr"
et al.  in netinet/in.h vs. the kernel header, exactly because glibc's
support for kernel provided interfaces is sometimes out of sync or
missing completely.