telling [EMAIL PROTECTED] wrote:
Hello !
There's some really nice feature-patch named BadRAM at
http://rick.vanrein.org/linux/badram/index.html for years now, being
announced around 2000 on this list, voted for inclusion in 2.3.99.
BadRAM let's you tell the kernel to skip certain regions of ram, so
you can continue using defective modules. Some older article describing
BadRAM in more detail is at http://www.linuxjournal.com/article/4489
[...snip...]
Basically, this feature is a matter of adding/modifying 200 lines of
code, so iŽm even more wondering, why it exists for more than 7 years
and nothing happening here. I don`t know of any kernel patch which is
comparable to this.
Think about that... 200 lines of code which will have to be maintained
forever, once it becomes a supported feature, for the benefit of the few
people who can't or won't replace bad memory.
This patch is real a ressource-saver - if being a standard Linux
feature, it will save even more ressources: Saving user's time (because
they are pulling their hair out to get this run with kernel XYZ) and
also saving CPU time (no compile orgies anymore), and thus waste of energy.
Consider one technical and one human behavour issue. While memory with
"bad spots" was common a decade ago, it's as likely with current memory
that the memory will "throw a bad bit" once in a while, on a read or
write anywhere in the marginal or bad chip. Depending on how the memory
is organized that could be 1/16th of the memory as a block of 32MB on a
512MB part, or every 16th byte in the whole memory.
As for the human issue, how many more people will use this capability to
avoid buying memory, run with only part of the bad memory detected and
blocked out, get unreliable operation, and think that Linux is unreliable.
Please comment if someone sees chances of getting this (after years
of
existance) into mainline and also please jump in to make the good thing
happen !
I personally think that the patch is at best a balance between benefit
and problems. As a patch I have to use deliberately I think it's a good
idea. As a permanent and default part of the kernel, I'm not convinced.
There are some patches I would love to see in mainline, like suspend2
which includes resume as well as suspend, but this is not one of them,
hope I've explained why.
As with so many other things in life, "it's not the cost but the upkeep."
Historical patch collection at:
http://rick.vanrein.org/linux/badram/download.html
Most recent version of BadRAM should be:
http://rick.vanrein.org/linux/badram/software/BadRAM-2.6.19.1.patch
Sorry for being a little bit "noisy" here, but I think BadRAM is a
great feature and Linux could really benefit from that.
regards
Roland K.
Sysadmin
List: linux-kernel
Subject: Re: Free Linux Driver Development!
From: devzero () web ! de
Date: 2007-02-04 21:37:33
Message-ID: 1605445807 () web ! de
[Download message RAW]
First off, compliments to this announcement, I liked it very much!
Some comment regarding those "volunteers, waiting to get some real work" :)
OK, but why isn't your army of volunteers fixing them?
They don't know about them, or they don't have the hardware to test?
Seriously, let the kernel-janitor's project know about any issues you
have and they will be glad to jump on it. Those people are just
chomping a the bit to do something a bit bigger than "compiler warning
cleanups" :)
So many times i have seen good ideas brought up, kernel patches being written,
posted \
to lkml, being developed outside mainline for a while and then being forgotten
some \
time later due to lack of energy of some individual to get this into mainline.
If there is an noticeably number of talented programmers (unfortunately, i`m
not) , \
so why not "feeding" them the right way ? Where is those public and transparent
and \
moderated Linux-Kernel "ToDo"- or "Keep an eye on"-list, sorted by priorities,
with \
sort of a "vote for this feature"-button, so those guys have something they can
pick \
up? There is so much great stuff and ideas out there where they could put their
work \
onto or getting involved, it just needs to be found or sort of being "managed"
a \
little bit better.
For myself, i`m waiting for so quite some things to get "one step further", but
they \
are more or less tied to some single individuals, for which you just cannot
send some \
"hey, what`s up with your project"-message every second day. The interest in
many \
nice projects often is quite low and evolution quite slow, but not only because
of \
the fact that they aren`t great, but more because of not getting widely known.
It`s \
not always missing specs, it`s also some missing noise/feedback for different \
features or missing of some "driving force" to bring things forward. How should
one \
developer know that somebody needs a feature if those who could probably need
it \
don`t request it? Maybe just because of the fact that they even imagine that
such \
feature would be possible ?
Where is those efforts for fixing/integrating fantastic cowloop?
What about badram/badmem patch ?
Compressed Ccaching ?
Somebody helping with development of dm-loop or extend loop.c to support more
than \
256 devices ? Replacement of proprietary, unstable and unelegant vmware-lopp
for \
being able to mount vmware .vmdk files ? Internal Spec for this is open,
dm-userspace \
could be some infrastructure for this, but the author seems to have other \
priorities.... dm-cow, zfs-fuse - anybody ?
Kernel based target for AoE (Ata over Ethernet) ? (there are two independent \
implementations, but both got stuck at some early experimental stage)
Just my 2 cents.
Roland K.
Sysadmin
ps:
This isn`t meant to criticise any of you kernel developers since you`re doing \
fantastic work!
_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222
--
Bill Davidsen <[EMAIL PROTECTED]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
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/
