[OpenAFS-port-freebsd] Patches for FreeBSD 4.x

[Chaskiel M Grundman]

--On Monday, June 03, 2002 20:19:51 -0400 Matthew Emmerton 
<matt@gsicomp.on.ca> wrote:

>
> mv src/config/param.i386_fbsd_42.h src/config/param.i386_fbsd_4.h
> mv src/config/param.i386_fbsd_42_usr.h src/config/param.i386_fbsd_4_usr.h
> mv src/config/Makefile.i386_fbsd_42.in src/config/Makefile.i386_fbsd_4.in

An afs sysname is a unique identifier that represents two different things: 
One is a combination of hardware architecture and operating system on which 
a particular set of AFS binaries are supported , the other is to for @sys 
paths in afs, where it is used to select files based on the client system 
architecture. It may make "sense"  for all the freebsd's to be lumped 
together for the second purpose, but for the first purpose, it can only be 
done if *binary* kernel modules (as well as other programs) are both 
forward and backward compatible across all freebsd 4.x systems. And, as in 
<http://www.central.org/numbers/systypes.html>, only the first purpose 
matters as far as what sysnames afs implimentation. The official sysname 
identifies a set of afs binaries, and nothing else. Anything that's done 
with the information beyond that is convention


Here's an example of a change that occured between 4.3 and 4.4 that could 
potentially cause a kernel module to misbehave if run on the wrong version:

<http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/file.h.diff?r1=1.22.2.5&
r2=1.22.2.6&only_with_tag=RELENG_4>

In this patch, the offset and size of fp->f_flag in a struct file changed, 
so any filesystem module that used information from that structure member 
would get the wrong data if it was compiled on freebsd <4.4 and run on 
freebsd >= 4.4.

Here's one from 4.4->4.5

<http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/mount.h.diff?r1=1.89.2.4
&r2=1.89.2.5&sortby=date&only_with_tag=RELENG_4>

That actually moves data around in a struct mount, which I know openafs 
uses.

So, my reccomendation to the gatekeepers (and I have an unfair advantage) 
is that any freebsd sysname-collapsing patch should not be accepted. 1.2.6, 
when it comes out, will have the patches I did several months ago to enable 
4.3, 4.4, and 4.5 support (they've been in cvs for some time, but did not 
get pulled up for 1.2.4, and 1.2.5 was rushed) . I will try and get some 
4.6 patches in before then...