Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: David Miller <davem <at> davemloft.net>
Subject: Re: [PATCH] Add finit_module syscall for Linux
Newsgroups: gmane.comp.lib.glibc.alpha
Date: Wednesday 23rd January 2013 18:33:36 UTC (over 4 years ago)
From: "Joseph S. Myers" 
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.
 
CD: 8ms