--On January 20, 2006 9:20:19 PM +0100 Jesper Juhl <[email protected]>
wrote:
On 1/20/06, Michael Loftis <[email protected]> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
