> I'm not a real friend of out-of-tree code, especially if it replaces > *existing* code from mainline. *If* such a patch is really desirable > it should be sent to LKML and walk through the review cycle. Any > single patch differing from mainline makes debugging problems > harder, so I'm quite conservative in accepting patches to main > grml-kernel.
ok - quite ok to be conservative - i can understand this. on the other hand with kernel patches it`s often sort of a chicken-egg problem. no mainline inclusion without testing, no testing without mainline inclusion....... yes, but grml is not for testing kernel patches ;) i came across the following posting and contacted the author: http://forums.gentoo.org/viewtopic-t-506388.html think we just should wait for some time...... regards roland ps: anyway - not sure if the BadRam patch changes relevant code-paths if there isn`t "badram=" specified on the commandline. > -----Ursprüngliche Nachricht----- > Von: Michael Prokop <[EMAIL PROTECTED]> > Gesendet: 29.10.06 23:31:18 > An: [email protected] > Betreff: Re: [Grml] BadRam/BadMem Kernelpatch > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [20061029 15:12]: > > > Since grml seems to become more and more THE live-cd for admins, > > and maybe often being used for recovery purpose to save data from > > more or less "dead" boxes - did anybody think of taking a look at > > the BadRam Kernelpatch ? > > http://rick.vanrein.org/linux/badram/index.html > > Yes, I'm aware of that patch. > > [...] > > Unfortunately, I don`t have personal experience with this patch > > (yet), but maybe there are people on this list who know that patch > > already !? > > > It exists for quite some time and a version for recent 2.6.18 > > kernel is available. > > > Also, there exists a spin-off project "BadMem" at > > http://badmem.sourceforge.net/ > > I'm not a real friend of out-of-tree code, especially if it replaces > *existing* code from mainline. *If* such a patch is really desirable > it should be sent to LKML and walk through the review cycle. Any > single patch differing from mainline makes debugging problems > harder, so I'm quite conservative in accepting patches to main > grml-kernel. > > thx && regards, > -mika- > -- > http://grml.org/ # Linux for texttool-users and sysadmins > http://wiki.grml.org/ # share your knowledge > http://grml.supersized.org/ # the grml development weblog > #grml @ irc.freenode.org # meet us on irc > > <hr> > _______________________________________________ > Grml mailing list - [email protected] > http://lists.mur.at/mailman/listinfo/grml > join #grml on irc.freenode.org > grml-devel-blog: http://grml.supersized.org/ _______________________________________________________________________ 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 _______________________________________________ Grml mailing list - [email protected] http://lists.mur.at/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog: http://grml.supersized.org/
