Message-ID: <f2b55d220702221721x71b23acfsba925cd5d0532561@mail.gmail.com>
Date:	Thu, 22 Feb 2007 17:21:09 -0800
From:	"Michael K. Edwards" <medwards.linux@...il.com>
To:	Alan <alan@...rguk.ukuu.org.uk>
Cc:	"D. Hazelton" <dhazelton@...er.net>,
	"David Lang" <david.lang@...italinsight.com>, davids@...master.com,
	"v j" <vj.linux@...il.com>, trent.waddington@...il.com,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	"Neil Brown" <neilb@...e.de>
Subject: Re: GPL vs non-GPL device drivers

On 2/22/07, Alan <alan@...rguk.ukuu.org.uk> wrote:
> > Oh yeah?  For IRIX in 1991?  Or for that matter, for Linux/ARM EABI
> > today?  Tell me, how many of what sort of users do you support
>
> Solaris (NTL - very large ISP/Telco), Dec server 5000 (for fun), Irix (and
> linux cross for Irix removal), MIPS embedded (including the port to Linux
> of Algorithmics toolchain) for Sonix then 3COM routers.

My list of GNUs maintained is about the same:  SunOS 4.x, Solaris 2.x,
IRIX, ConvexOS, embedded MIPS and ARM and x86.  I've used, but didn't
maintain, GCC for embedded PowerPC and m68k, and until I found a
distro I could more or less trust to be point fixable, I did my own
desktop/server Linux toolchains for x86, PowerPC, and x86_64.  The
only one for which I resorted to coughing up the university's money to
the FSF was IRIX, and that's because it had to reach functional parity
with the Sun and Convex boxes pronto.

> It's not a hard problem. gcc 2.x wasn't too hot on MIPS but it worked
> although the Irix compiler generated vastly better code (and AFAIK still
> does).

It worked until you tried a 64-bit target or stressed the floating
point.  I had one of the first R4400s that ever left SGI, in an Indigo
with the IndigoVideo board when it was still in alpha.  Part of the
horse-trade between the university and the start-up I worked for was
that they got to run batch jobs on the thing when I wasn't physically
at the keyboard.  I had built several experimental toolchains for the
thing but concluded rapidly that I didn't want to tech-support that
shit.  Best $5K of someone else's money I ever spent.

> There are folks who maintain cross devel chains for just about every
> Linux platform specifically for testing and while it isn't a small job
> they do seem to be coping quite happily.

Er, I'm one of them.  :-)  When the ARM-based device I'm currently
working on first ships as an out-of-form-factor prototype to OEM
customers, it will be accompanied by a complete toolchain, kernel, and
userland, built from scratch using crosstool and ptxdist and extensive
patches I wrote, all of them to be contributed upstream because I
convinced my client that it's the right thing to do.  This includes
the latest upstream editions of each userland component, a gdbserver
that has been tested on multi-threaded soft-float NPTL binaries, the
first (public) ltrace to work correctly on Linux/ARM in at least three
years, the first (public) strace to understand ALSA ioctls, and
infrastructure for unit testing and system latency analysis.

It will be delivered as a set of git repositories with the complete
development history and tracking branches for outside projects, and
the only bits that aren't open source will be those encumbered by
inescapable trade secret agreements with chip vendors.  With the
exception of those closed binaries, everything from soup to nuts is
exactly reproducible from source on any Linux distro with a moderately
current native toolchain and autotools.  Before the first unit ships
retail, these git repositories will be carefully scrubbed of
encumbered material and opened to the public.  Pull one git repository
and run one script, and a few hours later you have your own JFFS2
image that you can burn to flash using facilities we will leave in
U-Boot for end-users' benefit.

Absolutely everything in the system can be point-fixed and recompiled
by the end user, with results as predictable and reproducible as I
know how to make them for myself.  Updates from third-party upstreams
can be merged using the tools that I believe to be best-in-class for
the purpose and use myself, daily.  No binary ever ships without
passing through an autobuild and unit test framework that I provide as
part of the end user source code release.  That's my personal standard
of release quality.  Now tell me, how does that compare to your
employer's?

> > CodeSourcery and MontaVista and Red Hat stay in business?  Not with
> > the quality of their code or their customer service, I'll tell you
> > that -- although Mark Mitchell is probably the best release manager
>
> Lots of people would disagree with you about that (and independant
> surveys would back the disagreement), like they would disagree with you
> about most things.

I have never particularly feared being in the minority, as long as I'm
right.  :-)  But seriously, if you haven't heard the complaints about
unreproducibility of Red Hat toolchains going back to the "GCC 2.96"
debacle, you haven't been listening -- and MontaVista became notorious
in the industry for deliberately mucking with kernel APIs as a vendor
lock-in tactic.  (They appear to have reformed substantially since the
2.4.x days.)  I don't know Mark personally but he appears to be as
open about CodeSourcery's processes and priorities as any toolchain
vendor has ever been, and GCC 4.1.2 looks like it's going to be as
stable as any upstream GCC release has ever been and perform decently
as well, so I don't have much to complain about in that department.
YMMV.

> I was hoping you'd take the pseudo-legal noise elsewhere.

You crack me up, Alan, you really do.  But in any case I have probably
responded as often to this thread (which I did not start and to which
I have perhaps contributed one message in ten) as is of use to anyone.
 HTH, HAND.

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists