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.
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel
