From: Martin Pitt <martin.pitt@ubuntu.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: [PATCH] Testbeds for libudev/gudev clients
Date: Mon, 09 Jul 2012 20:09:04 +0000 [thread overview]
Message-ID: <20120709200904.GB3221@piware.de> (raw)
In-Reply-To: <20120706050131.GC3109@piware.de>
Hello Lucas,
Lucas De Marchi [2012-07-09 16:54 -0300]:
> You might want to look into kmod's testsuite. We do exactly that and
> until there's a better alternative I plan to support this for newer
> glibcs.
Thanks for pointing out! I'll do that. When it fails with a newer
glibc, we should get test case failures and thus it should be rather
obvious where things need fixing.
I guess that still means we'd either need a libudev-test.so or a shell
wrapper and the libpath.so thing around all tests, and thus
build/ship the two as part of a libudev install. That's something
which I considered to be more ugly, but if Kay prefers that, I'll look
into this.
> When I implemented that I tried what you are trying now and it didn't
> look right and it's ugly to touch all the calls with path strings and
> also very error prone.
libudev already has something like that, it has the TEST_PREFIX macro
everywhere. So I don't think it's actually getting much worse, but
with a preloaded library we wouldn't need the TEST_PREFIX thing any
more either.
So the trade is "add the get_prefix() calls to the path name build
calls" vs. "maintain/build/install a preload library".
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
next prev parent reply other threads:[~2012-07-09 20:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-06 5:01 [PATCH] Testbeds for libudev/gudev clients Martin Pitt
2012-07-09 7:25 ` Martin Pitt
2012-07-09 13:50 ` Kay Sievers
2012-07-09 14:22 ` Martin Pitt
2012-07-09 19:54 ` Lucas De Marchi
2012-07-09 20:09 ` Martin Pitt [this message]
2012-07-09 20:21 ` Lucas De Marchi
2012-07-10 3:40 ` Martin Pitt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120709200904.GB3221@piware.de \
--to=martin.pitt@ubuntu.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).