Problem with restricted I2C algorithms in kernel 2.6.26!
Quoted 13 lines · Jean Delvare
Hi Michael,
Quoted 9 lines · Michael Krufky
I agree with Trent and D.Kelly
These options should be made available to the user -- We should go with the patch that Jean posted, "Subject: i2c: Let users select algorithm drivers manually again" -- this is a fair compromise for both sides -- users that dont know should leave the automatic selection enabled. Users that know better can disable the automatic selection and enable what they need.
Quoted 10 lines
Quoted 3 lines
The statement, "just have the external driver merged into the kernel" is not a solution.
Why not, please? A vast majority of drivers work fine that way today. I am still waiting for someone to give me a good reason why some other drivers supposedly can't be merged upstream (something better than "believe me, it's impossible".)
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.
Quoted 4 lines
Quoted 2 lines
Removing the option to build those additional algos is a regression, IMHO
Will be addressed soon, do not worry.
Regards,
Mike
Quoted 3 lines · [email protected] wrote:
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?
We almost _never_ use linux-next in the way that we base our development on it. We use it to prepare integration.
BTW, looking back at this thread in the list archive, I see some people thoroughly confusing
- unmerged code,
- external developer repositories/ external patchkits,
- module source files outside a complete kernel source directory.
These are all independent matters.
All code starts as unmerged code.
All developers use external repositories.
However, module source files which are outside of the kernel source directory are not quite the norm. (Because the kernel build system doesn't support this.)
Signature · 8 lines
Stefan Richter -=====-==--- =--- -=--- http://arcgraph.de/sr/ _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
Hi Michael,
Quoted 6 lines · On Thu, 7 Aug 2008 17:34:30 -0400 , [email protected] wrote:
Quoted 4 lines · Jean Delvare
Why not, please? A vast majority of drivers work fine that way today. I am still waiting for someone to give me a good reason why some other drivers supposedly can't be merged upstream (something better than "believe me, it's impossible".)
Quoted 8 lines
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.
Not my goal, obviously.
Quoted 7 lines
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?
Some distributions do package linux-next. And this seems to be a very easy way to get end users to test bleeding edge code. You just tell the user to install the linux-next package and he/she's done. No need to build anything.
Signature · 1 line
Jean Delvare