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]

Re: [PATCH] Fix p{readv,writev}{64} consolidation implementation


On 22 Jun 2016 11:57, Florian Weimer wrote:
> On 06/15/2016 05:41 PM, Mike Frysinger wrote:
> >> I think we should really have some sort of libtest.a, which provides 
> >> test helpers, error-checking functions such as xmalloc, and general 
> >> helpers for setting up special test environments.  I'm a bit worried 
> >> about figuring out the proper dependencies, so that libtest.a is built 
> >> before all the tests are linked.
> > 
> > isn't this what test-skeleton.c does for us now ?  and we all agree that
> > all tests should be using that.
> 
> There are limits to what we can put into test-skeleton.c due to symbol
> conflicts and dependencies of the test harness which are incompatible
> with some things which we want to test.

symbol-wise, i don't think there's a realistic problem.  we've rarely
(ever?) run into this problem, and it's trivial to sort out by using
a namespace prefix like "tst_".  which we probably want to do anyways
to keep the API more readable.

dependency wise (e.g. dl or pthread usage), i'd wait until the need
actually arises before i'd start worrying about it.

> With libtest.a, we can still have clean compilation environments for
> tests, and the linker will sort out things for us.  (We can even have
> ELF constructors which get pulled into the link as needed.)

i don't think i'd agree with that.  if our test API used tst_xxx and
random tests started interposing their own variant, that's just ugly
and a pita to digest to the point where it shouldn't really be allowed.

> > imo we should just mandate all tests use the entry point "do_test" and it
> > take argc/argv args (even if they're unused), and then all tests can pull
> > test-skeleton.c in at the top.
> 
> Yes, seems a reasonable improvement, and mostly unrelated.

they are related when you look at the implications of the two paths.
if we have a single test-skeleton.c, having a sep header for all the
prototypes is kind of pointless and just busy work.  but if there's a
lib of test files, then having a sep header is pretty much required.
if there isn't a sep header, then the include point of the skeleton
must be at the top since it's acting as the header.
-mike

Attachment: signature.asc
Description: Digital signature


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