This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add finit_module syscall for Linux
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.