This is the mail archive of the libc-alpha@sourceware.org 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] |
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 > > init_module@@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
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |