[OpenAFS-devel] Refactoring the Solaris libafs code base

[Derrick J Brashear]

On Mon, 25 Dec 2006, Dale Ghent wrote:

>
> I'm kind of looking for some guidance in this email as well as to proffer 
> some changes in a few realms, including OS rev. support cut-off, conversion 
> to vn_alloc(), and a en masse cleaning up of  src/afs/SOLARIS code.
>
> 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.

counterpropose we do these changes for 1.5.x, and simply make it such that 
people who want older run 1.4

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

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

Yay
>   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'd argue one header

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

Userspace cache manager. There's no need to break it, either. It shouldn't 
interfere with anything you're doing.

> 3) Actually improving the Solaris AFS client driver. Between the Solaris 
> Internals 2nd edition book and several choice blogs.sun.com posts, and 
> reviewing fs code from src.opensolaris.org, it seems we can stand some 
> updates. DNLC isn't being used (we do call dnlc_enter() and dnlc_remove() but 
> with junk, and lookups are not done). The prescribed way of creating and 
> killing vnodes isn't being done (vn_alloc). I also want to reduce dependancy 
> or remove direct accesses to any private kernel functions or structs.

That would be excellent.


> 4) Source patches - What do the GKs prefer to deal with - one huge one or 
> lots of small ones?

If they're functionally separate changes, one change per diff. Otherwise, 
one large one is fine.