On Wednesday, January 11, 2006 04:00:47 PM -0800 Russ Allbery
<[EMAIL PROTECTED]> wrote:
Jeffrey Hutzelman <[EMAIL PROTECTED]> writes:
Russ Allbery <[EMAIL PROTECTED]> wrote:
Certainly such a library would be useful. If someone wants to
implement it without all of the dependencies that Heimdal libkafs has,
I'd be all in favor of it. Heimdal's libkafs has significant
dependencies and isn't really suitable for use outside of a system
built with Heimdal in general.
That's true for the full libkafs, but not for the functions I mentioned.
Ah, hm, I see what you're saying. So basically, the API provided would be
only the k_* functions, namely:
k_hasafs
k_pioctl
k_unlog
k_setpag
k_afs_cell_of_file
the two AFSCALL defines, the VIOC* defines, and struct ViceIoctl?
Actually, I'm not sure why k_afs_cell_of_file is interesting; I thought
that was just a pioctl. But it could be thrown in for good measure.
The AFSCALL defines are actually completely uninteresting to users of that
API, since it doesn't provide any way to call arbitrary AFS syscalls. As
for the VIOC defines, we should do something, but I'm not too thrilled with
the idea of OpenAFS containing two independently-maintained lists of those.
I suppose I don't get to complain about that until I start distributing an
authoritative header to go with the tables at grand.central.org/numbers.
I was talking about interfaces, not implementations. I don't have any
problem with a library which implements the setpag() API without rmtsys
support. But a library which exports only lsetpag() is not all the
useful.
I was trying for something minimally intrusive, which was ruling out
changing the name of the function (since otherwise I couldn't just reuse
the same code).
echo 'int setpag(void) { return lsetpag(); }' | gcc -x c -c - -o setpag.o
:-)
(what's sad is that on my amd64_linux26 machine, that produces a 1344-byte
file, of which 16 bytes are actually code. Talk about bloat!
If we do something like the above, I wonder if it
wouldn't possibly be better to copy the required code into a new source
directory. I'm not sure how best to do this cleanly.
Well, we more or less need a separate directory for each library we build;
that's just how the build system is. So essentially what you need is to
build src/sys/afssyscalls.c in more than one place. That's not too hard;
we do it in several places already. It would presumably need some bashing
to be able to provide both sets of interfaces. I'm wary of implementing
lpioctl in terms of k_pioctl or vice versa, because that sounds like it's
asking for symbol conflicts if someone uses libsys and libkafs (ours or the
real one) in the same binary.
On the other hand, it's rather a pain to deal with from a distribution
perspective, since you run into conflicts between the two libraries and
have to be careful about SONAMEs, library versioning, etc. This can be
dealt with (both Heimdal and MIT provide a libkrb5, for instance), but
it's ugly.
True. Like I said, I'm not sure it's the right approach, but it might be.
Some distribution pain might be worth people being able to build AFS-aware
apps that can be built against either heimdal or openafs without requiring
the other to be present...
-- Jeff
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
