[OpenAFS-devel] Refactoring the Solaris libafs code base

[Marcus Watts]

"Sean O'Malley" <omalleys@msu.edu> writes:
> From: "Sean O'Malley" <omalleys@msu.edu>
> To: <openafs-devel@openafs.org>
> In-Reply-To: <200701022320.SAA18933@quince.ifs.umich.edu>
> Message-ID: <Pine.GSO.4.33.0701031038150.22466-100000@eclipse.cl.msu.edu>
> Subject: Re: [OpenAFS-devel] Refactoring the Solaris libafs code base 
> Date: Wed, 3 Jan 2007 12:01:56 -0500 (EST)
> 
> I am know I am probably some of the cause of fixing header files, and my
> sincere apologies.
> 
> We have about 5 compiler toolsets we are using. We have GNU, Sun, IBM, M$,
> HP, SGI?, Cray? and ??. QNX, BSDi, Ultrix, Next, AT&T, Vax, SunOS (bsd),
> and ?? are all deprecated. Linux, and the BSDs (open, free, net, Apple)
> all are using the gnu toolsets.
> 
> I realize we are worried about choking the compiler by including the same
> header file twice and issues about order. The issue about including the
> same header file twice, seems like it should be taken care of at the OS
> level by wrapping it in ifdefs like we do the AFS headers. Since we
> seem to have detailed knowledge,( maybe some of this needs to get passed
> back to the specific platform developers/venders... we can't be the only
> ones that have faced this...)
> 
> The ordering issue is our issue. I assume the precompilers and headers
> have improved over the years and might actually take care of some of this
> for us. Or maybe not. =)
> 
> I am just curious as to how big of a problems rxgen is really fixing with
> our -currently- supported systems and what platforms we seem to have the
> most issues with versus how many issues it is causing (like trying to
> clean up v7 "h/style" includes.  I really don't know and I don't quite get
> the point of rxgen, as I have only braindeadedly stared at the code a
> couple of times, late at night.
> 
> I won't even try to claim novice knowledge of rxgen, kernel development,
> multi-platform development, or development in general.
> 
> If determined rxgen could be axed, the next question would simply be what
> would need to be in place in order for everything to work properly without
> it? I assume there isn't an "easy" button for this and there would have to
> be a (probably long) transition period. What would have to be done?  And
> where would we end up? *curious*
> 
> Sean
...

Who is "we" above?

While it's true openbsd & linux both use "gnu toolsets", that's way far
from making them in any meaningful way equivalent so far as resolving
header files goes.  Just for starters, the two have completely
different kernel headers, the openbsd folks never used all of the gnu
tools and have forked those that they do use, & the gnu folks have
meanwhile built in far too much knowledge of printf() and friends to be
truely healthy.

In some environments, os includes have ifdef wrappers (or equivalent
less portable mechanisms such as "#pragma once".)  In others, that's
just not true, and you're not likely to convince the developers to put
such in.  The big saving grace is that *most* of these systems are in
one way or another descended from a common set of ancestors, esp. v7,
4.2bsd, & sys5, and even the big exception, linux, is still in many
ways shaped by that.

rxgen can't be axed (at least not easily).  It's *fundamental* to afs.
It provides the language used to describe the RPC interface between all
of the various components of AFS.  You can't just take it out; nobody
wants to maintain a hand-crafted rpc description.  You could replace it
with idl or something else, but you haven't got "afs 3" compatibility
anymore.  Actually, dce idl has already been done; that's what "afs 4"
was.  There's a transarc white paper that describes rxgen, but you
might find it easier to find a good reference on onc rpc.  Any decent
network programming book should talk about it.  Rxgen is actually an
enhanced version of rpcgen.

Fixing rxgen & h/ headers is probably more tedious than anything else.
The trick would be to take most or all of the kernel header stuff out
of rxgen, and to put it into some other part of the cm source instead.
Ideally, you would want rxgen to not emit anything that says "ifdef
KERNEL" and to have it emit exactly the same headers for both userland
& kernel code, which should be the minimal set of headers necessary to
compile the resulting source.  That's an easy principle, but it's
liable to have a sort of unravelling of include dependencies in sorting
the consequences out.  That's probably why nobody's done it.

				-Marcus Watts