Greg KH wrote:
On Wed, Feb 09, 2011 at 05:15:21PM +0100, Ludwig Nussel wrote:
Jeff Mahoney wrote:
The issue as I see it is that we have no way to communicate to the user that the driver they're using is of dubious quality. In an ideal world, we could take the bug reports and fix the upstream driver. In reality, most of us don't have the time to tackle improving a driver for hardware we don't have.
Maybe the model of trying to put everything into a single giant repo needs to be reconsidered upstream already.
Um, really? The benifits of keeping the drivers/staging/ tree _in_ the main kernel tree are huge. There is no known advantage of keeping it out, and in fact, that's one of the main reasons I started doing this work.
Well, no doubt having a central place for hosting and a shepherd is beneficial. The question is whether all of this needs to be in one git repo/tarball. Comparing apples and oranges the kernel could be viewed like openSUSE Factory with a single .spec file that builds everything. It would be quite hard to maintain leaf packages that way, especially for novices.
What do you feel would benifit by keeping this separate?
You mean who? Me when trying to get a fix for a lirc driver out to the users that don't tumble on weed for example :-) Previously I could just cherry pick fixes from lirc cvs myself, put them into the lirc package and request an update. Now the drivers are in the kernel and I certainly don't want to get involved maintaining patches there.
How would the work flow happen? How would other distros and users be able to sync up properly?
Just like it works with distributions or bigger user space projects that consist of several components. How do GNOME or KDE manage to create working (*cough*) releases? :-)
A user space driver load/bind interceptor would be nice indeed.
What do you mean by this?
Some program that could e.g. ask for confirmation before a module that was never loaded before gets loaded or ask whether a loaded module is allowed to bind to a device not seen before. Like a polkit dialog saying "loading NULL deref prone exoticsocketfamily.ko requires admin authentication". The same mechnism could then be used to require confirmation if staging drivers are requested. Admins could easily train an installation and then lock it down so users can't use arbitrary usb devices. I'm thinking of the recent issue where a mobile phone could pretend to be a keyboard and launch programs when plugged in. On a locked system only a specific usb port would be allowed to have a keyboard connected. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org