Re: Problem with restricted I2C algorithms in kernel 2.6.26!

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: mkrufky
Date: Thursday, August 7, 2008 - 2:34 pm

Jean Delvare wrote:

Nobody said that a driver "...can't be merged upstream" ...  but 
REQUIRING a driver to be merged upstream to allow development and / or 
testing is a problem, IMHO.

If you required that all of my development happens within a git 
development repository, preventing me from working against distro-kernel 
xyz, then I would simply spend more time on Windows driver development 
and my Linux contributions would cease.

External subsystem development repositories allow us to work against 
stable kernels at our own pace.  When driver X is ready to be merged, it 
gets merged.

With the model that you propose, "use linux-next for development" ... 
well then what about testing?  Who is going to test my driver if it 
requires a full kernel compile?

Khali, you know me, and you know that I am always in favor of merging 
drivers into the kernel.  The ability to choose a kernel's features is 
an option that should not be removed.

Regards,

Mike
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: Problem with restricted I2C algorithms in kernel 2.6.26!, mkrufky, (Thu Aug 7, 2:34 pm)