[OpenAFS-devel] Refactoring the Solaris libafs code base

[Marcus Watts]

Dale Ghent <daleg@umbc.edu> writes:
...
> 1) Proposal to cut off support for revisions less than Solaris 2.6.
> 
> To be honest, my own opinion is that even 2.6 is too old to care  
> about and Solaris 7 is such a stepchild that the cut-off should be  
> 8... even as far as Sun is concerned, 2.6's supportability has  
> expired and you can get help for it only if you have a specialized  
> support contract.
> 
> But since 2.6 brought us a full palette of 64bit typedefs and  
> associated goodness, and thus the VFS/VNODE interfaces are (by and  
> large) the same between 2.6 and 8, supporting 2.6 should be of no  
> undue burden. That said there's very little compelling reason to  
> still keep code specific to Solaris 2.5.1 and lower around. Raise  
> your hand if you have a 2.5.1 or lower server where you always  
> absoltively, posolutely need the latest afs client on it. Anyone? Ok,  
> I thought so.

Ok by me.  You might want to ask info-afs@ as well.

> 
> Anyway, this proposal dovetails with:
> 
> 2) Clean up src/afs/SOLARIS code.
> 
> Old-style function definitions. Improper typedefs for lots of things,  
> tons of missing declarations, header file includes are never clear,  
> and other niggling items. I'd really like to clean this up, at least  
> for the sake of readability and actually being able to see compiler  
> warnings which matter rather than having to pick through the many  
> "normally" emitted. This raises some questions:
> 
>     2a) There seems to be a largely abandoned osi_prototypes.h file.  
> Should all functions introduced in the osi_*.c files go in that one  
> header file, or should those functions be declared in a companion  
> header files (eg: osi_groups.h, osi_vfsops.h, etc.)

I have some more generic mostly userland cleanups for some stuff,
and I know a lot of stuff was already cleaned up in cvs-head.
I don't know if what I have is orthogonal to what you
propose or if it overlaps.  At the moment, my changes are all
part of rxk5.  I got more keen on removing "normal" warnings
as I started touching stuff that was generating those warnings.

> 
>     2b) src/afs/sysincludes.h uber alles? Or src/afs/UKERNEL/ 
> sysincludes.h ? What's the deal with UKERNEL anyway??

UKERNEL means "userland kernel".  The Java code, & I think
some of the administrative code uses this.  It looks nifty,
but the project at work I was going to use as an excuse to
actually find out what this did hasn't happened yet.

What this means, though, is that some code is built many
different times being targetted at up to 5 distinct runtime
environments:
	userland - lwp - nopic (static link)
	kernel - lkm
	userland - pthread - pic (shared object)
	userland - pthread - nopic (static link)
	ukernel - pthread - pic (shared object)
This is most obvious in some of the lower-level shared code,
like RX, where you'll see that as 3 different sets of include
files: kernel, userland, ukernel.  The more recent libraries
tend to be very "application specific", thus some things get
built many more than the 5 times you might expected.

> 
>     2c) #ifdef FOO, or #if defined(FOO) - is there a general  
> preference for one or the other format?

I've used #if FOO in some cases.  But that's bad; either sun or gcc
emits lots of warnings about the undeined symbol (which from K&R to
the present resolves as "false").  Don't do this.

'#ifdef FOO' is shorter and easier to type/read.  It's preferable
in any case where there's no likelyhood it will get more complicated.

"#if defined(FOO)" can be easily turned into "#if defined(FOO) || defined(BAR)"
or "#if defined(FOO) && defined(BAR)".  

You probably won't need "if defined(FOO)" for OS-specific files,
since "ifdef <some-version>" implies "if defined(<some-version>)
|| defined(<some-version+1> ... defined(<latest-version>).
You might need
#if defined(<some-version>) && !defined(<some-newer-version>)
to get a feature that was later withdrawn.

...

			-Marcus Watts