[OpenAFS-devel] Re: kabi-tracking kmods
Derrick Brashear
shadow@gmail.com
Thu, 27 Sep 2012 10:45:40 -0400
On Thu, Sep 27, 2012 at 10:26 AM, Andrew Deason <adeason@sinenomine.net> wrote:
> On Wed, 26 Sep 2012 23:00:12 +0200
> Stephan Wiesand <stephan.wiesand@desy.de> wrote:
>
>> Another option would be to make the OpenAFS FUSE client fully
>> functional.
>>
>> Any serious obstacles to that? What would it take?
>
> The major piece of missing functionality is a way to do AFS syscalls
> (including pioctls), so aklog, fs, etc can work. My suggestion is using
> a socket or something you communicate over, or some special file you
> ioctl(). I'm unsure how practical ioctls are in FUSE, but if you can do
> it you can probably reuse most of the existing syscall code. (Name the
> file /afs/.:fuse_syscall or something.)
>
> Then you have to make the userspace tools somehow be aware of that
> alternative method of making syscalls. My suggestion is to have some
> environment variable point to the FUSE mount point, and the tool would
> try to issue syscalls against that mount point. This could be the
> AFSSERVER environment variable but in some slightly different format,
> since that's what is already used for syscall redirection with the
> translator.
>
> Any other serious obstacles are just stability or speed issues, which I
> expect would get better as it was used more.
why not just use rmtsysd functionality in afsd.fuse and then there's
no extra code
at all (other than making rmtsysd call the right piece of libuafs)?
that had been my thought but i never got around to looking at it. the
clients tho would all already dtrt once AFSSERVER was set.
> --
> Andrew Deason
> adeason@sinenomine.net
>
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>
--
Derrick