Hello All,
This question might sound dumb for many, and to some annoying too ;-)
Am enterting into -rc Kernel (testing & analysis) & involvement with
the kernel (contributing to patches). I have this doubt. I did refer
to applying-patches in the kernel documentation, this is what I got:-
> These are the base stable releases released by Linus. The highest numbered
> release is the most recent.
> If regressions or other serious flaws are found, then a -stable fix patch
> will be released (see below) on top of this base. Once a new 2.6.x base
> kernel is released, a patch is made available that is a delta between the
> previous 2.6.x kernel and the new one.
> To apply a patch moving from 2.6.11 to 2.6.12, you'd do the following (note
> that such patches do *NOT* apply on top of 2.6.x.y kernels but on top of the
> base 2.6.x kernel -- if you need to move from 2.6.x.y to 2.6.x+1 you need to
> first revert the 2.6.x.y patch).
I did understand till here. Should I start compile/test/debug
one-after-one in this fashion:-
2.6.19 source + patch-2.6.20-rc1
2.6.19 source + patch-2.6.20-rc2
2.6.19 source + patch-2.6.20-rc3
2.6.19 source + patch-2.6.20-rc4
OR
Pick the latest release number?
Note:
Am working for different requirements in the Labs with Linux
(Telecom/Embedded). This activity starting as an independant activity
in my home/sometimes in Labs. So, I wanted to jump into kernel
development (mainly as compile/test/debug/patch). Hope I get enough
encouragement ;-)
~Akula2
On 09/01/07, Akula2 <[email protected]> wrote:
> Hello All,
>
> This question might sound dumb for many, and to some annoying too ;-)
>
> Am enterting into -rc Kernel (testing & analysis) & involvement with
> the kernel (contributing to patches). I have this doubt. I did refer
> to applying-patches in the kernel documentation, this is what I got:-
>
> > These are the base stable releases released by Linus. The highest numbered
> > release is the most recent.
>
> > If regressions or other serious flaws are found, then a -stable fix patch
> > will be released (see below) on top of this base. Once a new 2.6.x base
> > kernel is released, a patch is made available that is a delta between the
> > previous 2.6.x kernel and the new one.
>
> > To apply a patch moving from 2.6.11 to 2.6.12, you'd do the following (note
> > that such patches do *NOT* apply on top of 2.6.x.y kernels but on top of the
> > base 2.6.x kernel -- if you need to move from 2.6.x.y to 2.6.x+1 you need to
> > first revert the 2.6.x.y patch).
>
> I did understand till here. Should I start compile/test/debug
> one-after-one in this fashion:-
>
> 2.6.19 source + patch-2.6.20-rc1
> 2.6.19 source + patch-2.6.20-rc2
> 2.6.19 source + patch-2.6.20-rc3
> 2.6.19 source + patch-2.6.20-rc4
>
> OR
>
> Pick the latest release number?
>
Depends on what you want to do. If you want a stable kernel to use in
production you should probably pick the latest stable kernel
(currently that's 2.6.19.1).
If you want to help fix bugs, develop features, test etc, then it is
usually best to use the latest development snapshot available. An
easy way to always have the tip of the tree available is to use git -
see this document for more info : http://linux.yyz.us/git-howto.html
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Akula2 <[email protected]> wrote:
> This question might sound dumb for many, and to some annoying too ;-)
It's OK if you don't do it too often ;-)
[...]
> I did understand till here. Should I start compile/test/debug
> one-after-one in this fashion:-
>
> 2.6.19 source + patch-2.6.20-rc1
> 2.6.19 source + patch-2.6.20-rc2
> 2.6.19 source + patch-2.6.20-rc3
> 2.6.19 source + patch-2.6.20-rc4
>
> OR
>
> Pick the latest release number?
Pick the latest, it has bugs in earlier ones fixed. But it might have its
own ;-)
BTW, you can track the day-to-day development of the kernel (and other
stuff) using git, which has other nifty features (like being able to go
back to an earlier version, and even automate the finding of the broken
patch by narrowing down from a known good and a known bad version).
git is probably in your distribution, or you can get it (as source, or
prebuilt) from <http://kernel.org/pub/software/scm/git>, a bunch of
documentation is in the package itself or at <http://www.git.or.cz>.
<http://www.kernel.org> gives pointers to several git kernel repositories.
Good luck!
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
Akula2 wrote:
> Should I start compile/test/debug one-after-one in this fashion:-
>
> 2.6.19 source + patch-2.6.20-rc1
> 2.6.19 source + patch-2.6.20-rc2
> 2.6.19 source + patch-2.6.20-rc3
> 2.6.19 source + patch-2.6.20-rc4
Or
linux-2.6.19 + testing/patch-2.6.20-rc1 = linux-2.6.20-rc1
linux-2.6.20-rc1 + testing/incr/patch-2.6.20-rc1-rc2 = linux-2.6.20-rc2
linux-2.6.20-rc2 + testing/incr/patch-2.6.20-rc2-rc3 = linux-2.6.20-rc3
and so on.
> OR
>
> Pick the latest release number?
Or this. Or use git as was suggested by others, to track kernel changes
in a finer-grained manner. Or try the -mm patchset which has --- how
shall I call it --- pre-release code. Or track some subsystem-specific
or architecture-specific development trees if you are especially
interested in a platform or driver subsystem. See the MAINTAINERS file
for their development repositories. These repos do not always carry
self-contained source trees though, and what purposes they serve for the
maintainers and how they can be used by others than the maintainers
differs from repo to repo.
--
Stefan Richter
-=====-=-=== ---= -=--=
http://arcgraph.de/sr/
On 1/9/07, Jesper Juhl <[email protected]> wrote:
> Depends on what you want to do. If you want a stable kernel to use in
> production you should probably pick the latest stable kernel
I am a Linux user/developer in all my IT career which began in 1997.
But always my goal to be a kernel developer and a contributor after
getting hardened. But my career didn't allow me to do this LKML work
except regular reading (frequent change of projects & skills in
Telecom/Embedded). Since last year am with Big B (don't want to name
my company here. Because many people on this list are from the same
company, might get offended because of my novice questions. Or, They
might see me as a silly guy!)
But my interest reached to impossible level to hold anymore. From now
on I want to be an active contributer among this great community :)
Sorry for this big rant. These kernels I test would be for my
Workstations/Embedded boards (ARM & Power) at my home & my Labs
(example ThinkCentre A51). Not for any production Servers as of now.
> (currently that's 2.6.19.1).
I did start involving with LKML & posted a few too. But, I didn't get
any pointer from you guys.
http://lkml.org/lkml/2007/1/4/228
http://lkml.org/lkml/2007/1/5/74
Maybe I did something naive or stupid in the effort above or in the
posting here. Dunno!
> If you want to help fix bugs, develop features, test etc, then it is
> usually best to use the latest development snapshot available. An
> easy way to always have the tip of the tree available is to use git -
> see this document for more info : http://linux.yyz.us/git-howto.html
Just now compiled 2.6.20-rc4 too. So I have already started the
effort, here is we go:-
[sukhoi@Typhoon linux-2.6.20-rc4]$ ll /boot/
total 13004
-rw-r--r-- 1 root root 70195 Dec 16 04:22 config-2.6.18-1.2868.fc6
drwxr-xr-x 2 root root 4096 Jan 10 02:15 grub
-rw------- 1 root root 1519417 Dec 26 19:35 initrd-2.6.18-1.2868.fc6.img
-rw------- 1 root root 1391180 Jan 9 23:12 initrd-2.6.19.1-Topol-M.img
-rw------- 1 root root 1383782 Jan 10 02:15 initrd-2.6.20-rc4.img
-rw-r--r-- 1 root root 94600 Jul 13 10:44 memtest86+-1.65
-rw-r--r-- 1 root root 95025 Dec 16 04:23 symvers-2.6.18-1.2868.fc6.gz
lrwxrwxrwx 1 root root 21 Jan 10 02:14 System.map -> System.map-2.6.20-rc4
-rw-r--r-- 1 root root 887701 Dec 16 04:22 System.map-2.6.18-1.2868.fc6
-rw-r--r-- 1 root root 965328 Jan 9 23:11 System.map-2.6.19.1-Topol-M
-rw-r--r-- 1 root root 957961 Jan 10 02:14 System.map-2.6.20-rc4
lrwxrwxrwx 1 root root 18 Jan 10 02:14 vmlinuz -> vmlinuz-2.6.20-rc4
-rw-r--r-- 1 root root 1816959 Dec 16 04:22 vmlinuz-2.6.18-1.2868.fc6
-rw-r--r-- 1 root root 2036631 Jan 9 23:11 vmlinuz-2.6.19.1-Topol-M
-rw-r--r-- 1 root root 1993172 Jan 10 02:14 vmlinuz-2.6.20-rc4
> Jesper Juhl <[email protected]>
Thanks,
~Akula2
On 1/10/2007 4:00 PM, Lei W wrote:
> If now i have applied patch-2.6.19.1,how can i goto
> 2.6.20-rc4 ?
$ cd linux/
$ patch -p1 -R < patch-2.6.19.1
$ patch -p1 < patch-2.6.20-rc4
--
Stefan Richter
-=====-=-=== ---= -=-=-
http://arcgraph.de/sr/
On Wed, 10 Jan 2007 19:07:32 +0100
Stefan Richter <[email protected]> wrote:
> On 1/10/2007 4:00 PM, Lei W wrote:
> > If now i have applied patch-2.6.19.1,how can i goto
> > 2.6.20-rc4 ?
>
> $ cd linux/
> $ patch -p1 -R < patch-2.6.19.1
> $ patch -p1 < patch-2.6.20-rc4
for Lei W:
cd linux/
ketchup 2.6.20-rc4
http://www.selenic.com/ketchup/wiki/
:)
--
Paolo Ornati
Linux 2.6.20-rc4-gf3a2c3ee on x86_64