On Wednesday, July 19, 2006 09:56:52 AM -0400 Jim Rees <[EMAIL PROTECTED]> wrote:
I'm not arguing against making a coherent plan for setpag(). The linux kernel is moving in the direction of disallowing any added system calls, like setpag, or modified ones, like setgroups. Given this, it appears to me that we need to replace setpag with keyrings, and stop using the setpag system call.
No, you're confused. The "can't have our system call" issue was solved long ago, and if it hadn't been, then we'd be in much bigger trouble than just not having setpag().
We don't have to replace AFSCALL_SETPAG with keyrings. We have to replace storing PAG's in groups with keyrings.
I would not have a problem with seeing this code or something like it in the cvs head. It is clearly not a complete solution and I would not want it to move into 1.5 or 1.4 until we do have a coherent plan.
I don't care what you commit to the cvs head. What I care about is that you don't let a broken interface escape into the wild, where it can cause harm in the future.
Derrick and Chas have done the work of producing a working implementation. Now we need to figure out how to deploy it without breaking existing interfaces and deployed applications, and without introducing new broken interfaces.
Good software is designed; it doesn't just congeal. We are not in so much of a hurry that we can't take the time to get this right.
If we do nothing, there will be no pags in the linux client.
People have been saying that for years; it hasn't happened yet. How about less alarmism and more good engineering practice? Derrick adds:
Nothing stops us from talking about it now, either. In order to not have a flag day, we need one more piece which we can't add on our own. Given that, it doesn't matter whether we commit this code now or later, only when we choose the flag day to be.
Defeatism doesn't become you, Derrick. I prefer not to have the flag day at all. -- Jeff _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
