Re: Driver Model

[Robert Love]

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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/