[OpenAFS-port-freebsd] Patches for FreeBSD 4.x
Chaskiel M Grundman
cg2v@andrew.cmu.edu
Tue, 11 Jun 2002 21:06:43 -0400
--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...