Staging tree status for the .33 kernel merge

Ashwin Ganti ashwin.ganti at gmail.com
Mon Jan 4 17:16:26 UTC 2010


On Sun, Jan 3, 2010 at 10:57 PM, Serge E. Hallyn <serge at hallyn.com> wrote:
> Quoting Greg KH (greg at kroah.com):
> ...
>> This means, unless someone steps up and starts doing real work (not
>> trivial spelling fixes) on the following drivers, they will be removed
>> in the future kernel releases.
>>
>>  - arlan, netwave, strip, wavelan - wireless drivers mentioned above
>>    that are on the way out.  Slated for removal in 2.6.35
>>  - hv - Microsoft Hyper V drivers.  The developers again seem to have
>>    disappeared, this is getting old. Slated for removal in 2.6.35
>>  - p9auth - this will be removed in .34 unless someone steps up.
>
> I think I've decided to try to push it.  I'm working with some patches
> at git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux-cr.git
> (branch p9auth.jan3.4 is latest).  I'll send patches as I feel they
> are ready - so far they pass testcases, but are too new for me to
> feel I should push them today.

Thanks Serge!

It is useful to continue to have this driver in the tree as there a
few other people as well who have shown interest in using this. I have
been recently contacted by guys at Glendix (http://www.glendix.org/)
who have started looking at using this driver.

>
> Ashwin, I'm curious whether you'd think the last patch
> (http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/sergeh/linux-cr.git;a=commitdiff;h=1662ba777140a39c21a9b647459d2deab8ffe1ca)
> would be a problem with any userspace - but I assume there is no
> legacy userspace to really worry about?

There is no legacy user space support yet for Linux. This should be
fine in that sense.
I still need to look at the patches in detail though but what is the
motivation for this change?
Please also cc rsc at swtch.com and ericvh at gmail.com as well when you
send out these patches for review.

>
> Apart from plenty more cleanups, another more fundamental issue to
> address is how to stop unused caphash entries from piling up in
> memory.  Put a timeout on them?  Let privileged userspace list and
> occasionally delete them?  Associate a target task with each entry,
> where either the task or its decendent can use the capability, but
> if the task dies we free the caphash entry?

So, there are a couple of options here (I favor the second approach):
1. We can add a timer to expire the capabilities.
2. Add a creation time stamp to every capability. Whenever a
capability is used (i.e. written to /dev/caphash) we can go through
the list in the kernel and reap the ones whose time stamp has expired.
We can optimize the data structure later to make this faster.

Ashwin.



More information about the devel mailing list