[OpenAFS-devel] fs sysname assignment problem

[John A. Goebel]

++ 22/06/05 00:11 -0400 - <Tom Keiser>:

Hey,

> On 6/21/05, John A. Goebel <jgoebel@slac.stanford.edu> wrote:
> > 
> > (insert head scratching wonder)
> > 
> > The AFS version is 1.3.84 built on an Opteron running
> > kernel-smp-devel-2.6.9-5.EL and glibc-2.3.4-2, so is a 64-bit build. My 32-bit
> > architecture builds work fine.
> > 
> > Any clues on what's going on?
> > 
> 
> Yeah.  The way we abstract knowledge of datamodel differences between
> userspace and kernelspace in the pioctl and syscall layers needs to be
> tweaked a little bit.  I've been working on a patch to fix this for
> other reasons.
> 
> Right now, most of the datamodel handling is done through
> platform-specific ifdefs in afs_call.c and afs_pioctl.c.  Although
> that works ok for most things, it starts getting a bit annoying as
> certain syscalls and pioctls are complicated enough that they need to
> be aware of the datamodel differences.  The end result is we need to
> have a lot of preprocessor logic spread about in several difference
> places.  My first thought was to roll out two new macros that get
> defined in each of the config/param.*.h files, e.g. for sun4x_510:
> 
> #if defined(KERNEL)
> #if defined(__sparcv9)
> #define afs_osi_get_kdatamodel() 64
> #define afs_osi_get_udatamodel() ((get_udatamodel() ==
> DATAMODEL_ILP32) ? 32 : 64)
> #else /* __sparcv9 */
> #define afs_osi_get_kdatamodel() 32
> #define afs_osi_get_udatamodel() 32
> #endif /* __sparcv9 */
> #endif /* KERNEL */
> 
> Does this seem like an ok solution to the problem?  Or, does somebody
> have a better way?
 
Tom, I hear an unfortunately deafening silence on this issue.

So another bit of information: I build 1.2.13 (after apply a patch 
<https://lists.openafs.org/pipermail/openafs-info/2004-September/014951.html>
for a 2.4 kernel (RHEL3) with the same results. I'm not able to get
multiple sysnames and there is not sysname (@sys) expansion.

Has anyone have a Opteron system running RHEL that _can_ make this work? Any
suggested magic?

Thanks,
John
 
> Regards,
> 
> -- 
> Tom Keiser
> tkeiser@gmail.com
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
> 

##############################################
# John Goebel <jgoebel(at)slac.stanford.edu> #
# Stanford Linear Accelerator Center         #
# 2575 Sand Hill Road, Menlo Park, CA 94025  #
############################################ #