linux-kernel - Re: Problem with restricted I2C algorithms in kernel 2.6.26!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 8 Aug 2008 10:52:05 -0700 (PDT)
From:	Trent Piepho <xyzzy@...akeasy.org>
To:	Jean Delvare <khali@...ux-fr.org>
cc:	"D. Kelly" <user.kernel@...il.com>,
	Sam Ravnborg <sam@...nborg.org>,
	"mailing list: linux-kernel" <linux-kernel@...r.kernel.org>,
	Linux I2C <i2c@...sensors.org>
Subject: Re: Problem with restricted I2C algorithms in kernel 2.6.26!

On Fri, 8 Aug 2008, Jean Delvare wrote:
> On Thu, 7 Aug 2008 16:41:10 -0700 (PDT), Trent Piepho wrote:
> > 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.
>
> Once again a "believe me it's impossible" without any good reason
> given. I fail to see why embedded platforms would be any different from
> other platforms or subsystem trees. Please enlighten me.

Because they usually require lots of additional patches that aren't in the
kernel.  Sometimes embedded developers try to get these patches into the
mainline kernel, but some maintainers aren't interested in accepting
patches that don't appear to be useful to desktop users.

> > 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.
>
> Except that distributions start packaging linux-next, while in general
> they don't package out-of-tree versions of packages that are also
> available in the kernel tree. If the v4l-dvb tip was in linux-next (it

Sure they do.  There are packages of the latest v4l-dvb, nvidia and ATI
drivers, and more.  There is even a system, DKMS, used to allow kernel
module source packages to be installed and automatically rebuilt for new
kernels.

You can install and run a new module without even rebooting.  Installing
linux next is quite a bit more complex.  Users won't test your driver if
they have to install a new kernel for every revision.

It's a nightmare for development too.  I can't develop the entire kernel,
it's too big and there are too many changes.  If my driver has become
unstable, is it something I did or one of the 20,000 patches that have
appeared in linux-next?  Like Mike said, one needs a stable platform to
develop on.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/