public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Trent Piepho <xyzzy@speakeasy.org>
Cc: "D. Kelly" <user.kernel@gmail.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	"mailing list: linux-kernel" <linux-kernel@vger.kernel.org>,
	Linux I2C <i2c@lm-sensors.org>
Subject: Re: Problem with restricted I2C algorithms in kernel 2.6.26!
Date: Thu, 7 Aug 2008 18:14:16 +0200	[thread overview]
Message-ID: <20080807181416.5de4ce6d@hyperion.delvare> (raw)
In-Reply-To: <Pine.LNX.4.58.0808070851310.10341@shell4.speakeasy.net>

Hi Trent,

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.

> Why does the kernel build system support building out of tree modules if no
> one should do it?

I guess it can be convenient at times. But people doing that shouldn't
dare to complain that everything isn't perfect for them.

> Maybe an option to turn i2c algorithms on could do into the Library
> Routines menu.  There are already options for things like the crc routines
> here so they can be turned on if an out of tree driver needs them but
> nothing in the kernel does.

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.)

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

-- 
Jean Delvare

  reply	other threads:[~2008-08-07 16:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5ab239b10807161233i6c1c4d0we01ea1b8e6ccaa5b@mail.gmail.com>
2008-07-26  6:59 ` Problem with restricted I2C algorithms in kernel 2.6.26! Andrew Morton
2008-07-26 14:34   ` [i2c] " Jon Smirl
     [not found] ` <5ab239b10807161233i6c1c4d0we01ea1b8e6ccaa5b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-08-07 11:13   ` Jean Delvare
     [not found]     ` <20080807131357.59399ddf-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-08-07 16:01       ` Trent Piepho
2008-08-07 16:14         ` Jean Delvare [this message]
     [not found]           ` <20080807181416.5de4ce6d-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-08-07 17:19             ` Jean Delvare
     [not found]               ` <20080807191943.72d1802d-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-08-07 17:29                 ` Randy Dunlap
2008-08-07 23:41           ` Trent Piepho
2008-08-08  9:37             ` Jean Delvare
2008-08-08 17:52               ` Trent Piepho
2008-08-10 11:07                 ` Adrian Bunk
2008-08-07 18:39     ` Sam Ravnborg
2008-08-07 18:49       ` Jean Delvare
2008-08-07 19:03         ` Michael Krufky
2008-08-07 21:06           ` Jean Delvare
2008-08-07 21:34 mkrufky
     [not found] ` <489B6A66.40605-dJidKbW2IEtAfugRpC6u6w@public.gmane.org>
2008-08-08  0:17   ` Stefan Richter
2008-08-08  9:28 ` Jean Delvare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080807181416.5de4ce6d@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=i2c@lm-sensors.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=user.kernel@gmail.com \
    --cc=xyzzy@speakeasy.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox