++ 22/06/05 00:11 -0400 - <Tom Keiser>: Hey,
> On 6/21/05, John A. Goebel <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > 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 # ############################################ # _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
