Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Oct 2012 09:42:29 -0700
From:      Garrett Cooper <yanegomi@gmail.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, "Simon J. Gerraty" <sjg@juniper.net>, freebsd-arch@freebsd.org
Subject:   Re: Fwd: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
Message-ID:  <CAGH67wQffjVHqFw_eN=mfeg-Ac2Z6XBT5Hv72ev0kjjx7YH7SA@mail.gmail.com>
In-Reply-To: <201210021037.27762.jhb@freebsd.org>
References:  <CAGH67wRkOmy7rWLkxXnT2155PuSQpwOMyu7dTAKeO1WW2dju7g@mail.gmail.com> <201210020750.23358.jhb@freebsd.org> <CAGH67wTM1VDrpu7rS=VE1G_kVEOHhS4-OCy5FX_6eDGmiNTA8A@mail.gmail.com> <201210021037.27762.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 2, 2012 at 7:37 AM, John Baldwin <jhb@freebsd.org> wrote:
> On Tuesday, October 02, 2012 10:29:49 am Garrett Cooper wrote:
>> On Tue, Oct 2, 2012 at 4:50 AM, John Baldwin <jhb@freebsd.org> wrote:
>>
>> ...
>>
>> > This sounds like a superior approach.  It doesn't break any current use
>> > cases while giving the ability to build multiple programs in the few
>> > places that need it.  It sounds like there are a few places under gnu/
>> > from Garrett's reply that might be able to make use of this as well.
>>
>> For the record, gnu/cc/cc_tools/Makefile is where I first spotted a
>> potential "bsd.progs.mk" candidate. Most of the other code doesn't
>> care given how things are organized in our source tree.
>>
>> > BTW, one general comment.  There seem to be two completely independent
>> > groups of folks working on ATF (e.g. there have been two different
>> > imports of ATF into the tree in two different locations IIRC, and now
>> > we have two different sets of patches to our system makefiles).
>> >
>> > Are these two groups talking to each other at all?  I know in May that
>> > many folks (certainly multiple vendors) are interested in ATF, and it
>> > seems that both Juniper and Isilon have ported ATF internally.  It seems
>> > that it might be good for the two groups to work together to avoid
>> > stomping on each other's toes.  It seems there are some differences in
>> > the two approaches that merit working out to avoid a lot of wasted
>> > effort on both sides.
>>
>> Both parties (Isilon/Juniper) are converging on the ATF porting work
>> that Giorgos/myself have done after talking at the FreeBSD Foundation
>> meet-n-greet. I have contributed all of the patches that I have other
>> to marcel for feedback.
>
> This is very non-obvious to the public at large (e.g. there was no public
> response to one group's inquiry about the second ATF import for example).
> Also, given that you had no idea that sgf@ and obrien@ were working on
> importing NetBSD's bmake as a prerequisite for ATF, it seems that whatever
> discussions were held were not very detailed at best.  I think it would be
> good to have the various folks working on ATF to at least summarize the
> current state of things and sketch out some sort of plan or roadmap for future
> work in a public forum (such as atf@, though a summary mail would be quite
> appropriate for arch@).

I'm in part to blame for this. There was some discussion -- but not at
length; unfortunately no one from Juniper was present at the meet and
greet; the information I got was second hand; I didn't follow up to
figure out the exact details / clarify what I had in mind with the
appropriate parties.

That being said, I *sort* of understand what's going on now, although
I'm still guessing as I haven't received any FreeBSD internal
(developers@, etc) emails and all the discussion I have so far is
between gnn@, marcel@, gibbs@, mlaier@, and mdf@.

For all intents and purposes I've been paused for a few weeks because
of other things, so no harm, no foul, but I'd like to know what all is
being contributed back from Juniper in terms of tests, ATF integration
into the build system (which I've given back to marcel@/gnn@, but
haven't received feedback for yet -- probably because they're busy),
etc so I can better avoid duplicated effort and help the cause of
creating a maintainable/testable FreeBSD. As far as what Isilon is
contributing back, I wouldn't look any further than my perforce repo;
the original goal as of last BSDCan was to contribute back `isi_check`
(custom wrapper around GNU libcheck), and maybe some of our tests are
written for isi_check: the problem with that plan is that it depends
on GNU [lib]check -- yet another test infrastructure -- diverges us
more unnecessarily from NetBSD (and there are several things we want
to grab from NetBSD and contribute back instead of forging ahead down
our own path), the tests would need to be audited and cleaned up to
use generic macros and check for generic functionality, etc. Also, it
would help to have generic system tests similar to LTP's breadth in
the tree (so that way we can avoid breakage before things are
committed to current). There are some functional gaps that I like to
fill in with ATF that GNU libcheck does well [with fixtures] and there
are some inconsistencies between the ATF C and C++ bindings I'm
working on enhancing

More details about what I planned on doing can be found here:
http://wiki.freebsd.org/TestingFreeBSD -- although it deserves
updating when looking at the structure and dealing with the "patches"
(I need to update it to "just work" with the latest current).

Thanks!
-Garrett



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wQffjVHqFw_eN=mfeg-Ac2Z6XBT5Hv72ev0kjjx7YH7SA>