Messages in this thread | | | Subject | Re: Driver Model | From | Robert Love <> | Date | Tue, 02 Sep 2003 15:13:50 -0400 |
| |
On Tue, 2003-09-02 at 14:43, James Clark wrote:
> 1. Will the move to a more uniform driver model in 2.6 increase the chances of > a given binary driver working with a 2.6+ kernel.
I don't see how.
> 2. Will the new model reduce the use/need for kernel modules.
No. The two concepts are really unrelated.
> 3. Will the practice of deliberately breaking some binary only 'tainted' > modules prevent take up of Linux. Isn't this taking things too far?
Tainted modules are not "broken" -- they just display a "tainted" message. We do not do things to deliberately break binary-only modules.
The driver model has four main benefits, in my eyes:
- unifies code between the previous desperate driver models - creates a device topology, which is needed for power management - allows for things like sysfs and other logical device representations - it is just the Right Way to do it
None of your questions are related to the driver model, really. It is not a new uniform driver API, if that is what you are thinking. It is a topology/hierarchal abstraction for devices.
Robert Love
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ On Tue, 2003-09-02 at 14:43, James Clark wrote:
> 1. Will the move to a more uniform driver model in 2.6 increase the chances of > a given binary driver working with a 2.6+ kernel.
I don't see how.
> 2. Will the new model reduce the use/need for kernel modules.
No. The two concepts are really unrelated.
> 3. Will the practice of deliberately breaking some binary only 'tainted' > modules prevent take up of Linux. Isn't this taking things too far?
Tainted modules are not "broken" -- they just display a "tainted" message. We do not do things to deliberately break binary-only modules.
The driver model has four main benefits, in my eyes:
- unifies code between the previous desperate driver models - creates a device topology, which is needed for power management - allows for things like sysfs and other logical device representations - it is just the Right Way to do it
None of your questions are related to the driver model, really. It is not a new uniform driver API, if that is what you are thinking. It is a topology/hierarchal abstraction for devices.
Robert Love
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |