Messages in this thread Patch in this message | | | Date | Sat, 9 Sep 2000 11:59:41 -0500 (CDT) | From | Oliver Xymoron <> | Subject | Re: [RFC] Changes file [was Re: modules directory] |
| |
On Sat, 9 Sep 2000, Daniel Phillips wrote:
> Simon Huggins wrote: > > On Thu, Sep 07, 2000 at 08:46:56AM +1100, Keith Owens wrote: > > ... and a few more times recent weeks ... > > > > > <rant> > > > Why don't you look in linux/Documentation/Changes? That file exist > > > precisely to stop repeated questions like this on the linux kernel > > > developers list. > > > </rant> > > > > Because the file just lists versions you need. It doesn't say "since > > version x.y.z you need a newer version". > > > > Why not make it easy on people and have a log something like: > > > > 2.4.0-testX-preY > > Requires modutils-x.y.z otherwise you get error messages like > > "blah blah blah" > > Note you should no longer frobnicate the thingummie or bad > > things will happen. > > 2.3.whatever_it_was > > You need to mount shm on blah. > > > > Now when you tell them to read this file it sticks and *next time* they > > look there too. > > Why? > > Because it's a hell of a lot easier to work out what has changed from > > one version to the next. > > > > It also means that people who ran earlier pre versions of 2.4 but didn't > > upgrade in the mean time for one reason or another can find out what has > > changed between the few versions of this file. > > > > Stuff like the shm stuff and the modutils stuff has generated a fair bit > > of traffic. Having a step by step Changelog style file would help > > people get it right the first time. > > > > Comments? > > I'd like to see a directory in the root of the kernel tree having the > name of the kernel version. Any patch that breaks things writes a one > or two line file into that directory. When it's time to release a > kernel version you do the following: > > cat 2.4.0-testX/* >>Documentation/Changes > rm -rf 2.4.0-testX > > Forgetting to do this rollup is ok, it doesn't hurt anything. > Forgetting to include the change log entry in the patch is ok too - > it's not any worse than the current situation. > > This approach gives us a way of annotating the important effects of > patches that are actually applied. > > I can think of various arguments for not doing this or something like > it, but the only substantive one I can think of is 'no, it would make > it easier to work with the kernel', and I guess this is the argument > that will be applied in this case. Disclaimer: I don't mind, in fact > being an elitist is kind of fun.
This is similar to my patch-names patch, which lets you add components to uname too. IIRC, it was rejected because it made things easier.
diff -uNr linux-2.2.0-pre6/Makefile linux/Makefile --- linux-2.2.0-pre6/Makefile Wed Jan 6 17:01:15 1999 +++ linux/Makefile Tue Jan 12 17:31:33 1999 @@ -281,7 +281,10 @@ @mv -f .ver $@ include/linux/version.h: ./Makefile - @echo \#define UTS_RELEASE \"$(KERNELRELEASE)\" > .ver + @echo -n \#define UTS_RELEASE \"$(KERNELRELEASE) > .ver + @find -maxdepth 1 -name 'patchdesc.*[^~]' -printf '+%f' | \ + sed -e 's/+patchdesc\./+/g' >> .ver + @echo \" >> .ver @echo \#define LINUX_VERSION_CODE `expr $(VERSION) \\* 65536 + $(PATCHLEVEL) \\* 256 + $(SUBLEVEL)` >> .ver @echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))' >>.ver @mv -f .ver $@ diff -uNr linux-2.2.0-pre6/patchdesc.names linux/patchdesc.names --- linux-2.2.0-pre6/patchdesc.names Wed Dec 31 18:00:00 1969 +++ linux/patchdesc.names Tue Jan 12 17:30:49 1999 @@ -0,0 +1,7 @@ +This patch adds a simple method to identify patched kernels. Patches +that include a file named 'patchdesc.*' in the top level source +directory will cause the kernel to add the file extension to the +version that is reported by uname(1). For instance, this file will +result in the 2.x.x+name being reported. + +oxymoron@waste.org Jan 12 1999 -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |