Re: Problem with restricted I2C algorithms in kernel 2.6.26!

[Trent Piepho <xyzzy@speakeasy.org>]

On Thu, 7 Aug 2008, Jean Delvare wrote:
> On Thu, 7 Aug 2008 09:01:35 -0700 (PDT), Trent Piepho wrote:
> > On Thu, 7 Aug 2008, Jean Delvare wrote:
> > > > One of the biggest reasons people choose to compile things from
> > > > cvs/svn/mercurial/etc. is because it gives them access to newer bug
> > > > fixes and support for things not yet present in the kernel source.  A
> > > > perfect example, the multiproto dvb driver tree.  Users wanting
> > > > support for dvb-s2 devices have to compile drivers outside of the
> > > > kernel because it's simply not available in the kernel and won't be
> > > > for some time.
> > >
> > > So basically you are telling that "thanks" to drivers being maintainers
> > > in external repositories, bugs are not fixed in the upstream kernel in
> > > a timely manner, and new features take more time to go there too? That
> > > must be the reason why kernel developers and users alike don't like
> > > external repositories in the first place.
> >
> > Code needs to get testing before it's put in the kernel.  How's that
> > supposed to happen if it's not made available outside the kernel tree
> > first?
>
> linux-next.

Expecting every developer to keep abreast of linux-next and the tens of
thousands of patches it gets just isn't realisitic.

The embedded platforms I develop on won't run linux-next.  Continuously
porting them to linux-next is simply impossible.  The man hours required to
do that would be staggering.

The pool of testers available to a driver that requires running linux-next
is going to be orders of magnitude less that a driver that can be compiled
out of tree against 2.6.19 to 2.6.27.

> Having I2C-specific options selectable under the Library menu would
> probably be even more confusing. However, it would be possible to do
> something similar under the I2C menu. Much like
> CONFIG_VIDEO_HELPER_CHIPS_AUTO does for the V4L subsystem:
> CONFIG_I2C_ALGOS_AUTO would default to Y and would hide I2C algo driver
> selection (as is the case in 2.6.26), changing it to N would present
> the old menu for users to select the aldo drivers manually (as was the
> case in 2.6.25.)

This seems perfectly reasonable to me.

> Which doesn't change my point that most people complaining about the
> change would rather merge their drivers in the upstream kernel.

Somtimes maintainers aren't interested in the drivers.....