[OpenAFS-devel] OpenAFS Development

[Derrick J Brashear]

On Thu, 24 Jun 2004, Jack Neely wrote:

> Before I start please refrain from all "they hate us" and "that's just a
> bitch to fix" replies.  I'm tired of it and it stifles development.  Would
> you want to work on something that you just got told is "just a bitch?"

Given that you admit that, then you should be able to understand why in
response to preceived lack of cooperation in moving to a model where
sys_call_table doesn't need to be hooked for PAGs, why nothing has been
done? (*)

> In return I do offer my services as limited as they are.

Suggestions are inline.

> with the 2.6.6-1.435.  Arla CVS built, installed, and worked right out
> of the box.  PAGs.  I had PAGs.  In fact, Arla will try to hook into the
> LSM first, and failing that, hooks the syscall table.  For our
> convenience, I have attached the code that finds sys_call_table.

The hostility engendered toward OpenAFS on the basis of having this
suggests it's worth letting this hack die. Perhaps if we demonstrate our
willingness to move forward there will be some actual cooperation to help
us move forward.

> there needs to be something in the stock kernel that can generically
> handle some sort of authentication key per process.  Recently, there was
> a very productive conversation on LKML about a "key-ring" patch between
> David Howells and Kyle Moffett.  A link to it was posted here after the
> first few messages, but now a rather complex and generic system has been
> laid out.  I assumed the OpenAFS folks would be very interested in this
> and give some feedback, but there's been silence.  I've spoken with Kyle

I don't make a habit of repeating myself. I said on linux-kernel what we
were trying to replace; Nothing has changed.

Right now, I can have processes with multiple uids in a single PAG, and
processes with a single uid in different disjoint PAGs. I use that
functionality. So do others. Kyle's earlier statements led to my belief
that he didn't mean to do that. So, in my mind it was a proposal to
implement something other than PAGs. Whatever. But later discussion seemed
more likely to be useful.

If something useful happens, we'll use it. If nothing useful happens,
well, we can't use it. Attempting to be involved (myself, and I can only
really speak for me on that basis) produced nothing useful, so I'll wait
and let people who aren't necessarily perceived as having baggage do it;
It's not sour grapes, I want to use this functionality...

I'd take a simple and generic system: process labels.

Comments about caching removed. If you want to push there, testing along
the lines of showing where optimization is needed (rather than simply
that is it) would be useful.

> Finally, NPTL.  We are starting to look at deploying OpenAFS servers to
> replace Transarc code.  What's involved in looking at the NPTL issues in
> OpenAFS?  These need to be fixed, not worked around.  The workaround
> will probably go away soon.  One of my next tasks is to look into this
> more closely.

I'm not aware of anyone who knows yet. What would make it easier would be
if gdb had something like Solaris dbx's "thread -blockedby", but failing
that the suggestion I made the other day (when it hangs, use gdb's
generate-core-file and then get backtraces from all threads) would seem to
be a start. Alternately, knowing how to reproduce beyond "let it run for a
while".

> In conclusion, I'm very blown away by Arla.  OpenAFS has always worked a
> little better for us as a client but now the tables are turned.  Both
> projects are Open Source, would a look at some of this code help us?

It might for using Linux Security Module, and frankly the only reason I
never did that was the impression I got was it wouldn't be being shipped
enabled by vendors. If that's untrue, well, I'd be on that.

-D
* actually it's untrue, we tried anyway, but unless some piece of data
tied to a process is copied over forks, we're sort of screwed, and there's
nothing we can "borrow" or "use" which we'd not either break some other
meaning of, or not work the way we want.