Date: Sat, 22 Jul 2006 09:34:27 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: obrien@freebsd.org Cc: cvs-src@freebsd.org, src-committers@freebsd.org, alc@cs.rice.edu, cvs-all@freebsd.org Subject: Re: cvs commit: src/share/mk bsd.cpu.mk Message-ID: <20060722.093427.163264779.imp@bsdimp.com> In-Reply-To: <20060722002533.GA15356@dragon.NUXI.org> References: <20060721125118.GA6326@dragon.NUXI.org> <20060721.081453.1586000351.imp@bsdimp.com> <20060722002533.GA15356@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20060722002533.GA15356@dragon.NUXI.org>
"David O'Brien" <obrien@freebsd.org> writes:
: I've mentioned this to you, but I won't get into an argument what you
: [mis]understood. he-said-she-said... Getting things upstream has been
: the driving force in my strong interest in getting an ARM board or
: working simulator.
What can I do to help get things upstream? I can test things on
actual hardware. The various simulators haven't been robust enough to
run FreeBSD/arm.
: > I'd be happy to help with this process if you'd only tell
: > me what to do. Who should I send email to with the patches? What
: > paperwork needs to be filled out? What can I do to help ensure that
: > the changes are fed upstream.
:
: The same things one need to get changes into any upstream package. The
: path that we, The FreeBSD Project, has is that for toolchain things it
: needs to be upstream and then we do an import. Often this will be thru
: (and require) a toolchain upgrade. It is reasonable now, that we can get
: the ARM (and other processor support I can get HW/emulator for) into FSF
: GCC 4 and Binutils 2.17.1 and into FreeBSD thru upgrades to those
: versions.
I'm happy to make the contacts at FSF, etc to help get things
upstream. However, I have concerns about this route. I'd like a
route that can be merged into RELENG_6. Since we based our patches
and stuff is with gcc 3 in the tree, this is possible. If we were to
only bring things in via gcc4, that would be something we couldn't
merge.
There's a lot of interest in using FreeBSD/arm with RELENG_6, based on
conversations that I've had with a number of interested parties.
That's why we really want 6.2 to go out with working toolchains.
: > Finally, you ignored my proposal that we import on the vendor branch
: > the changes we have today, understanding that when gcc 4 comes you are
: > under 0 obligation to do anything with them. Since they would be on
: > the vendor branch, it wouldn't interfere with your gcc 4 work. It
: > would allow us to MFC the changes.
:
: This destroys the notion of a "vendor branch". Putting changes into a
: vendor branch that will never be part of the vendor code goes against the
: purpose of the vendor branch and what it represents.
It is an abuse of the vendor branch. Given the weaknesses of CVS, I
think this is the least bad solution. We do this as a means to an
end, not because CVS is good for this task. We accept the risks that
we lose changes on an import, and are willing to absolve the importer
of preserving these changes.
The alternatives are:
(1) provide out of tree patches.
(2) Provide in-tree patches, applied by hand
(3) in tree patches applied automatically
(4) provide the changes in cvs
#1 doesn't work. There are too many people with too many trees. I've
witnessed several people wasting entire days trying to get these
patches working. It is a huge hassle for a growing number of people.
I'd wager that the number of people that this hits has already
exceeded our entire ia64 install base.
#2 is just like #1. Getting the patch isn't the issue.
#3 or #4 could both be used. I dislike #3 because it duplicates what
CVS does. However, as a practical point, if people can do:
setenv TARGET arm
make buildworld
it doesn't matter much how it is done. It seemed to me that the path
I outlined would be the least work. Patches are unlikely to apply
after the upgrade, which would, I'd think, get in the way of the
upgrade.
: I've been working on a forming a response to your proposal that would be
: able to appease both of us. I am open to a phone call from you, but only
: after you've calmed down and can discuss things agreeably. If you recall
: I tried to setup a meeting with you at USENIX ATC. And I've tried to
: catch you on IRC several times.
When's a good time for us to talk? I've calmed down from being upset
over the 'arm kernel folks doing nothing' remark, and think we can
work something out.
: > : I'd like to ask when we'll get ARM resources in the FreeBSD.org cluster
: > : so committers can have access to ARM - I don't. So it is hard to test
: > : anything. Until a month ago no one would agree on a reference platform
: > : so toolchain work could be tested vs. spending all my time trying to get
: > : something working that no one else had. I am still waiting to get the
: > : ARM board I purchased in my hands and working.
: >
: > We've tested these patches. They work. Why must you be so insistant
: > on a proceedure that makes it so hard to get things done.
:
: As I wrote to you before, I will not commit anything to GCC/Binutils/GDB
: that I have not (and cannot) test myself. Would you accept a large patch
: from me and commit it to the FreeBSD kernel without you being able to
: build and test it? I dare say you wouldn't.
I think this is the crux of my frustration with you. I have and would
commit changes to the kernel that I've not personally tested. I've
done this when people send me support for hardware I don't have for
drivers that I've maintained. What I do in those cases is that I
review the code, providing feedback for the submitter. Once those
issues are sorted out, I commit it to the tree. I then monitor the
lists for reports of problems (since I can't test all hardware). I
ask the original submitter to test the patches and make sure that
nothing broke or was botched in the integration. I make adjustments
as necessary.
In this case, you are able to build a world for arm on i386 or amd64
(and maybe others, I've only done it on those two box). You can
review the patches and suggest where things are done wrong. You can
commit them to the tree and then ask the folks that have the hardware
to test. If you get bugs from users, then you can point those users
at the submitter of the patches.
I'll be the first to admit that this is a little messier than having
all the hardware to do the testing. But as FreeBSD grows, it isn't
always possible to have all the hardware.
: > There will be times that the cluster doesn't have the resources needed,
: > and you'll have to take it on faith that another architecture works.
:
: Then The FreeBSD Project should take up a discussion of what it means for
: an architecture or platform to officially be part of what the project
: produces with this constraint. The "Support for Multiple Architectures"
: document that was a consensus of the committer community. You can claim
: it is out of date, but then the committer community should have a chance
: to discuss this issue as a whole.
I think that we've already moved on beyond that document, and need to
update it for the new thinking on how platforms are included.
: > : Alan I'm curious, for you what is the rush?
: >
: > 6.2. I've told you this before. We want to make a big splash with the
: > emebedded arm stuff, and I really want to get things in before then.
: >
: > I'm extremely frustrated on this and this current situation is intolerable.
:
: I feel the same. You're going against how we've supported new
: architectures in the past, and being unreasonable.
And I've tried to point out that this new architecture is different
than older ones.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060722.093427.163264779.imp>