cvs commit: src/share/mk bsd.cpu.mk

[John Baldwin]

On Monday 24 July 2006 23:41, David O'Brien wrote:
> On Mon, Jul 24, 2006 at 01:39:59PM -0400, John Baldwin wrote:
> > On Friday 21 July 2006 20:25, David O'Brien wrote:
> > > On Fri, Jul 21, 2006 at 08:14:53AM -0600, M. Warner Losh wrote:
> > > > : 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.
> > 
> > Erm, I think this argument is actually not valid.  Committers commit
> > patches submitted by other people or patches they haven't directly
> > tested all the time.
> 
> You're scaring me there John.  I hope you at least build a kernel and see
> things still boot.

I do build, but booting isn't always relevant.  If someone has a bug in smbfs
and they've confirmed it worked for them, but I have no smb servers around,
what good does it do to boot it?  I can't get anywhere close to executing that
code path.  I just did this with the locking fixes for smbfs_unmount() and
netsmb last week for example.
 
> One thing I'm not sure people realize is that part of what is being asked
> is to commit a patch to RELENG_4.  Our rules are that it should first go
> in to HEAD, then possibly thru RELENG_6.  The rules are the same for the
> GCC, Binutils, and GDB trees.

Warner wants to get it into HEAD first and then MFC it to RELENG_6, I don't
see what's so odd about that.

> > I do this a lot when fixing problems for people where I come up with a 
> > patch and ask them to test it, and if they say it works ok I commit it.  I 
> > don't try to reproduce every single bug people report to locally test 
> > patches.  For many of them I simply don't have the necessary hardware and/or 
> > environment!
> 
> This isn't an issue of if some patch fixes an obscure problem, but this
> is basic functionality.

Errm, adding support for arm isn't basic functionality, it can only affect
arm users, of which there are none (because there's no toolchain yet).  You
can't possibly make arm support any worse than it is right now (i.e.
nonexistent).

> > In addition, in this case, you aren't getting a patch from some random PR 
> > submitter you don't know from Adam.  You are getting the patches from Warner, 
> > cognet@, etc. who you _know_ and should have enough of an established 
> > relationship now to at least be able to guage their technical competence.  
> 
> The GCC patch as-is would be rejected, nor does it cleanly apply to the
> GCC HEAD branch.  So all I could do is work up an equivalent patch for GCC
> head, see that I can still build GCC,  but not produce a working binary.
> Then back port the HEAD patch to GCC stable branches.
> 
> Sorry that is just more working in the dark than I want to do.
> 
> I'll I've every asked is that I could test (i.e., run) an ARM kernel and
> ARM userland binary.

You know, you can also ask other people to test the compiler you build.  That's
what I did for the smbfs/netsmb patch I referenced earlier.  In that case I
came up with a patch and let the user handle building the kernel, but you can
also build a gcc binary and ship it off to one of the arm folks for testing.

This is not an intractable problem, but I think it would be useful to not try
to have do it entirely on your own.

-- 
John Baldwin