Douglas E Engert <[EMAIL PROTECTED]> writes: > Russ Allbery wrote:
>> Right, yeah. It's a very simple function in most (possibly all) cases. > AIX was messy, but I have not looked at AIX in a few years. AIX is messy because AIX would (used to?) refuse to run a binary that contained system calls that the local system didn't understand, even if those system calls were never actually called. As a result, the KTH Kerberos code first checks to see if AFS is in the kernel, and then, if it is, loads a dynamic library that contains the actual system calls. If you don't care about the code running on a system that doesn't have AFS in the kernel, you don't have to worry about that stuff. It may also be that AIX 5 doesn't have this behavior; I've not looked at AIX 5 at all. AIX support is something that I think I'd rather leave to people who really care about AIX. My recommendation would be to bail on anything prior to AIX 5.3, since the whole LAM thing is just more trouble than it's worth. > OK, the same lib could have the setpag routine and ktc_setToken like > routine as Jeff points out as long as it does not require any extra > libs. I've now taken an extensive look at this and have started playing with code. It turns out that the library that I was thinking of already exists, and I just wasn't familiar enough with the AFS code to know about it. It's libsys.a. This contains only the system call layer and the necessary glue to talk to the kernel, without any elaborations. This is even lower level than ktc_SetToken; this is pioctl. Now, I see two ways going forward. pioctl is as low-level as you get, but it's really not particularly useful without the wrappers that AFS puts around it. It doesn't seem particularly likely to me that a lot of code outside the AFS source tree is ever going to be calling pioctl directly, nor would I want to maintain such stuff. So one route is to bail on worrying about ktc_SetToken right now, as you were trying to convince me, and just build a library that contains setpag (or, actually, lsetpag, as I have no desire to deal with the AFS/NFS translator in this context since it immediately hauls in RX and then away we go into dependency hell again). The other route is to basically provide a shared libsys, probably as libafssys, including all the stuff in libsys. That means the inode calls as well as setpag and pioctl, and possibly the debugging stuff; I haven't bothered to figure out if that's live code. I'm currently leaning towards (and implementing) the former option, but if someone wants to talk me into the latter option, let me know. I think setpag is sufficiently special that having a shared library containing only it is worth doing. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
