The question here is not about ioctl, but about using the same data structure as used in proc_afs_syscall
Thanks Geza > The GPL module won't help you as it's the kernel and not the userland. > Doing ioctls on a proc file isn't really proprietary; You don't need > to link our code. > > Derrick > > > On Oct 6, 2008, at 15:25, Gémes Géza <[EMAIL PROTECTED]> wrote: > >> Volker Lendecke írta: >>> On Sun, Oct 05, 2008 at 10:41:06PM +0200, Gémes Géza wrote: >>> >>>> I've built up a patch (attachment 3658 to bug 5799 on samba bugzilla) >>>> which makes fake-kaserver and vfs-afsacl work again. >>>> But the patched configure makes smbd, net and maybe other binaries >>>> link >>>> with libsys.a in order to communicate with the openafs kernel code. >>>> The >>>> question is what are the legal consequences, are the binaries >>>> distributable et all? >>>> >>> >>> At the time I wrote the fake kaserver stuff I had the same >>> concerns and thus did a fresh implementation of the ticket >>> generation and syscall wrappers. Can't you do the same with >>> the proc_afs_syscall thing? This can't be much code. >>> >>> Volker >>> >> Unfortunately this time it seems to be a lot harder, the main change >> being at least to my understanding, the fact that the openafs kernel >> module doesn't advertise its services as a system call, and thus we >> cannot link with just libc code which calls into the kernel, but need to >> explicitly use openafs calls for the same propose resulting in a need to >> link to their code. >> Hope is not lost totally yet as I've read about some work of developing >> a GPL licensed kernel module, and then we could use some glue code from >> there. >> >> Geza >> _______________________________________________ >> OpenAFS-info mailing list >> [email protected] >> https://lists.openafs.org/mailman/listinfo/openafs-info _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
