This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add finit_module syscall for Linux

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]