[OpenAFS] Removing the ability to change the PAG of the parent

[Mike Coyne]

Maybe something as simple as adding a build option to the openafs =
configure --with-libkopenafs-only compile and link only the objs that =
you need something like what goes into libsys.a currently, that way it =
would stay in sync with the distribution.=20

In thinking of a problem I am currently working on, I have been having =
problems getting header files from SGI for a older Altix running SuSe, =
So I can't build openafs for it. It does have a old copy of Hidemal on =
it and a libkafs.a , if I link against that and finaly get 1.4.11 up and =
running will that create a incompatibility with the "new in 1.4.11"  =
linux PAG handeling? If so is there a version of libkopenafs that can be =
build with 1.4.11 , if not maybe use Russ Allbery's  compatibility =
package in kstart?=20

Mike Coyne

-----Original Message-----
From: Derrick Brashear [mailto:shadow@gmail.com]=20
Sent: Friday, February 19, 2010 6:15 PM
To: Mike Coyne
Cc: Russ Allbery; openafs Info
Subject: Re: [OpenAFS] Removing the ability to change the PAG of the =
parent

[openafs-info-admin@ removed from CC list; is one of you using Lotus =
Notes?=3D

On Fri, Feb 19, 2010 at 4:08 PM, Mike Coyne <Mike.Coyne@paccar.com> =
wrote:
> What also may be nice if if libkopenafs along with the wrappers can be =
ma=3De
> to compile stand alone so it could be more easly be =A0linked and =
distrib=3Dted
> to possibly systems with out afs installed,=A0 similary to the =
libkafs.a =3Dn
> your kstart package but with out the requirement for afs to be =
pre-instal=3Ded
> for some non-linux systems ?

That's possibly doable; You'd not be able to get pts lookups and so
you'd not have Tokens for AFS id (number) but instead just Tokens, but
that's not reliable anyway.