Re: CVS commit: src/lib/libperfuse
On Wed, 29 Jun 2011, Christos Zoulas wrote:
Emmanuel Dreyfus wrote:
LIB=perfuse
-LIBDPLIBS+= puffs ${.CURDIR}/../libpuffs
+LIBDPLIBS+= puffs /usr/src/lib/libpuffs
Looks wrong.
If ${.CURDIR} doesn't do the right thing, then perhaps you want
${.PARSEDIR}.
--apb (Alan Barrett)
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On 6/28/11 7:25 AM, Jukka Ruohonen wrote: > On Tue, Jun 28, 2011 at 08:12:26AM +0200, Alistair Crooks wrote: >> 3. they are candidates for modifying to work under atf, I have yet to >> get the time to do that >> >> 4. luke kindly made some gnu autotests for them a while ago >> >> [...] >> >> and if someone was to offer to convert these tests to atf style, that >> would be great, thanks. > > Ok. > > But I think this entails a wider discussion about how the tests shipped > with third-party software could be integrated to atf(7). In case of netpgp(1) > this is easy; a relatively small code base for which both in-house tests and > /src/tests can be easily distributed. But then there are entirely different > beasts like gcc(1). One of the ideas floating around in my head is to make atf-run (well, kyua) support "foreign" tests. The most basic form of this would be programs that just return 0 on success or 1 on failure, but maybe it'd be extended to also support autotest programs, etc. Sure, their functionality would be limited within the framework (as compared to "native atf tests", but this would allow us to "mux" all the tests in one single run without much effort. -- Julio Merino / @jmmv
Re: CVS commit: src/sys/dev/wscons
> Module Name: src > Committed By: macallan > Date: Wed Jun 29 03:06:16 UTC 2011 > > Modified Files: > src/sys/dev/wscons: wsconsio.h > > Log Message: > add two new ioctl()s: > WSDISPLAYIO_GET_EDID to retrieve EDID data from display drivers > WSDISPLAYIO_SET_POLLING to control polling with VCONS_DRAW_INTR Can you please document these new exported APIs in wsdisplay(4) man page? Too many undocumented APIs in wscons(4) are really annoying. --- Izumi Tsutsui
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On Tue, Jun 28, 2011 at 06:50:50AM +, David Holland wrote: > Perhaps if atf were less intrusive...? What do you mean? I think it needs to be quite intrusive (sandboxing, etc.). Unquestionably the old /regress-style is not the way to go. Even if you dislike some parts of the API, already the consistency is a big win. On Wed, Jun 29, 2011 at 10:50:22AM +0100, Julio Merino wrote: > One of the ideas floating around in my head is to make atf-run (well, > kyua) support "foreign" tests. The most basic form of this would be > programs that just return 0 on success or 1 on failure, but maybe it'd > be extended to also support autotest programs, etc. Wasn't there already a test or two doing something like this? Fine by me, as long as we do not regress to the old /regress-style in which it is usually hard to even know what is being tested. > Sure, their functionality would be limited within the framework (as > compared to "native atf tests", but this would allow us to "mux" all the > tests in one single run without much effort. But in reality, the gcc(1) test suite is probably the only one that would really be worth considering. NetBSD does not ship that much third-party software, and the availability of tests is generally quite limited among this group. - Jukka.
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On 6/29/11 2:59 PM, Jukka Ruohonen wrote: > On Tue, Jun 28, 2011 at 06:50:50AM +, David Holland wrote: >> Perhaps if atf were less intrusive...? > > What do you mean? I think it needs to be quite intrusive (sandboxing, etc.). > Unquestionably the old /regress-style is not the way to go. Even if you > dislike some parts of the API, already the consistency is a big win. Yep, I had the same question here. I don't know what the original comment meant. > On Wed, Jun 29, 2011 at 10:50:22AM +0100, Julio Merino wrote: >> One of the ideas floating around in my head is to make atf-run (well, >> kyua) support "foreign" tests. The most basic form of this would be >> programs that just return 0 on success or 1 on failure, but maybe it'd >> be extended to also support autotest programs, etc. > > Wasn't there already a test or two doing something like this? Fine by me, > as long as we do not regress to the old /regress-style in which it is usually > hard to even know what is being tested. Some atf-ified tests do look like this, yes, and it's ugly. But if we could do this, we could lower the barrier of entry (specially for third-party projects): you could plug in a simple test program that you already have and get it to work inside atf, later refining it. Also, using "foreign" test programs does not preclude the sandboxing. The sandboxing is something that must be in place all the time IMHO regardless of how the tests are written. >> Sure, their functionality would be limited within the framework (as >> compared to "native atf tests", but this would allow us to "mux" all the >> tests in one single run without much effort. > > But in reality, the gcc(1) test suite is probably the only one that would > really be worth considering. NetBSD does not ship that much third-party > software, and the availability of tests is generally quite limited among > this group. Maybe true, but I'd personally like to see all the available tests running, even if they are not sophisticated enough. (Otherwise, why are we importing them at all?) -- Julio Merino / @jmmv
Re: CVS commit: src/crypto/external/bsd/netpgp/dist
On Wed, 29 Jun 2011, Jukka Ruohonen wrote: > On Wed, Jun 29, 2011 at 10:50:22AM +0100, Julio Merino wrote: > > One of the ideas floating around in my head is to make atf-run (well, > > kyua) support "foreign" tests. The most basic form of this would be > > programs that just return 0 on success or 1 on failure, but maybe it'd > > be extended to also support autotest programs, etc. > > Wasn't there already a test or two doing something like this? The libevent tests do work that way, using an atf-sh wrapper iain
Re: CVS commit: src/sys/uvm
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: > hi, > > > Module Name:src > > Committed By: hannken > > Date: Mon Jun 27 15:56:37 UTC 2011 > > > > Modified Files: > > src/sys/uvm: uvm_amap.c > > > > Log Message: > > amap_copy(): Keep the source amap locked until its lock has been copied. > > btw, this code seems to assume that uvm_anfree does not release the lock > even temporarily while the comment on uvm_anfree1 says the opposite. Right. Fix would be to always drop the lock in uvm_anfree() and call it in the last point. I will write a patch tomorrow. > > YAMAMOTO Takashi -- Mindaugas
