Message-ID: <20081124131415.GA21403@linux-mips.org>
Date:	Mon, 24 Nov 2008 13:14:15 +0000
From:	Ralf Baechle <ralf@...ux-mips.org>
To:	Chad Reese <kreese@...iumnetworks.com>
Cc:	"Kevin D. Kissell" <kevink@...alogos.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org
Subject: Re: Is there no way to shared code with Linux and other OSes?

On Sat, Nov 22, 2008 at 11:08:05AM -0800, Chad Reese wrote:

> 	linux-mips@...ux-mips.org
> Subject: Re: Is there no way to shared code with Linux and other OSes?
> Content-Type: text/plain; charset=ISO-8859-1

Adding linux-kernel since this is probably of more general interest than
just the linux-mips list.

> I appreciate the info about the typedefs, but I didn't really mean to
> signal them out. They just happened to be an example I picked.

Thus it received a specific answer.

> The
> fundamental issue is that we have a large number of files written using
> a fairly common corporate coding standard (4 space indents, no tabs,
> javadoc comments) that is used by a number of OSes. We generate our API
> documentation from it using doxygen, so the comments at least attempt to
> have useful info in them. In order to use this code in the kernel, we're
> having to basically run it through the evil indent program and strip
> quite a bit of stuff out. Obviously indent will make a mess of some
> stuff, so lots of hand editing is needed. The end result is code that
> has diverged from the original in such a way that diffs are basically
> impossible.
> 
> We're already having issues with bugs between the different versions and
> the kernel submit stuff has just started. Maybe the only solution is two
> divergent code bases, but it just feels like the gun is pointed at my
> foot and cocked. I really don't want to pull the trigger knowing what is
> about to happen.
> 
> Obviously I don't target these comments at true Linux drivers. The CF
> libata driver is obviously a Linux specific driver and should follow all
> Linux standards. Code for bootloader communication and networks setup is
> completely OS agnostic, so sharing it between systems makes sense.

I'll start off my answer with a bit of history.  A few years ago the Linux
codebase was growing at exponentional speed not last from contributions
from other projects and there were few standards in the Linux world.  As
the result the code base was highly inconsistent in many aspects,
including coding style and typedefs.  It made maintenance and even just
understanding the code base painful.  Then on a few occasions Linus
decreed certain standards such as code to be formatted to fit into 80
colums.  Other standards arose from a common understanding.

The primary purpose of all these standards, both written in the kernel
documentation and unwritten is to improve maintainability of the code and
as such there is little point in blind enforcing them even though the
noise generated by automated checkers such as checkpatch.pl encourages
that.  So take that with a grain of salt.

Re divergent code base - I see your issue but the problem is both ways.
Historic example is Broadcom which contributed the headers for the Sibyte
SOC family.  The headers are generated using inhouse tools just as yours
and we'd like to change them - but all those changes conflict with
Broadcom's bi-annual contribution which are bascially are versions
re-generated with their latest tools and from their latest RTL.

OS compatibility layers are another subject.  They simplify maintenance
for the one and make it harder for the other.  In general in the Linux
world we've made not so positive experience with such glue code layers,
so we tend to limit if not avoid their use.

Another factor is that usually long after the contributing company has
already forgotten about their code I'm the guy who still is stuck with it.
For many more years ...

  Ralf
--
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