Michael Banck <[EMAIL PROTECTED]> writes: > There is no kernel AFS support in the Hurd yet (though this issue might > have stirred up some interest to write a translator for it), so the > syscalls in afssys.c fail. > > I am not sure what should be done in the generic case (I saw there is > some code for various other operating systems), but I think it makes no > sense to call these syscalls without kernel support? There was quite a > discussion whether a bogus ioctl should be added to glibc on the Hurd > for this issue, but this got (rightfully, IMHO) discarded by the > maintainers.
I agree that the ioctl should not be added to the glibc just for this, that why we define the cpp symbols ourself in kafs.h/afssys.c. In other unixes _IOW creates something standalone, apprently Hurd is born diffrently. In case of hurd we can use something other then _IOW and things will work jus fine, the resulting numbers from _IOW are used in pioctl calls and can overlap with ioctl numbers. So defineing _VICEIOCTL to #define _VICEIOCTL(v) ((unsigned int ) (0x56000000 | v) #define VIOC_SYSCALL ((unsigned int ) (0x43000000 | 1) for Hurd should work just fine. #define _(v) ((unsigned int ) (0x56000000 | v) > Probably the whole kafs directory should not need to be compiled if AFS > is not found (could configure check for that somehow, perhaps?), and the > code in the other parts be conditionalized appropriately. Just because the build machine doesn't have AFS support doesn't mean the binary should support it. AFS can be added later. Love
pgpMN4TWMVPex.pgp
Description: PGP signature
