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

[Matthew Emmerton]

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

Understood, and I have to admit, I'm not as well versed in the kernel
internals as I should be.  The primary motivation of the sysname collapsing
that I did in my patch was to avoid duplicate autoconf glue and
configuration files for 4.[3456], brought on by the neccessity get it
compiled on 4.5.  I have no objection to having multiple sysnames defined,
but it would be nice if we didn't have to add duplicate (identical)
configuration files to make things compile.  Since Derrick has hinted that
much of the contents of the config files will be automatically detected (a
la autoconf or some similar mechanism) in the future, I can live with
duplicates now.

Since there is support for 4.[345] already in CVS, my patches for sysname
collapsing can be dropped.

However, included in that batch of patches is one patch (patch-aa) which is
still neccessary, as it #ifdef's out the implementation of the strcasecmp()
function, which is already present in FreeBSD.

--
Matt Emmerton