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

[M. Warner Losh]

In message: <200607251229.17862.jhb at freebsd.org>
            John Baldwin <jhb at freebsd.org> writes:
: > 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.

Yes.  I specifically want things to go into head first.  However, I
don't want to have to wait for a round-trip through the FSF's gcc repo
because gcc 3.4 is no longer being changed.  Making people do that is
totally unacceptable in this project.  We have never had an iron-clad
rule about requiring this for other parts of the tree.  We've tried to
keep things on the vendor branch, but we should not be slaves to our
version control system.  And in other parts of the tree we've allowed
the flexibility we need to accomplish the tasks.

We need to find some way to accomplish having local changes in the
tree that doesn't screw new imports.  It must also allow for easier
integration of new architectures because that is the direction FreeBSD
is going.  We're going to have at least two new ones this year (arm
and mips) and maybe more in the future depending on how well the
embedded stuff goes.

: > > 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, there's nothing stopping you from doing the normal
bootstrapping tests for all the other platforms.  You can test things
there.  We've already agreed that if you commit it and arm is broken
we'll sort it out and try again.  In fact, after the most recent set
of changes, arm is still not working and we're sorting out the
details.

I often apply changes to the kernel for hardware I don't have.
Sometimes I rely entirely on the submitter to do the testing.
Sometimes I do some limited tests on my local hardware to ensure it
works there still.  However, I know that in the hardware world I'll
never have all the hardware I need to totally support something.  I
have a large collection of laptops (alas, mostly old and way
obsolete), and people still have laptop issues.

: > > 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.

I'm also happy to work to make these patches conform to the gcc
style.  I have no clue what that style is, and where these patches
violate it.  I'm also cool with trying to port them to gcc's trunk in
svn.  Since that's post 4.1, I'll also have to port them to 4.1 so we
can bring them into the tree.

How does one go about getting a svn branch on the gcc svn server for
the FreeBSD distribution?  I think that would also help to facilitate
merging the changes into the main gcc sources.  It would give people a
chance to generate patches directly from the repo and get feedback
when we ask for permission to put them back into the trunk and/or 4.1
branches.

One thing we have to stop doing is requiring all changes to go through
the fsf repo first.  That process is too cumbersome to be workable.
we need to find some compromise that will allow us to commit directly
to the freebsd the patches that we require to make arm (and soon mips)
work.  A place where feedback can be generated and the patches refined
before we submit them to fsf (unless we have no one in the project to
do that, then we have to go directly to fsf).  We need to do this in a
manner that's friendly to future imports, but also preserves the
well-integrated tree that is a competitive advantage of FreeBSD.  I'm
open to being flexible in the HOW much of this happens.  I've proposed
my way of doing it, but if there's a better way, then I'll happily do
that.

The bottom line: we need to break the grid-lock we have now and I'm
tired of excuses that put the blame on our process.  This process has
resulted in a nearly year-long road-block.  It has reached a crisis
now, so we need to take a good, hard look at the processes and revise
them to make sense and work with the new realities of FreeBSD's needs.

Warner