Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Mike Frysinger <vapier <at> gentoo.org>
Subject: Re: [PATCH] Add finit_module syscall for Linux
Newsgroups: gmane.comp.lib.glibc.alpha
Date: Wednesday 23rd January 2013 17:54:09 UTC (over 4 years ago)
On Wednesday 23 January 2013 11:43:45 Joseph S. Myers wrote:
> On Tue, 22 Jan 2013, Kees Cook wrote:
> > Yeah, seems true. Weird. The callers (e.g. kmod) use their own externs.
> > Hmpf
> > 
> > $ readelf -s /lib/x86_64-linux-gnu/libc.so.6  | grep init_module
> >    894: 00000000000f77d0    36 FUNC    GLOBAL DEFAULT   12
> > [email protected]@GLIBC_2.2.5
> > 
> > But it is exported. Is this something to fix, or should finit_module
> > follow this lead?
> 
> 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).

what if we just included all these syscall wrappers in libc_nonshared.a ?  
that way we minimize the baggage ...
-mike
 
CD: 19ms