From owner-cvs-src@FreeBSD.ORG Sat Jul 22 15:36:02 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8720316A4DF; Sat, 22 Jul 2006 15:36:02 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E98BA43D8F; Sat, 22 Jul 2006 15:35:46 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6MFYBf3002149; Sat, 22 Jul 2006 09:34:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 22 Jul 2006 09:34:27 -0600 (MDT) Message-Id: <20060722.093427.163264779.imp@bsdimp.com> To: obrien@freebsd.org From: "M. Warner Losh" 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> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 22 Jul 2006 09:34:11 -0600 (MDT) 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2006 15:36:02 -0000 In message: <20060722002533.GA15356@dragon.NUXI.org> "David O'Brien" 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