Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Joseph S. Myers <joseph <at> codesourcery.com>
Subject: Re: [PATCH] Add finit_module syscall for Linux
Newsgroups: gmane.comp.lib.glibc.alpha
Date: Wednesday 23rd January 2013 17:59:28 UTC (over 4 years ago)
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.

-- 
Joseph S. Myers
[email protected]
 
CD: 16ms