linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Loftis <mloftis@wgops.com>
To: Jesper Juhl <jesper.juhl@gmail.com>
Cc: dtor_core@ameritech.net,
	James Courtier-Dutton <James@superbug.co.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: Development tree, PLEASE?
Date: Fri, 20 Jan 2006 14:48:22 -0700	[thread overview]
Message-ID: <0FA349BF620394796EB40A3A@d216-220-25-20.dynip.modwest.com> (raw)
In-Reply-To: <9a8748490601201220h2d85fa4au780715ff287cf1eb@mail.gmail.com>



--On January 20, 2006 9:20:19 PM +0100 Jesper Juhl <jesper.juhl@gmail.com> 
wrote:

> On 1/20/06, Michael Loftis <mloftis@wgops.com> wrote:
>>
> [snip]
>> I'm trying to think of a way to relate this better but I just can't.
>> What's needed is a 'target' for incremental updates, things like minor
>> changes, bugfixes, etc.  I feel like supporting entirely new hardware
>
> That's called a vendor kernel.
> You pay the vendor money, the vendor maintains a stable (as in feature
> frozen) kernel, backports bugfixes for you etc.
> Take a look at the RedHat and SuSE enterprise kernels, they seem to be
> what you want.

RedHat's kernel is, I'm sorry, a car wreck of too many patches.  We tried 
that in the hosting environment, had many many gremlins as a result.  Most 
of which are still unresolved.  I've got httpd's and mysqld's that the 
root/listener process uses up almost all of the CPU.  And they're not doing 
anything.

Even without that I'm all for cleaner kernels, hopefully with pretty well 
documented reasons behind changes or clear reasons.  RH is trying to be 
everything, which is fine for them and their intended audience.  I've never 
really been happy with their kernels, nor with their base os.  Many are 
though.

Why can't a community do this though?  I guess the answer is there's no 
reason a community cant, jsut the mainline developers are not going to, 
because it's too much work.

> In my book 'stable' means 'doesn't crash' and 'doesn't break userspace
> without long advance notice', it doesn't mean 'does not evolve/goes
> stale'.
> And in my oppinion the current 2.6 tree succeeds in being a stable kernel.

I think stable should also include bugfixes and updates without having to 
take (potentially, if not certainly) incompatible changes along with that. 
Which yes, is closer to many distro's models.

>
> Besides, I don't agree with your view that we break userspace all the
> time as you seem to be saying in several of your mails, quite the
> opposite - a lot of work goes into *not* breaking userspace.
> Just take a look at how syscalls are maintained, even old obsolete
> ones stay in place since removing them would break userspace. Stuff in
> /proc does not get changed since that would potentially break
> userspace. Look at the fact that you can still run ancient a.out
> binaries on a recent 2.6.x kernel.
> Even internal kernel APIs usually stay around with __deprecated or as
> wrappers around new APIs for extensive periods of time.
> And when stuff is removed it's announced for ages in advance. That
> devfs would be removed was announced several *years* before it
> actually happened. That old OSS drivers will be removed (but only for
> hardware that has ALSA equivalents) has been announced months ago and
> the removal won't happen for several months (at least) yet.
>
> I'd say the kernel tries damn hard at maintaining backwards
> compatibility for userspace.
> It tries less hard, but still makes a pretty good effort, for internal
> APIs, but the real solution to the internal API churn is to get your
> code merged as it'll then get updated automagically whenever something
> changes - people who remove or change internals try very hard to also
> update all (in-tree) users of the old stuff - take a look at when I
> removed a small thing like verify_area() if you want an example.

The only argument I have is one that won't fly at all here on LKML and 
that's about all the corporate sponsors the LK has that are also doing 
custom closed source modules that are only useful for their particular 
hardware.  I'm working with more than one such company now, if they want to 
step forward and name themselves they can, but I can't name them.  Without 
these companies paying various salaries and developing using Linux and 
pushing bugfixes back/etc on the open source portions of their products it 
would be a different landscape.

>> It's horrificly expensive to maintain large numbers of machines (even if
>> it's automated) as it is.  If you're doing embedded development too or
>> instead, it gets even harder when you need certain bugfixes or minor
>> changes, but end up having to redevelop things or start maintaining your
>> own kernel fork.
>>
> The solution here is to get your code merged in mainline.

Most of it can't.  Or simply won't be accepted.  Noone else has use for a 
PPC where the GPIO is driving a custom data acquisition FPGA, or things of 
that nature.  Some of it is the same old problem of proprietary firmware 
and IP.  Some of it isn't.  Most of it is just simply useless to everyone 
but the device's manufacturer, and thus wouldn't be maintained anyway, much 
less accepted.  I guess for those cases that it *might* be accepted and can 
be exported I'll have to decide where the tradeoff occurs between answering 
external questions about hardware that doesn't exist outside of these 
devices and apps.

There again, this is still just one part of the problem as a whole 
discussed in this thread.






  reply	other threads:[~2006-01-20 21:48 UTC|newest]

Thread overview: 126+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-20 15:17 Development tree, PLEASE? Michael Loftis
2006-01-20 15:31 ` Michael Loftis
2006-01-20 15:59 ` Marc Koschewski
2006-01-20 16:07   ` Michael Loftis
2006-01-20 16:34     ` Marc Koschewski
2006-01-20 17:04       ` Michael Loftis
2006-01-20 16:35     ` Marc Koschewski
2006-01-20 17:06       ` Michael Loftis
2006-01-20 17:31         ` Diego Calleja
2006-01-20 20:43         ` Kyle Moffett
2006-01-20 16:41     ` Jan Engelhardt
2006-01-20 17:14       ` Michael Loftis
2006-01-20 19:43         ` Greg KH
2006-01-20 20:56           ` Michael Loftis
2006-01-20 21:06             ` Christopher Friesen
2006-01-20 23:00             ` Horst von Brand
2006-01-20 23:17             ` Russell King
2006-01-20 23:33               ` Michael Loftis
2006-01-20 23:55                 ` Russell King
2006-01-21  0:05                   ` Michael Loftis
2006-01-21  0:26                     ` Lars Marowsky-Bree
2006-01-20 23:27             ` Greg KH
2006-01-20 23:52               ` Michael Loftis
2006-01-21  0:03                 ` Russell King
2006-01-21  1:38             ` Alan Cox
2006-01-20 20:25         ` Russell King
2006-01-20 22:05           ` Michael Loftis
2006-01-20 22:54     ` Horst von Brand
2006-01-20 16:40   ` Dmitry Torokhov
2006-01-20 16:48     ` Marc Koschewski
2006-01-20 16:55       ` Dmitry Torokhov
     [not found]         ` <20060120172431.GE5873@stiffy.osknowledge.org>
2006-01-20 17:43           ` Dmitry Torokhov
2006-01-20 17:53             ` Marc Koschewski
2006-01-20 18:00               ` Dmitry Torokhov
2006-01-20 18:06                 ` Marc Koschewski
2006-02-13 17:17               ` Dmitry Torokhov
2006-01-20 16:29 ` James Courtier-Dutton
2006-01-20 16:36   ` Michael Loftis
2006-01-20 16:50     ` Dmitry Torokhov
2006-01-20 17:31       ` Michael Loftis
2006-01-20 19:03         ` Valdis.Kletnieks
2006-01-20 19:10           ` Michael Loftis
2006-01-20 23:20             ` Bernd Petrovitsch
2006-01-20 23:54               ` Michael Loftis
2006-01-20 19:21           ` Michael Loftis
2006-01-20 19:24             ` Valdis.Kletnieks
2006-01-20 20:00             ` Russell King
2006-01-20 21:21               ` Michael Loftis
2006-01-20 21:40                 ` Doug McNaught
2006-01-20 22:09                   ` Michael Loftis
2006-02-02 12:16                     ` David Weinehall
2006-02-02 18:25                       ` Michael Loftis
2006-02-02 20:10                         ` Dave Jones
2006-02-02 22:05                           ` Sam Ravnborg
2006-02-02 22:10                             ` Dave Jones
2006-02-02 22:19                               ` Sam Ravnborg
2006-02-02 22:31                                 ` Dave Jones
2006-02-02 22:42                                   ` Sam Ravnborg
2006-02-03  1:29                                 ` Roman Zippel
2006-02-03  4:45                                 ` Theodore Ts'o
2006-02-03 12:28                               ` Roman Zippel
2006-02-03 16:04                                 ` Dave Jones
2006-02-02 22:01                         ` Willy Tarreau
2006-02-02 22:31                           ` Christopher Friesen
2006-02-03  5:08                             ` Willy Tarreau
2006-02-02 22:15                         ` David Weinehall
2006-02-02 22:47                           ` Michael Loftis
2006-01-20 20:10             ` James Courtier-Dutton
2006-01-20 20:20         ` Jesper Juhl
2006-01-20 21:48           ` Michael Loftis [this message]
2006-01-20 22:00             ` Dmitry Torokhov
2006-01-20 22:14               ` Michael Loftis
2006-01-21  9:22             ` Jan Engelhardt
2006-01-21 14:52               ` Alistair John Strachan
2006-01-21 17:03                 ` Jan Engelhardt
2006-01-20 21:50           ` Michael Loftis
2006-01-21  9:13         ` Jan Engelhardt
2006-01-20 16:53     ` Joe George
2006-01-20 17:03       ` Randy.Dunlap
2006-01-20 17:33         ` Joe George
     [not found]     ` <20060120121116.62a8f0a6.seanlkml@sympatico.ca>
2006-01-20 17:11       ` sean
2006-01-20 17:56         ` Development tree, please? Michael Loftis
     [not found]           ` <20060120131120.338ebf17.seanlkml@sympatico.ca>
2006-01-20 18:11             ` sean
2006-01-20 18:43               ` Michael Loftis
2006-01-20 17:11     ` Development tree, PLEASE? Diego Calleja
2006-01-21  1:56     ` Matthew Frost
2006-01-21  3:19       ` Matthew Frost
2006-01-21  7:22         ` Michael Loftis
2006-01-21  7:38           ` Lee Revell
2006-01-21 21:56             ` Sven-Haegar Koch
2006-01-21 22:18               ` Lee Revell
2006-01-21 22:40                 ` Michael Loftis
2006-01-21 22:47                   ` Lee Revell
2006-01-21 22:51                     ` Bernd Petrovitsch
2006-01-22  8:57                       ` Michael Loftis
2006-01-22  9:41                         ` Theodore Ts'o
2006-01-22 16:09                         ` Bernd Petrovitsch
2006-01-22 22:59                         ` Daniel Barkalow
2006-01-21 22:49                   ` Bernd Petrovitsch
2006-01-21 23:03                   ` Lee Revell
2006-01-22  9:03                     ` Michael Loftis
2006-01-22 17:03                       ` Bernd Petrovitsch
2006-01-25 21:30                         ` Nix
2006-01-25 21:36                           ` Lee Revell
2006-01-25 22:12                             ` Nix
2006-01-26  8:44                               ` Bernd Petrovitsch
2006-01-26 21:12                                 ` Jan Engelhardt
2006-01-26 21:44                                   ` Bernd Petrovitsch
2006-01-22 17:14                       ` Arjan van de Ven
2006-01-22 17:24                       ` Lee Revell
2006-01-21 11:28           ` Jesper Juhl
2006-01-21 18:09           ` Horst von Brand
2006-01-20 17:08 ` Gábor Lénárt
2006-01-21  0:36   ` Michael Loftis
2006-01-20 19:16 ` Greg KH
2006-01-20 19:27 ` Ben Collins
2006-01-20 22:04   ` Vincent Hanquez
2006-01-21 18:29     ` Johan Kullstam
2006-01-23 13:45       ` Vincent Hanquez
2006-01-24 15:35       ` Bob Copeland
2006-01-21 11:41 ` Ralf Baechle
2006-01-21  6:58 Michael Loftis
2006-03-14 13:57 Chuck Ebbert
2006-03-14 14:09 ` Arjan van de Ven
2006-03-16 20:17   ` Jan Engelhardt
2006-03-16 20:21     ` Jan Engelhardt

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=0FA349BF620394796EB40A3A@d216-220-25-20.dynip.modwest.com \
    --to=mloftis@wgops.com \
    --cc=James@superbug.co.uk \
    --cc=dtor_core@ameritech.net \
    --cc=jesper.juhl@gmail.com \
    --cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).