[tschwinge/sendmmsg] Add recvmmsg and sendmmsg to the generic glibc API
Roland McGrath
roland@hack.frob.com
Fri Nov 2 19:38:00 GMT 2012
> sendmmsg is called from __libc_res_nsend which is called from
> __libc_res_nquery and res_nsend, the latter is declared in
> resolv/resolv.h, so would that fulfil the »standard-specified or
> traditional name space« and not »in GNU extension functions«
> requirements?
Yes, that's the traditional BSD name space (what you get with -D_BSD_SOURCE
but no -D_GNU_SOURCE). So it should ideally not refer to GNU extensions.
Being traditional rather than standard, it's really up to us to say when
we care, but my inclination is to care by default.
> Hmm, on the other hand, libresolv seems to use both kinds of symbol
> references:
>
> $ readelf --dyn-syms resolv/libresolv.so
>
> Symbol table '.dynsym' contains 170 entries:
> Num: Value Size Type Bind Vis Ndx Name
> 0: 00000000 0 NOTYPE LOCAL DEFAULT UND
> 1: 00000000 0 FUNC GLOBAL DEFAULT UND __ctype_toupper_loc@GLIBC_2.3 (7)
> 2: 00000000 0 FUNC GLOBAL DEFAULT UND setbuf@GLIBC_2.0 (8)
> 3: 00000000 0 FUNC GLOBAL DEFAULT UND __fcntl@GLIBC_2.0 (8)
> [...]
>
> So, which is it?
setbuf and fcntl are both in the core POSIX.1 name space (setbuf via ISO C)
and so either kind of call is fine from libresolv.
In libc code, it never hurts to use the internal names just so as not to
have to keep track of which name space your caller is in. Also note that a
single DSO can two functions in different name space categories. If say
there is a standard function and a GNU extension function, if the GNU
extension function is not called by any implementation code reached from a
standard name space function, then it doesn't matter whether it uses other
functions outside that name space. If an application using only the
standard name space redefines such other functions, then it won't ever be
able to notice that the GNU extension function it doesn't call would behave
differently.
> The rationale being that in the latter case we're violating the
> standards' name space rules anyway (with the new symbols we add as GNU
> extensions), so in this case adding an additional sendmmsg symbol doesn't
> hurt?
Yes. More precisely, we treat our nonstandard feature-test macro name
spaces (_BSD_SOURCE, _GNU_SOURCE) as if they were standards, so their
superset relationship to the standard name spaces is like that of a later
POSIX.1 version with an earlier one or with ISO C. sendmmsg is now in the
GNU name space, so the rest of the GNU name space referring to it is fine.
> After having gone through the mildly brain-twisting update of
> sysdeps/unix/sysv/linux/*sendmmsg.*, I decided to convert recvmmsg in the
> same turn. If you don't want that, I can back it out.
Let's not add any symbols we don't actually need.
> > All files using stub_warning need #include <stub-tag.h>.
>
> Have been missing from sysdeps/unix/sysv/linux/*mmsg.c. ;-)
Please send a separate fix for that. The failure mode is missing __stub_*
defines in the installed <gnu/stubs.h> file (here only when compiling with
kernel headers that don't define __NR_sendmmsg et al).
> OK. Though, that then requires some manual effort if the patch is also
> going to be published as a Git branch.
See the git-show-gnu script I posted here a while back.
Thanks,
Roland
More information about the Libc-alpha
mailing list