On Sun, 20 May 2001 [EMAIL PROTECTED] wrote: > > I assume so.. However then we have a coordination issue to make > > sure that we don't re-use the same RPC numbers as IBM/Transarc. > > We have a similar problem with pioctl numbers. I've been working on setting up what I hope will become a generally recognized canonical list of AFS protocol constants, including things like Rx service numbers, RPC numbers, and so on. So far, I've compiled only a few of the many lists required; I've been holding off on the rest until I know whether the major implementors (OpenAFS, Arla, IBM) are willing to support this sort of coordination. Properly, pioctls are an implementation detail and not part of the AFS protocol. However, the UNIX implementors do seem to be interested in maintaining some level of compatibility for those operations which they have in common. > two easy solutions: > 1. put it on a different port. or > 2. make it a different service. call it "lk", for instance. I'll avoid commenting on this issue in detaul, except to say that NFS's "locking" is separate because it was hacked onto the side of an existing protocol, not because that is a desirable design. It's worth nothing that NFS handles locking very poorly. Applications which have critical dependencies on locking generally warn users not to put their data in NFS, because of the poor locking semantics. It is unlikely that we can do any better in AFS with a similar kludge. Even with a well-integrated locking protocol, the amount of work and overhead involved in getting it right is significant. DFS comes close, but IIRC DFS tokens have some notable denial-of-service vulnerabilities. > As for pioctls -- > 1 just reserve a half-dozen up front, or > 2 skip ahead a few thousand or > 3 use a magic number in the arguments so the pioctl code can tell that it's an > OpenAFS call instead of an IBMAFS call. It's quite difficult indeed to skip ahead "a few thousand" in a namespace whose size is only 255. If you look at the registry page on central.org, you'll notice that I have proposed reserving a portion of the space for implementation-specific operations. I've done the same in the _ioctl_ space, even though that space is rather less crowded at the moment. In any event, I think ioctl's are irrelevant here -- byte-range locking in AFS would presumably be accomplished using the same UNIX locking syscalls as are used for files in other filesystems. Otherwise, why bother? -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Carnegie Mellon University - Pittsburgh, PA _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
