Hi all,
Here's a summary of the state of the drivers/staging/ tree, basically
what will be coming in the 2.6.33 merge, and what the status of the
different drivers are so far.
Sorry it's late (after the merge), but hey, better late than never.
Again, drivers/staging/ is NOT a dumping ground for dead code. If no
one steps up to maintain and work to get the code merged into the main
portion of the kernel, the drivers will be removed.
Also, drivers can now be merged from mainling into the staging
directory, providing a path out of the kernel for some obsolete and/or
broken drivers.
So, here's some drivers that will be removed in the 2.6.33 kernel:
- android drivers. Google and no one else stepped up to maintain
them, so they will be dropped. So sad...
- dst. The developer isn't working on this anymore and recommended
that it be removed as no one is using it.
Here is some new drivers that will show up in .33:
- arlan, netwave, strip, wavelan - wireless drivers that are on
their way out of the kernel. If anyone is actually using this old,
obsolete hardware, speak up soon, otherwise they will be removed in
a few kernel releases.
- ramzswap - a compressed ram driver
- rtl8192u - yet another wireless driver
- samsung-laptop - laptop for the N128 Samsung laptop
- batman-adv - a network protocol
- dt3155 - a frame grabber driver
- sm7xx - another frame buffer driver
Here's the list of drivers that have had work done on them that will
show up in the .33 release:
- comedi - lots of development effort happened here, mostly all
cleanups, but there are some logic changes. More is needed, and
it's moving along nicely.
- line6 - lots of work happening, very nice to see
- rt* - loads of cleanups and other merges. Will be obsolete soon due
to a "real" wireless driver being worked on, but it's still nice to
have these be a working alternative until then.
- rtl* - more wireless driver work, horrible code, but it seems to
work for the users. Hopefully more development time can be spent
here in the new year.
- dream - here's the platform specific code for the Android G1
platform. This might be the way the android code sneaks back into
the kernel, as there is developers trying to get this to work. Of
course, it's all happening without Google's help. {sigh}
- et131x - loads of cleanups, more left to do. Good solid progress
happening here.
- iio - a new driver added to this subsystem, along with other fixes
and cleanups. Looking nice.
- poch - still some work happening, nice to see it pick back up.
- panel - minor cleanups.
- vme - cleanups and minor tweaks, still alive and kicking
- vt66* - more wireless drivers, will be obsoleted by a "real" driver
again.
- wlags49 - more cleanup work as well.
Here's some drivers not listed so far, that have had work done recently,
after the 2.6.33-rc1 merge happened, so it has to wait for the .34
kernel release:
- wlan-ng
- slicoss
- mimo
- asus_oled
- udlfb
- w35und
Hm, so, what's up with all of the other staging drivers, and why have
they not had any development? What is the status of them? They are now
on the short list to be deleted in 2 kernel releases, unless some _real_
development happens on them.
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.
- frontier - slated for removal in .35. Will be easy for someone to
pick up if they want to (hint, hint, hint)
- altpciechdma - this will be removed in .34 unless someone steps up.
- b3dfg - this will be removed in .34 unless someone steps up.
- pohmelfs - filesystem under development out of tree, would be nice
to get the patches merged back into here
- quatech_usb2 and serqt_usb2 - usb to serial drivers that need to get
merged into mainline.
- rar and sep - Intel needs to step up here and get this code cleaned
up properly, or it too will be removed.
Again, if someone is looking for some kernel development work to do,
picking any of the above drivers up to get them merged into mainline,
would be a great thing to do.
And, on a final, and sadder note, I'd like to announce the failure of
the driver project to complete a driver for a company that requested it.
This was totally my fault, and I would publically like to apologize
about my lack of getting a SCSI driver written in time for a company
that had asked for it. So, while the Linux driver project is doing
great work for a large number of companies, every once in a while we do
fail, we are only human.
thanks,
greg k-h
* Greg KH | 2009-12-22 16:54:47 [-0800]:
>Here's a summary of the state of the drivers/staging/ tree, basically
>what will be coming in the 2.6.33 merge, and what the status of the
>different drivers are so far.
I can't find usbip in your summary. Is there nothing to say or did you
just forgot about it?
>thanks,
>
>greg k-h
Sebastian
On Wed, Dec 23, 2009 at 11:53:15AM +0100, Sebastian Andrzej Siewior wrote:
> * Greg KH | 2009-12-22 16:54:47 [-0800]:
>
> >Here's a summary of the state of the drivers/staging/ tree, basically
> >what will be coming in the 2.6.33 merge, and what the status of the
> >different drivers are so far.
>
> I can't find usbip in your summary. Is there nothing to say or did you
> just forgot about it?
Oops, I forgot about it. It's slated to be removed in .35 as well,
because no one is working on it.
thanks,
greg k-h
Quoting Greg KH ([email protected]):
...
> 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.
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?
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?
-serge
On Mon, Jan 04, 2010 at 12:57:55AM -0600, Serge E. Hallyn wrote:
> Quoting Greg KH ([email protected]):
> ...
> > 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.
Ok, send them on to me when you feel they are good enough.
thanks,
greg k-h
On Sun, Jan 3, 2010 at 10:57 PM, Serge E. Hallyn <[email protected]> wrote:
> Quoting Greg KH ([email protected]):
> ...
>> 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 [email protected] and [email protected] 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.
Quoting Ashwin Ganti ([email protected]):
> On Sun, Jan 3, 2010 at 10:57 PM, Serge E. Hallyn <[email protected]> wrote:
> > Quoting Greg KH ([email protected]):
> > ...
> >> 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?
Well, to have a login daemon be unprivileged, it needs some way to
set groups without CAP_SETGID. I was playing with some toy frontend
and backend (i.e. login and factotum) code and this seemed a nice
simple way to do it.
> Please also cc [email protected] and [email protected] as well when you
> send out these patches for review.
Will do, thanks.
> > 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.
Ok, I'll do that when I get a chance, do some more testing, and send
out in the next two weeks.
thanks,
-serge