[OpenAFS-devel] openafs libuafs for QT File apis

Michael Meffie mmeffie@sinenomine.net
Tue, 5 Jan 2016 18:24:08 -0500


> On Tue, 29 Dec 2015, Troy Benjegerdes wrote:
> 
> > So I got this crazy idea that I wanted to make
> > QT apps on android & ios that could access AFS.
> >
> > Attached is a patch which seems to 'sort of' work
> > in a few cases, but mostly not. The fact that
> > it does actually work in a few cases seems to
> > make it worth the effort to fix the rest.
> >
> >
> > Any thoughts?
> >
> > Also what issues does anyone see with linking
> > libuafs with the GPL QT libraries.. I know we
> > had a lot of friction with the linux community,
> > but this is sort of the other way around.
> 
> I have no particular thoughts about UAFS or GPL compatibility.  UAFS is
> far enough along that I haven't been able to convince myself to advocate
> for removing it entirely, but I don't know what its current known flaws or
> weaknesses are or how far from fully baked it is.  I am not spending my
> time on it other than to keep it limping along during overall structural
> changes, since there are (to me) more important fish to fry.

UAFS has been useful for non-authenticated fuse clients.  I've been using
it for quite a long time.   Several ideas have been mentioned on how
to support authenticated access, but I'm not aware of any patches.

Also, the libafscp is quite nice and could be useful in providing
access to /afs from within an app.

> > And where are we with working open code for
> > ipv6? I think half of the "don't work" cases
> > above are related to the goofy IPv4 network
> > topology I have my AFS servers on.
> 
> Extremely far.
> There are two changes in gerrit, http://gerrit.openafs.org/#/c/11861/ is
> the tip, but that does not even begin to scratch the surface of the work
> that needs to be done.
> 
> To the best of my knowledge, no one is publicly working on IPv6 support,
> or has even declared an intent to start working on it.  Even if someone
> was working on it, I wouldn't expect it to be done for another 2 years,
> starting from the current state of affairs.
> 
> It sounds all doom and gloom because it is -- if no one is actually doing
> the work, it's just not going to get done.  If someone is interested in
> doing the work, we can start outlining a direction of progress for
> reasonable incremental chunks of work and having design discussions, but
> there seems no point in talking about it with no plans for actually doing
> it.

Ben is correct; much needs to be done.  The gerrits he refers to are part of a
proposed conversion from storing addresses in raw 32-bit integers to standard
sockaddrs. This is prerequisite work needed before IPv6 support can be
done.

Some progress in getting a stack of changes ready for gerrit was made recently.
I've been pushing changes to my public github account[1] for anyone with the
time or inclination to review or provide feedback.  The first batch of changes
identifies all the various incarnations of int that are used to represent IPv4
addresses throughout the code base, as well as distinguishing fileserver
"numbers" from network addresses, followed by the start of changes to convert
the code base to sockaddr.

[1]: https://github.com/meffie/openafs


-- 
Michael Meffie <mmeffie@sinenomine.net>