[PATCH] show patch names
Oliver Xymoron
built into a kernel. This will help track non-standard kernel versions,
such as those released by Redhat, or Alan's ac series, etc. more easily.
With this patch in place, each new patch can include a file of the form
"patchname.[identifier]" in the top level source directory and
[identifier] will then be added to the kernel version string. For
instance, Alan's ac patches could include a file named patchdesc.ac2
(containing a change log, perhaps), and the resulting kernel would be
identified as 2.2.0-pre6+ac2, both at boot and by uname.
This may prove especially useful for tracking problems with kernels built
by distribution packagers and problems reported by automated tools.
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.
+
+oxym...@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 majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Pavel Machek
> This four-line patch provides a means for listing what patches have been
> built into a kernel. This will help track non-standard kernel versions,
> such as those released by Redhat, or Alan's ac series, etc. more easily.
>
> With this patch in place, each new patch can include a file of the form
> "patchname.[identifier]" in the top level source directory and
> [identifier] will then be added to the kernel version string. For
> instance, Alan's ac patches could include a file named patchdesc.ac2
> (containing a change log, perhaps), and the resulting kernel would be
> identified as 2.2.0-pre6+ac2, both at boot and by uname.
>
> This may prove especially useful for tracking problems with kernels built
> by distribution packagers and problems reported by automated tools.
I just want to second this. I think it is very usefull to list
patches: we are approaching stable series and there are lots of
patches for stable series.
Perhaps searching only Documentation/ tree would be sufficient? (After
all, description of patch is just form of documentation, don't you
think?)
Pavel
--
The best software in life is free (not shareware)! Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
Oliver Xymoron
> > This four-line patch provides a means for listing what patches have been
> > built into a kernel. This will help track non-standard kernel versions,
> > such as those released by Redhat, or Alan's ac series, etc. more easily.
>
> I just want to second this. I think it is very usefull to list
> patches: we are approaching stable series and there are lots of
> patches for stable series.
Unfortunately, this has probably come up way too late for 2.2, which is a
shame because that's precisely where it's valuable. Maybe all the
distribution vendors will pick it up independently. :) My patch that
builds .config into the kernel (I'll post it later today after I test it a
bit) stands a couple orders of magnitude less chance, though it has quite
a bit more diagnostic value.
> Perhaps searching only Documentation/ tree would be sufficient? (After
> all, description of patch is just form of documentation, don't you
> think?)
I thought about a couple different schemes for the name files. Another is
having a special directory for them, which is nice as it allows you to do
away with the name prefix and the nasty sed pipe (or Makefile hackery).
But I think there's some value to having them in the top-level where
you're less likely to miss them when you do a build. Unless you're Alan or
Linus and are constantly merging patches, this won't be a problem, as
you'll probably have no more than a few of these.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
MOLNAR Ingo
On Thu, 14 Jan 1999, Pavel Machek wrote:
> I just want to second this. I think it is very usefull to list
> patches: we are approaching stable series and there are lots of
> patches for stable series.
i think this a step in the wrong direction. i dont think it's good in the
long run to support forked versions. forking is hard conceptually, and we
should not pretend it's easy, developers should have a maximum incentive
to merge code ...
-- mingo
Neil Conway
>
> On Thu, 14 Jan 1999, Pavel Machek wrote:
>
> > > built into a kernel. This will help track non-standard kernel versions,
> > > such as those released by Redhat, or Alan's ac series, etc. more easily.
> >
> > patches: we are approaching stable series and there are lots of
> > patches for stable series.
>
> shame because that's precisely where it's valuable. Maybe all the
> distribution vendors will pick it up independently. :) My patch that
> builds .config into the kernel (I'll post it later today after I test it a
> bit) stands a couple orders of magnitude less chance, though it has quite
> a bit more diagnostic value.
I think both are probably a good idea, on balance. The .config
inclusion needn't use more than about 1200 bytes at the extreme (if
compressed, judging by mine), and one could hardly argue that this patch
would break stuff... For space-conscious folk we can always make it a
config option ;-))
As for the patch-listing patch, I'd have it in my kernel.
Neil
Oliver Xymoron
> i think this a step in the wrong direction. i dont think it's good in the
> long run to support forked versions. forking is hard conceptually, and we
> should not pretend it's easy, developers should have a maximum incentive
> to merge code ...
Every feature that Linus didn't put in himself is a fork, if only for a
short time. Some things remain forked, in this weak sense, for much
longer, and some of them get widespread use. For instance, I believe all
of the 2.0 Redhat kernels (with the exception of 2.0.36?) were shipped
with patches. The large fd array patch may not make it into the 2.2 series
for a while, but it's likely that distribution vendors _will_ ship it so
it will be on a sizable portion of the installed base. Patches like the
crypto patches may never get merged into the official kernel, but I would
hope that most users eventually will be using them. Historically, it seems
most stable series kernels on big sites end up being run with patches. It
was certainly the case for post-1.2.13 and most of the 2.0 era.
The purpose here is not "support forks" - they're already a fact of life.
The idea is to support support, and make it easy to recognize when these
patches are in play. 2.2.0+foo saves the trouble of guessing, hey, are you
using patch foo? "Duh, I dunno, I didn't build it."
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
Oliver Xymoron
> > My patch that
> > builds .config into the kernel (I'll post it later today after I test it a
> > bit) stands a couple orders of magnitude less chance, though it has quite
> > a bit more diagnostic value.
>
> I think both are probably a good idea, on balance. The .config
> inclusion needn't use more than about 1200 bytes at the extreme (if
> compressed, judging by mine), and one could hardly argue that this patch
> would break stuff... For space-conscious folk we can always make it a
> config option ;-))
This patch can be done two ways (and I might post both). One is build the
file in as __init_data and make it accessible through a command line
option "config" which is also marked __init. Zero post-init overhead. Some
scripting wizardry with gunzip, nm and objdump lets you pull the file out
of a compressed kernel image as well (though it's ugly - I'll probably
leave it for later).
However, I've seen a number of good arguments from MEC to go all the way
and add /proc/config, which means adding ~5k of data into the kernel, but
also means always being able to recover config data and never having a
confusion about which build is actually running. This, together with my
patchnames patch, makes reporting kernel build information very easy to
automate.
MOLNAR Ingo
On Thu, 14 Jan 1999, Oliver Xymoron wrote:
> However, I've seen a number of good arguments from MEC to go all the way
> and add /proc/config, which means adding ~5k of data into the kernel
> [...]
an order less than a ~5k .config, instead of bloat like this:
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
CONFIG_M686=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_TSC=y
it's enough to store:
EXPERIMENTAL
M686
X86_WP_WORKS_OK
X86_INVLPG
X86_BSWAP
X86_POPAD_OK
X86_TSC
my 7k .config can be stored in 600 bytes plaintext with this method, and i
have compressed it down the 300 bytes with gzip. Storing a stripped down
and gzip-ed .config in the kernel and reporting it to user-space via /proc
doesnt sound like a big overhead, and certainly simplifies/cleans up the
bug reporting process.
> also means always being able to recover config data and never having a
> confusion about which build is actually running. This, together with my
> patchnames patch, makes reporting kernel build information very easy to
> automate.
.config is a fact of life. I dont agree with your patches idea though,
'production quality patches' outside the main kernel are an artifact of
bad communication. we should _not_ make it easier. People playing with
'experimental patches' should be fully aware of the risks.
-- mingo
Nicholas J. Leon
# However, I've seen a number of good arguments from MEC to go all the way
# and add /proc/config, which means adding ~5k of data into the kernel, but
# also means always being able to recover config data and never having a
# confusion about which build is actually running. This, together with my
# patchnames patch, makes reporting kernel build information very easy to
# automate.
This has all been done before and ignored by Linus. I myself produced a
patch that did the trick.... here's an OLD version for 2.1.104 ....
From nich...@binary9.net Sun May 31 12:48:30 1998
Date: Sun, 31 May 1998 12:48:30 -0400 (EDT)
From: nich...@binary9.net
Reply-To: nich...@binary9.net
To: linux-...@vger.rutgers.edu
Subject: [PATCH] /proc/config.gz V0.3
Message-ID: <Pine.LNX.3.96.98053...@neko.binary9.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
X-Status:
Alrighty folks -
Here is version 0.3 of my /proc/config.gz implementation. Thanks to the
input from several very helpful people, I've made a few changes. I've now
made it a configurable item (CONFIG_PROC_CONFIG), though I did make it
default to "Y" for all architectures.
The makehexhash.c program has been replaced with an od|sed pipe in the
shell script that generates the kernel/config.c
(scripts/makeproconfig.sh).
During the generation of config.c, I do a quick test to verify that the
compressed .config is less than 4K in size.
As always, input is welcome!
diff -Nur linux.104-prist/Documentation/Configure.help linux.104-config/Documentation/Configure.help
--- linux.104-prist/Documentation/Configure.help Thu May 28 11:18:37 1998
+++ linux.104-config/Documentation/Configure.help Sun May 31 12:35:14 1998
@@ -5748,6 +5748,14 @@
18 kB. Several programs depend on this, so everyone should say Y
here.
+/proc/config.gz support
+CONFIG_PROC_CONFIG
+ Say Y here if you want a copy of your current kernel configuration
+ saved in the kernel that you build. This is extremely useful if you
+ ever build more than one kernel. The cost is around 1K-4K of running
+ memory. Only say no if you really can't spare this. You can sneeze
+ and lose more on memory than this.
+
NFS filesystem support
CONFIG_NFS_FS
If you are connected to some other (usually local) Unix computer
diff -Nur linux.104-prist/Makefile linux.104-config/Makefile
--- linux.104-prist/Makefile Sat May 30 14:30:06 1998
+++ linux.104-config/Makefile Sun May 31 12:34:09 1998
@@ -197,11 +197,18 @@
mkdir include/linux/modules; \
fi
+proconfig: $(TOPDIR)/kernel/config.c
+
+
+$(TOPDIR)/kernel/config.c:
+ $(CONFIG_SHELL) scripts/makeproconfig.sh > $(TOPDIR)/kernel/config.c
+
oldconfig: symlinks scripts/split-include
$(CONFIG_SHELL) scripts/Configure -d arch/$(ARCH)/config.in
if [ -r include/linux/autoconf.h ]; then \
scripts/split-include include/linux/autoconf.h include/config; \
fi
+ $(MAKE) proconfig
xconfig: symlinks scripts/split-include
$(MAKE) -C scripts kconfig.tk
@@ -209,6 +216,7 @@
if [ -r include/linux/autoconf.h ]; then \
scripts/split-include include/linux/autoconf.h include/config; \
fi
+ $(MAKE) proconfig
menuconfig: include/linux/version.h symlinks scripts/split-include
$(MAKE) -C scripts/lxdialog all
@@ -216,12 +224,27 @@
if [ -r include/linux/autoconf.h ]; then \
scripts/split-include include/linux/autoconf.h include/config; \
fi
+ $(MAKE) proconfig
config: symlinks scripts/split-include
$(CONFIG_SHELL) scripts/Configure arch/$(ARCH)/config.in
if [ -r include/linux/autoconf.h ]; then \
scripts/split-include include/linux/autoconf.h include/config; \
fi
+ $(MAKE) proconfig
+
+cloneconfig: symlinks scripts/split-include
+ @if [ -f "/proc/config.gz" ]; then \
+ mv -f .config .config.bak; \
+ cat /proc/config.gz | gzip -dc | sed 's/^/CONFIG_/' >> .config; \
+ $(CONFIG_SHELL) scripts/Configure -di arch/$(ARCH)/config.in; \
+ if [ -r include/linux/autoconf.h ]; then \
+ scripts/split-include include/linux/autoconf.h include/config; \
+ fi; \
+ $(MAKE) proconfig; \
+ else \
+ echo "Your current kernel does not support cloning."; \
+ fi
linuxsubdirs: dummy
set -e; for i in $(SUBDIRS); do $(MAKE) -C $$i; done
@@ -344,7 +367,7 @@
rm -f core `find . -name '.*.flags' -print`
rm -f vmlinux System.map
rm -f .tmp*
- rm -f drivers/char/consolemap_deftbl.c drivers/char/conmakehash
+ rm -f drivers/char/consolemap_deftbl.c drivers/char/conmakehash
rm -f drivers/sound/bin2hex drivers/sound/hex2hex
if [ -d modules ]; then \
rm -f core `find modules/ -type f -print`; \
@@ -360,7 +383,7 @@
rm -f drivers/char/hfmodem/gentbl drivers/char/hfmodem/tables.h
rm -f drivers/sound/*_boot.h drivers/sound/.*.boot
rm -f .version .config* config.in config.old
- rm -f scripts/tkparse scripts/kconfig.tk scripts/kconfig.tmp
+ rm -f scripts/tkparse scripts/kconfig.tk scripts/kconfig.tmp kernel/config.c
rm -f scripts/lxdialog/*.o scripts/lxdialog/lxdialog
rm -f .menuconfig.log
rm -f include/asm
diff -Nur linux.104-prist/arch/alpha/defconfig linux.104-config/arch/alpha/defconfig
--- linux.104-prist/arch/alpha/defconfig Mon Mar 30 03:21:39 1998
+++ linux.104-config/arch/alpha/defconfig Sun May 31 12:36:32 1998
@@ -234,6 +234,7 @@
# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
CONFIG_PROC_FS=y
+CONFIG_PROC_CONFIG=y
CONFIG_NFS_FS=y
# CONFIG_NFSD is not set
CONFIG_SUNRPC=y
diff -Nur linux.104-prist/arch/arm/defconfig linux.104-config/arch/arm/defconfig
--- linux.104-prist/arch/arm/defconfig Sun Apr 12 14:42:15 1998
+++ linux.104-config/arch/arm/defconfig Sun May 31 12:36:53 1998
@@ -187,6 +187,7 @@
# CONFIG_UMSDOS_FS is not set
CONFIG_VFAT_FS=y
CONFIG_PROC_FS=y
+CONFIG_PROC_CONFIG=y
CONFIG_NFS_FS=y
CONFIG_NFSD=y
CONFIG_SUNRPC=y
diff -Nur linux.104-prist/arch/i386/defconfig linux.104-config/arch/i386/defconfig
--- linux.104-prist/arch/i386/defconfig Thu May 14 13:43:36 1998
+++ linux.104-config/arch/i386/defconfig Sun May 31 12:36:29 1998
@@ -228,6 +228,7 @@
# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
CONFIG_PROC_FS=y
+CONFIG_PROC_CONFIG=y
CONFIG_NFS_FS=y
CONFIG_NFSD=y
CONFIG_SUNRPC=y
diff -Nur linux.104-prist/arch/m68k/defconfig linux.104-config/arch/m68k/defconfig
--- linux.104-prist/arch/m68k/defconfig Tue Mar 10 17:43:13 1998
+++ linux.104-config/arch/m68k/defconfig Sun May 31 12:36:45 1998
@@ -160,6 +160,7 @@
# CONFIG_UMSDOS_FS is not set
# CONFIG_MSDOS_PARTITION is not set
CONFIG_PROC_FS=y
+CONFIG_PROC_CONFIG=y
CONFIG_NFS_FS=y
# CONFIG_ROOT_NFS is not set
# CONFIG_SMB_FS is not set
diff -Nur linux.104-prist/arch/mips/defconfig linux.104-config/arch/mips/defconfig
--- linux.104-prist/arch/mips/defconfig Fri May 8 03:13:23 1998
+++ linux.104-config/arch/mips/defconfig Sun May 31 12:36:40 1998
@@ -246,6 +246,7 @@
# CONFIG_UMSDOS_FS is not set
CONFIG_VFAT_FS=y
CONFIG_PROC_FS=y
+CONFIG_PROC_CONFIG=y
CONFIG_NFS_FS=y
CONFIG_NFSD=y
CONFIG_SUNRPC=y
diff -Nur linux.104-prist/arch/sparc/defconfig linux.104-config/arch/sparc/defconfig
--- linux.104-prist/arch/sparc/defconfig Fri May 8 03:11:28 1998
+++ linux.104-config/arch/sparc/defconfig Sun May 31 12:36:36 1998
@@ -239,6 +239,7 @@
# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
CONFIG_PROC_FS=y
+CONFIG_PROC_CONFIG=y
CONFIG_NFS_FS=y
CONFIG_NFSD=m
CONFIG_SUNRPC=y
diff -Nur linux.104-prist/arch/sparc64/defconfig linux.104-config/arch/sparc64/defconfig
--- linux.104-prist/arch/sparc64/defconfig Fri May 8 03:11:28 1998
+++ linux.104-config/arch/sparc64/defconfig Sun May 31 12:36:49 1998
@@ -248,6 +248,7 @@
# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
CONFIG_PROC_FS=y
+CONFIG_PROC_CONFIG=y
CONFIG_NFS_FS=y
CONFIG_NFSD=m
CONFIG_SUNRPC=y
diff -Nur linux.104-prist/fs/Config.in linux.104-config/fs/Config.in
--- linux.104-prist/fs/Config.in Sat Apr 4 12:45:14 1998
+++ linux.104-config/fs/Config.in Sat May 30 23:29:43 1998
@@ -21,6 +21,10 @@
dep_tristate 'VFAT (Windows-95) fs support' CONFIG_VFAT_FS $CONFIG_FAT_FS
bool '/proc filesystem support' CONFIG_PROC_FS
+if [ "$CONFIG_PROC_FS" = "y" ]; then
+ bool ' /proc/config.gz (kernel configuration)' CONFIG_PROC_CONFIG
+fi
+
if [ "$CONFIG_INET" = "y" ]; then
tristate 'NFS filesystem support' CONFIG_NFS_FS
if [ "$CONFIG_NFS_FS" = "y" -a "$CONFIG_IP_PNP" = "y" ]; then
diff -Nur linux.104-prist/fs/proc/array.c linux.104-config/fs/proc/array.c
--- linux.104-prist/fs/proc/array.c Wed May 6 14:01:45 1998
+++ linux.104-config/fs/proc/array.c Sun May 31 10:50:55 1998
@@ -1200,6 +1200,7 @@
extern int get_rtc_status (char *);
extern int get_locks_status (char *, char **, off_t, int);
extern int get_swaparea_info (char *);
+extern int get_proc_config (char *);
#ifdef CONFIG_ZORRO
extern int zorro_get_list(char *);
#endif
@@ -1290,6 +1291,11 @@
case PROC_HARDWARE:
return get_hardware_list(page);
#endif
+#ifdef CONFIG_PROC_CONFIG
+ case PROC_CONFIG:
+ return get_proc_config(page);
+#endif
+
}
return -EBADF;
}
diff -Nur linux.104-prist/fs/proc/root.c linux.104-config/fs/proc/root.c
--- linux.104-prist/fs/proc/root.c Sun May 17 14:34:57 1998
+++ linux.104-config/fs/proc/root.c Sun May 31 11:13:21 1998
@@ -623,7 +623,13 @@
NULL, NULL /* parent, subdir */
};
#endif
-
+#ifdef CONFIG_PROC_CONFIG
+static struct proc_dir_entry proc_root_config = {
+ PROC_CONFIG, 9, "config.gz",
+ S_IFREG | S_IRUGO, 1, 0, 0,
+ 0, &proc_array_inode_operations
+};
+#endif
void proc_root_init(void)
{
proc_base_init();
@@ -694,7 +700,9 @@
#ifdef CONFIG_PROC_DEVICETREE
proc_device_tree_init();
#endif
-
+#ifdef CONFIG_PROC_CONFIG
+ proc_register(&proc_root, &proc_root_config);
+#endif
proc_bus = create_proc_entry("bus", S_IFDIR, 0);
}
diff -Nur linux.104-prist/include/linux/proc_fs.h linux.104-config/include/linux/proc_fs.h
--- linux.104-prist/include/linux/proc_fs.h Sat May 30 22:44:14 1998
+++ linux.104-config/include/linux/proc_fs.h Sun May 31 12:08:01 1998
@@ -51,6 +51,9 @@
PROC_PPC_HTAB,
PROC_SOUND,
PROC_MTRR, /* whether enabled or not */
+#ifdef CONFIG_PROC_CONFIG
+ PROC_CONFIG,
+#endif
PROC_FS
};
diff -Nur linux.104-prist/kernel/Makefile linux.104-config/kernel/Makefile
--- linux.104-prist/kernel/Makefile Wed May 6 14:01:46 1998
+++ linux.104-config/kernel/Makefile Sun May 31 10:50:07 1998
@@ -25,6 +25,10 @@
OX_OBJS += ksyms.o
endif
+ifeq ($(CONFIG_PROC_CONFIG),y)
+O_OBJS += config.o
+endif
+
CFLAGS_sched.o := $(PROFILING) -fno-omit-frame-pointer
include $(TOPDIR)/Rules.make
diff -Nur linux.104-prist/scripts/Configure linux.104-config/scripts/Configure
--- linux.104-prist/scripts/Configure Sun May 3 20:52:06 1998
+++ linux.104-config/scripts/Configure Sat May 30 23:31:48 1998
@@ -120,14 +120,19 @@
# readln prompt default oldval
#
function readln () {
- if [ "$DEFAULT" = "-d" -a -n "$3" ]; then
+ if [ \( "$DEFAULT" = "-d" -o "$DEFAULT" = "-di" \) -a -n "$3" ]; then
echo "$1"
ans=$2
else
- echo -n "$1"
- [ -z "$3" ] && echo -n "(NEW) "
- IFS='@' read ans </dev/tty || exit 1
- [ -z "$ans" ] && ans=$2
+ if [ "$DEFAULT" = "-di" -a -z "$3" ]; then
+ echo "$1"
+ ans=$2
+ else
+ echo -n "$1"
+ [ -z "$3" ] && echo -n "(NEW) "
+ IFS='@' read ans </dev/tty || exit 1
+ [ -z "$ans" ] && ans=$2
+ fi
fi
}
@@ -488,6 +493,10 @@
DEFAULT=""
if [ "$1" = "-d" ] ; then
DEFAULT="-d"
+ shift
+fi
+if [ "$1" = "-di" ] ; then
+ DEFAULT="-di"
shift
fi
diff -Nur linux.104-prist/scripts/Makefile linux.104-config/scripts/Makefile
--- linux.104-prist/scripts/Makefile Mon Jan 5 04:41:01 1998
+++ linux.104-config/scripts/Makefile Sun May 31 10:36:48 1998
@@ -34,6 +34,6 @@
$(HOSTCC) $(HOSTCFLAGS) -c -o $@ $(@:.o=.c)
clean:
- rm -f *~ kconfig.tk *.o tkparse mkdep split-include
+ rm -f *~ kconfig.tk *.o tkparse mkdep split-include
include $(TOPDIR)/Rules.make
diff -Nur linux.104-prist/scripts/makeproconfig.sh linux.104-config/scripts/makeproconfig.sh
--- linux.104-prist/scripts/makeproconfig.sh Wed Dec 31 19:00:00 1969
+++ linux.104-config/scripts/makeproconfig.sh Sun May 31 12:02:34 1998
@@ -0,0 +1,54 @@
+#!/bin/sh
+##############################################################################
+# <author> Nicholas J. Leon
+# <email> nich...@binary9.net
+# <date> May 31 1998
+# <partof> CONFIG_PROC_CONFIG
+# <version> 0.3
+#
+# with help from Peter T. Breuer <p...@it.uc3m.es>
+#
+##############################################################################
+# generates $TOPDIR/kernel/config.c which contains the current .config file
+# file in gzip compressed format.
+
+tmpfile=/tmp/.mpc.$$
+
+cat $TOPDIR/.config | grep '^CONFIG' | sed 's/CONFIG_//' | gzip -9c > $tmpfile
+
+if [ `cat $tmpfile | wc -c` -gt 4000 ]; then
+ echo "Your compressed configuration exceeds ~4K! It is not possible"
+ echo "to store it in this kernel."
+ rm -f $tmpfile
+ exit 100
+fi
+
+echo '/*'
+echo ' Autogenerated file by' $0
+echo ' On' `date` 'by' $USER "from $TOPDIR/.config"
+echo ' */'
+echo ''
+
+cat -<<EOT
+#include <linux/config.h>
+#include <linux/version.h>
+#include <linux/malloc.h>
+#include <linux/unistd.h>
+
+EOT
+
+
+cat $tmpfile | od -v -tx1 -w10 | cut -d' ' -f2- | sed -e '/^[^ ]*$/d' | ( echo "unsigned char ucTable[]= {"; \
+ sed -e 's/[^ ][^ ]*/ 0x&,/g' ; echo "};" )
+
+
+cat -<<EOT
+
+int get_proc_config(char *page) {
+ memcpy(page,ucTable,sizeof(ucTable));
+ return sizeof(ucTable);
+}
+
+EOT
+
+rm -f $tmpfile
G'day!
-- n i c h o l a s j l e o n
elegance through simplicity*http://mrnick.binary9.net*nich...@binary9.net
good fortune through truth*roaming:nj...@email.msn.com*ICQ#2170994*U+($++)
TRA#6805*not all questions have answers*pseudogeek:P+++($++)L+($++)W=lm@b9
trust no-one with an iq under 150*understand yourself before trying others
Mitchell Blank Jr
> .config is a fact of life. I dont agree with your patches idea though,
> 'production quality patches' outside the main kernel are an artifact of
> bad communication. we should _not_ make it easier. People playing with
> 'experimental patches' should be fully aware of the risks.
Although maybe we should encourage distributors to use the new 'EXTRAVERSION'
variable in the makefile (i.e. 2.2.0-redhat6.0pl1 or something)
-Mitch
Oliver Xymoron
> Although maybe we should encourage distributors to use the new 'EXTRAVERSION'
> variable in the makefile (i.e. 2.2.0-redhat6.0pl1 or something)
Trouble is, that doesn't patch cleanly. Redhat distributes patches
along with pristine source in the SRPMs, allowing you to upgrade the
source and still use the patches. If you have multiple patches fighting
over the EXTRAVERSION line, or Linus decides to remove it after the
-pre series, you get rejects.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Mitchell Blank Jr
> Trouble is, that doesn't patch cleanly. Redhat distributes patches
> along with pristine source in the SRPMs, allowing you to upgrade the
> source and still use the patches. If you have multiple patches fighting
> over the EXTRAVERSION line, or Linus decides to remove it after the
> -pre series, you get rejects.
Have one of the patchs in the SRPM just update the EXTRAVERSION line.
As someone already pointed out, people who build their own kernel (either
from .tar.bz2 or by playing RPM games) probably know what is in their
kernel and can report it themselves. The biggest need is differentiating
between 2.2.0, 2.2.0-redhat, 2.2.0-suse, 2.2.0-debian, ...
-Mitch
MOLNAR Ingo
On Thu, 14 Jan 1999, Michael Elizabeth Chastain wrote:
> Hi Ingo,
>
> I went through this argument with Oliver yesterday ...
>
> Config Language is not bash.
ok. A 7.8K .config gets compressed to 2.1K via gzip --best, thats quite
good already.
-- mingo
Neil Conway
>
> On Thu, 14 Jan 1999, Michael Elizabeth Chastain wrote:
>
> > Hi Ingo,
> >
> > I went through this argument with Oliver yesterday ...
> >
> > Config Language is not bash.
>
> ok. A 7.8K .config gets compressed to 2.1K via gzip --best, thats quite
> good already.
Right: that's quite a few positive replies regarding something like
/proc/config.gz.
Anyone prepared to argue against it?
Neil
Matthias Andree
> As someone already pointed out, people who build their own kernel (either
> from .tar.bz2 or by playing RPM games) probably know what is in their
> kernel and can report it themselves. The biggest need is differentiating
> between 2.2.0, 2.2.0-redhat, 2.2.0-suse, 2.2.0-debian, ...
SuSE have several RPMs in their packages: one, linclude with just the
includes, linux with the actual kernel sources (without includes, they have
a dependency for that) and finally lx_suse with their hacked kernel version
complete with includes. Anyways, I think, there are a lot of people who just
follow some Kernel compilation FAQ to get their own kernel compiled with
different settings, yet they do know nothing about patches. This is where
a sort of patch registration comes in handy. It need not necessarily be in
the version itself, but a /proc/kernelconfig would also be fine. PLUS: if we
NUMBER each configuration option, not re-assigning numbers as options
disappears, we can handle all options with 2 bit each:
yes/module/no/illegal-state. The tool that decompresses the .config
information could then be either in user-space (binutils/modutils?) or a
module.
We can of course have the configuration linked in in plain text (stripping
everything that's commented out and stripping CONFIG_ prefixes), I don't
actually care since it does not matter if my bzImage is 891 or 896 k :) For
people with embedded systems, this .config-stored-in-kernel-thingy should be
optional to allow for tiny kernels.
--
Matthias Andree
--- How to obtain PGP public key
<man...@dosis.uni-dortmund.de> <<< /finger/ this
<m_an...@line.org> <<< mail, subject "SEND PGP-PUBLIC-KEY"
Manuel J. Galan
[...]
> kernel and can report it themselves. The biggest need is differentiating
> between 2.2.0, 2.2.0-redhat, 2.2.0-suse, 2.2.0-debian, ...
NO, PLEASE. no BSD splitting wars in Linux field!
Oliver Xymoron
> Yes. Because the
>
> cat .config.in >> zImage
>
> suggestion is even better. It takes no kernel memory and you can yank it off
> the image trivially
True, but it's also much less useful. It assumes you can identify which
kernel image you booted, etc. For instance, you're debugging a machine
with an uptime of 120 days, and the admin you're helping doesn't know
which kernel he booted.. It's also not available at boot time, which is
a useful debugging feature.
Now if only I could have stirred up this much discussion with my
patchnames patch..
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
MOLNAR Ingo
On Thu, 14 Jan 1999, Alan Cox wrote:
> > kernel image you booted, etc. For instance, you're debugging a machine
> > with an uptime of 120 days, and the admin you're helping doesn't know
> > which kernel he booted.. It's also not available at boot time, which is
>
> If the admin doesnt know which kernel he booted, he hasn't got symbol tables
> or .config data. In those cases I wouldnt even bother debugging it much
he has symbols, in /proc/ksyms. That together with /proc/config.gz enables
us to extrapolate the oops.
-- mingo
Michael Meissner
> > Trouble is, that doesn't patch cleanly. Redhat distributes patches
> > along with pristine source in the SRPMs, allowing you to upgrade the
> > source and still use the patches. If you have multiple patches fighting
> > over the EXTRAVERSION line, or Linus decides to remove it after the
> > -pre series, you get rejects.
>
> Have one of the patchs in the SRPM just update the EXTRAVERSION line.
>
> from .tar.bz2 or by playing RPM games) probably know what is in their
> between 2.2.0, 2.2.0-redhat, 2.2.0-suse, 2.2.0-debian, ...
First of all, I recall we had this discussion about year ago, and Linus turned
it down as kernel bloat. We even had people thinking about putting the .config
file in another section of the zImage file that wouldn't get loaded.
However, I would challenge your assumption that people know what is in their
kernel. Like a lot of us, I build my own kernels, etc. But I'm continually
tinkering with it. Maybe I built it without masquerade support because I
wasn't using it at the time (or because it was 2.2.0-pre5 to use a recent
example, and it didn't build with masquerade enabled). Particularly as you go
to earlier kernels that I've saved in my /boot partition. Lets see, I have 8
different versions in there right now, along with a tar'ved version of the
appropriate modules directory that I can untar in a flash if need be, and I
have 2-3 floppies sitting around the office with a kernel, lilo, and the tar'ed
and gzip'ed module directory for fast booting.
My personal vote would be to have a sed script eliminate all of the 'no'
answers in the .config file and the 'CONFIG_' prefix, convert it into a large
string, compile it, and then print it out in /proc/version after the version #
line (and of course break a whole new round of badly written /proc munging
programs, but that seems to be a Linux tradition).
--
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meis...@cygnus.com, 617-354-5416 (office), 617-354-7161 (fax)
Michael Meissner
> > Right: that's quite a few positive replies regarding something like
> > /proc/config.gz.
> >
> > Anyone prepared to argue against it?
>
>
> cat .config.in >> zImage
>
> suggestion is even better. It takes no kernel memory and you can yank it off
> the image trivially
Assuming you still have the image floating around. Kernels do get zapped, and
floppies do get lost/overwritten.
Paul Damplon
>Date: Thu, 14 Jan 1999 12:22:05 -0600 (CST)
>From: Oliver Xymoron <oxym...@waste.org>
>To: Alan Cox <al...@lxorguk.ukuu.org.uk>
>cc: Neil Conway <nconwa...@ukaea.org.uk>,
mi...@chiara.csoma.elte.hu, m...@shout.net, linux-...@vger.rutgers.edu
>Subject: Re: Building .config into the kernel
>
>On Thu, 14 Jan 1999, Alan Cox wrote:
>
>> Yes. Because the
>>
>> cat .config.in >> zImage
>>
>> suggestion is even better. It takes no kernel memory and you can yank
it off
>> the image trivially
>
>True, but it's also much less useful. It assumes you can identify which
>kernel image you booted, etc. For instance, you're debugging a machine
>with an uptime of 120 days, and the admin you're helping doesn't know
>which kernel he booted.. It's also not available at boot time, which is
>a useful debugging feature.
the booted kernel name is available as the environ of init under
/proc/1
>
>Now if only I could have stirred up this much discussion with my
>patchnames patch..
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Fred Reimer
> Oliver Xymoron wrote:
> > Trouble is, that doesn't patch cleanly. Redhat distributes patches
> > along with pristine source in the SRPMs, allowing you to upgrade the
> > source and still use the patches. If you have multiple
> patches fighting
> > over the EXTRAVERSION line, or Linus decides to remove it after the
> > -pre series, you get rejects.
>
> Have one of the patchs in the SRPM just update the EXTRAVERSION line.
>
> As someone already pointed out, people who build their own
> kernel (either
> from .tar.bz2 or by playing RPM games) probably know what is in their
> kernel and can report it themselves. The biggest need is
> differentiating
> between 2.2.0, 2.2.0-redhat, 2.2.0-suse, 2.2.0-debian, ...
If you want to do that, have the distributers change UTS_SYSNAME, not
appending the dist name to the version. This would make more sense, IMHO.
Fred
Barrett G. Lyon
>True, but it's also much less useful. It assumes you can identify which
>kernel image you booted, etc.
Can't you do something like:
cat vmlinux | grep "version" | head -1 ; uname -a
and match the build numbers? Just use gzcat on machines that use a
compressed kernel such as the Alpha.
-Barrett
--
Barrett G. Lyon PGP: www.netpr.com/pgpkeys
Data & Network Security Consultant Fax: 310-737-0196
Network Presence, LLC Email: bl...@netpr.com
--
Peter T. Breuer
>
> > with an uptime of 120 days, and the admin you're helping doesn't know
> > which kernel he booted.. It's also not available at boot time, which is
>
> or .config data. In those cases I wouldnt even bother debugging it much
It's often a hard fight to find which server booted what kernel from
where and whether it still has it even for a _good_ admin. There isn't
room for more than one or two good admins per institute. The rest will
be helpless. The good ones may not be physically present, or the
machine may be only accessible in limited ways (I often lose all contact
except for the nfs mount of their /etc's on my machines, for example,
when A.Useless wrecks nis, misconfigures dns by wrapping a comment line,
or other miserable miscreant thing, but the mount leaves me just enough
leeway to be able to get in and fix things).
It's ridiculous not to waste 4k of space on a list of config options in
memory on 256MB servers holding up 30 client machines. It saves time and
avoids confusion. It helps bug reporting too .. telephone conversation:
"is your kernel configured for firewalling? .. I don't know! .. please
zcat /proc/config.gz | mail me@here please .."
uh .. flame off. Not that it was very hot.
Peter
Fred Reimer
> >True, but it's also much less useful. It assumes you can
> identify which
> >kernel image you booted, etc.
>
> Can't you do something like:
> cat vmlinux | grep "version" | head -1 ; uname -a
>
> and match the build numbers? Just use gzcat on machines that use a
> compressed kernel such as the Alpha.
No. Who says you are using vmlinux and not bzImage. What if you booted off
a floppy and don't have it anymore? What happens if you build several
kernels with the same version but different config options and don't
remember which one you loaded at the lilo prompt (assuming you're using
lilo)? Even if they were still around, you couldn't tell which one was
booted (the version number would be the same).
Peter T. Breuer
>
> Can't you do something like:
> cat vmlinux | grep "version" | head -1 ; uname -a
>
> and match the build numbers? Just use gzcat on machines that use a
Nope. You may well have the image but not the config. I've got kernels
stretching all the way back to 1.2.13 2.0.0 2.0.25 2.0.30 2.0.33 2.0.36.
Are you seriously suggesting that i have all their kernel trees, and all
the configs for each of them, for all the variant images I sprayed
around the place? Uh uh.
Peter
Peter T. Breuer
> the booted kernel name is available as the environ of init under
> /proc/1
The label in lilo, not the "name". That can also have changed. Probably
has if the kernel is old enough that you've forgotten which it is anyway.
And what if it booted via nfs, or off a floppy?
Why all this palaver? It doesn't matter if you can figure out the image.
I could probably do it by diffing symbols. The point is that it's not
easy and it is silly. Just put the config options in /proc where we can all
see them. I couldn't care less about 4k ram from a 256MB server. I couldn't
even care in an 8MB machine (and I _have_ an 8MB machine).
Barrett G. Lyon
>"A month of sundays ago Barrett G. Lyon wrote:"
>>
>> Can't you do something like:
>> cat vmlinux | grep "version" | head -1 ; uname -a
>>
>> and match the build numbers? Just use gzcat on machines that use a
>
>Nope. You may well have the image but not the config. I've got kernels
>stretching all the way back to 1.2.13 2.0.0 2.0.25 2.0.30 2.0.33 2.0.36.
>Are you seriously suggesting that i have all their kernel trees, and all
>the configs for each of them, for all the variant images I sprayed
>around the place? Uh uh.
_NO_ I am not suggesting that you keep the trees for all those old kernels.
I am mearly suggesting that if you do have the kernel image stored on
mounted fs, you do have the ability to figure out what kernel you are
booted to.
That just goes to show that
cat .config.in >> zImage
can yeild your dotconfig even if you don't remember what kernel you booted.
There are exceptions, but if you can't keep track of your kernel thats
pretty bad.
-B
--
Barrett G. Lyon PGP: www.netpr.com/pgpkeys
Data & Network Security Consultant Fax: 310-737-0196
Network Presence, LLC Email: bl...@netpr.com
--
-
Peter T. Breuer
>
> can yeild your dotconfig even if you don't remember what kernel you booted.
> There are exceptions, but if you can't keep track of your kernel thats
> pretty bad.
No it isn't, it's normal. I don't for one single second believe that
you have the .config of the 4th kernel that you installed on the machine
in the first room on the third corridor of the second level of the
building over the road two years ago.
Natch, YOU put it on the machine, but since then they've had a few
system crashes, and they've tried a few things, and anyway, your kernel
is the only one that's ever worked on their adaptec bus with the hp
surestore that can't be terminated actively without killing the machine,
and they'd _really_ like to know what the magic combo you used to
compile it with is.
Get real.
Peter
G.W. Wettstein
} Subject: Re: Building .config into the kernel
> > Right: that's quite a few positive replies regarding something like
> > /proc/config.gz.
> >
> > Anyone prepared to argue against it?
> Yes. Because the
>
> cat .config.in >> zImage
>
> suggestion is even better. It takes no kernel memory and you can yank it off
> the image trivially
This should be a non-issue in my opinion. My team runs a bunch of
production Linux servers at my university job. Here is rpm output
from one of our servers:
rpm -qa:
Base-1.3-4
Kernel-2.0.35-3
Networking-1.0-24
Kerberos-1.0.5-5
Kernel_Static-2.0.36-1
rpm -q Kernel_Static -l:
/boot
/boot/vm2.0.36-1
/boot/vm2.0.36-1.config
/boot/vm2.0.36-1.map
Kernels don't get installed unless they are packed like above. This
doesn't have the advantage of the information being physically stuck
but I'm not sure if I see the advantage to that.
Greg
}-- End of excerpt from Alan Cox
As always,
Dr. G.W. Wettstein Enjellic Systems Development - Specialists in
4206 N. 19th Ave. intranet based enterprise information solutions.
Fargo, ND 58102
Phone: 701-281-1686 EMAIL: gr...@wind.enjellic.com
------------------------------------------------------------------------------
"One of the reporters asked if the could "see" the INTERNET worm.
They tried to explain that it wasn't something that you could actually
see but is was merely a program that was running in the background.
One of the reporters asked, 'What if you had a color monitor?'"
-- UNKNOWN
Barrett G. Lyon
>>
>> during compile time
>> cat .config.in >> zImage
>
>That's the problem. Imagine giving the instructions over the phone, blind
>(and in a foreign language, as I often do, to someone with a regional accent
>who thinks _you_ speak funny, and who usually turns the lights on and
>off). Whereas the stuff in proc would be a tease.
That sends shivers down my spine.. I agree it would not be fun to need to
track down a kernel image with someone that is clueless. New
administrators dont't really seem to follow traditional kernel naming
schemes either, this would contriubte to the ease of finding a old image.
Cheers,
-Barrett
--
Barrett G. Lyon PGP: www.netpr.com/pgpkeys
Data & Network Security Consultant Fax: 310-737-0196
Network Presence, LLC Email: bl...@netpr.com
--
-
Peter T. Breuer
I don't have the image. It's booted from a floppy (or by nfs, thanks to their
triple secure fallback). I gave it to them. They put it on a floppy. I don't
have the floppy. They don't know which floppy it is (the servers been up for a
while). The floppy's not in the drive. I may not be in the same
country. It may be midnight there. Next? Here's something for you to
look at.
Last login: Sat Jan 2 10:20:24 from csc003.csx.cam.a
Linux 1.2.13.
erasmus:~> uptime
11:58pm up 93 days, 8:03, 2 users, load average: 0.08, 0.02, 0.01
(and yes, I did have to telnet a thousand miles to do that).
> running and then get the config info out of that image. I'm not saying to
> archive your .config's.
Now imagine "zcat /proc/config.gz, aaaahhh".
Peter
Brandon S. Allbery KF8NH
+-----
| Natch, YOU put it on the machine, but since then they've had a few
| system crashes, and they've tried a few things, and anyway, your kernel
| is the only one that's ever worked on their adaptec bus with the hp
| surestore that can't be terminated actively without killing the machine,
| and they'd _really_ like to know what the magic combo you used to
| compile it with is.
In a sense, that's a counterargument: what if the magic combo was a bit of
code hackery? (Suggestions to embed the full kernel source code in the
image will be laughed out of court...!)
--
brandon s. allbery [os/2][linux][solaris][japh] all...@kf8nh.apk.net
system administrator [WAY too many hats] all...@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
We are Linux. Resistance is an indication that you missed the point.
Brandon S. Allbery KF8NH
+-----
| On Jan 14, 7:09pm, Alan Cox wrote:
| } Subject: Re: Building .config into the kernel
|
| > > Right: that's quite a few positive replies regarding something like
| > > /proc/config.gz.
| > >
| > > Anyone prepared to argue against it?
|
| > Yes. Because the
| >
| > cat .config.in >> zImage
| >
| > suggestion is even better. It takes no kernel memory and you can yank it of
| f
| > the image trivially
|
| This should be a non-issue in my opinion. My team runs a bunch of
| production Linux servers at my university job. Here is rpm output
| from one of our servers:
The situation at *this* university is a little different. The machine I was
working on this afternoon is a case in point: the grad student who normally
uses the machine put 2.1.131 on it, and I have very little idea of how it
was configured. And there's no way the LCS grad students are going to RPM
their kernels....
Peter T. Breuer
BTW, that IS a very good idea and It Should Be Done By Make. It's good
enough for 90% of the cases I can imagine, _provided_ that you can
identify the image, i.e. that the lilo/whatever config hasn't changed.
That's the problem. Imagine giving the instructions over the phone, blind
(and in a foreign language, as I often do, to someone with a regional accent
who thinks _you_ speak funny, and who usually turns the lights on and
off). Whereas the stuff in proc would be a tease.
Peter
Henrik Olsen
> > Right: that's quite a few positive replies regarding something like
> > /proc/config.gz.
> >
> > Anyone prepared to argue against it?
>
> Yes. Because the
>
> cat .config.in >> zImage
>
> suggestion is even better. It takes no kernel memory and you can yank it off
> the image trivially
And it should be fairly simple to make a /proc/config do the yanking if
it's there if you really want it in /proc :)
--
Henrik Olsen, Dawn Solutions I/S
URL=http://www.iaeste.dk/~henrik/
Get the rest there.
Nicholas J. Leon
# This should be a non-issue in my opinion. My team runs a bunch of
#
# Kernels don't get installed unless they are packed like above. This
# doesn't have the advantage of the information being physically stuck
# but I'm not sure if I see the advantage to that.
And if you don't run a distribution that keeps information about installed
package? What about that scenerio?
G'day!
-- n i c h o l a s j l e o n
elegance through simplicity*http://mrnick.binary9.net*nich...@binary9.net
good fortune through truth*roaming:nj...@email.msn.com*ICQ#2170994*U+($++)
TRA#6805*not all questions have answers*pseudogeek:P+++($++)L+($++)W=lm@b9
trust no-one with an iq under 150*understand yourself before trying others
David Lang
as a "new user" (Only using Linux at work from 2.0.0 on, at home from
0.99?? ) what is this traditional naming scheme
David Lang
"If users are made to understand that the system administrator's job is to
make computers run, and not to make them happy, they can, in fact, be made
happy most of the time. If users are allowed to believe that the system
administrator's job is to make them happy, they can, in fact, never be made
happy."
- -Paul Evans (as quoted by Barb Dijker in "Managing Support Staff", LISA '97)
On Wed, 13 Jan 1999, Barrett G. Lyon wrote:
> Date: Wed, 13 Jan 1999 17:34:28 -0600
> From: Barrett G. Lyon <bl...@netpr.com>
> To: p...@it.uc3m.es
> Cc: linux-...@vger.rutgers.edu
> Subject: Re: Building .config into the kernel
>
> >"Barrett G. Lyon wrote:"
> >>
> >> during compile time
> >> cat .config.in >> zImage
> >
> >That's the problem. Imagine giving the instructions over the phone, blind
> >(and in a foreign language, as I often do, to someone with a regional accent
> >who thinks _you_ speak funny, and who usually turns the lights on and
> >off). Whereas the stuff in proc would be a tease.
>
> That sends shivers down my spine.. I agree it would not be fun to need to
> track down a kernel image with someone that is clueless. New
> administrators dont't really seem to follow traditional kernel naming
> schemes either, this would contriubte to the ease of finding a old image.
>
> Cheers,
>
> -Barrett
>
>
>
>
> --
> Barrett G. Lyon PGP: www.netpr.com/pgpkeys
> Data & Network Security Consultant Fax: 310-737-0196
> Network Presence, LLC Email: bl...@netpr.com
> --
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majo...@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQEVAwUBNp6tnj7msCGEppcbAQHdQwgAoLy8tZATfQhJh3Eq+NpnQFh9+0KpqklC
lIyadz70pKYL7qWEWQi4oIihhmItVJ8P7lYDHKF+UiGJjczDUyqTSCSwXPJyr6tc
s1g7TRURNT4kdiCYx1AhjKlavxMb4vAqCpvo2VrAVi9Pqy2oiq3ALZLV6TmiR+gO
IqJqDQwHVdg/6Y/CMTsskEnYgKmevCSp5K90FqYccnx8G/SyMADdzjkX1Vb/egT5
5qXv1xrB0fRf7TUmynsI9N+SECedJ3bJf49wKebQKQsWhP8ejbJhiAGydkZXMqlM
cEWQrKCgewhrDFO01dite83WPmr/TTQSSUbe/+p7a6mfkuRgUmxzvA==
=HCWe
-----END PGP SIGNATURE-----
Marty Leisner
> kernel. Like a lot of us, I build my own kernels, etc. But I'm continually
> tinkering with it. Maybe I built it without masquerade support because I
> wasn't using it at the time (or because it was 2.2.0-pre5 to use a recent
> example, and it didn't build with masquerade enabled). Particularly as you go
> to earlier kernels that I've saved in my /boot partition. Lets see, I have 8
> different versions in there right now, along with a tar'ved version of the
> appropriate modules directory that I can untar in a flash if need be, and I
> have 2-3 floppies sitting around the office with a kernel, lilo, and the tar'ed
> and gzip'ed module directory for fast booting.
>
> My personal vote would be to have a sed script eliminate all of the 'no'
> answers in the .config file and the 'CONFIG_' prefix, convert it into a large
> string, compile it, and then print it out in /proc/version after the version #
> line (and of course break a whole new round of badly written /proc munging
> programs, but that seems to be a Linux tradition).
>
> Michael Meissner, Cygnus Solutions (Massachusetts office)
> 4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
> meis...@cygnus.com, 617-354-5416 (office), 617-354-7161 (fax)
>
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majo...@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
I find it maddening when you aren't sure what is in your kernel (and have to
build a new kernel to make sure).
Instead of /proc/version, have /proc/configuration as an option...
Marty Leisner
Matthew Wilcox
Brandon S. Allbery KF8NH wrote
> In a sense, that's a counterargument: what if the magic combo was a bit of
> code hackery? (Suggestions to embed the full kernel source code in the
> image will be laughed out of court...!)
http://www.ebi.ac.uk/~mdw/quine-1.1.tar.gz
Alain Williams
> It's ridiculous not to waste 4k of space on a list of config options in
> memory on 256MB servers holding up 30 client machines. It saves time and
> avoids confusion. It helps bug reporting too .. telephone conversation:
> "is your kernel configured for firewalling? .. I don't know! .. please
> zcat /proc/config.gz | mail me@here please .."
I agree. However, if someone *really* hasn't got the 4K to spare why not
make this a configuration option, ie allow /proc/config.gz to be
compiled out of the kernel. Like that everyone will be kept happy.
I suspect that most distributions will compile it in as it makes support
easier.
--
Alain Williams
Olaf Titz
> code hackery? (Suggestions to embed the full kernel source code in the
> image will be laughed out of court...!)
But then it helps greatly to have a patch identifier somewhere.
Like /proc/patches or the uname thing.
Olaf
Nimrod Zimerman
> Why all this palaver? It doesn't matter if you can figure out the image.
> I could probably do it by diffing symbols. The point is that it's not
> easy and it is silly. Just put the config options in /proc where we can all
> see them. I couldn't care less about 4k ram from a 256MB server. I couldn't
> even care in an 8MB machine (and I _have_ an 8MB machine).
And make this a compile-time option ('Y' by default), and you wouldn't even
have to care if you are on a 4MB machine.
On a 16mb machine - I support this. I currently have a bunch of kernels in
my /kernels directory, going back as old as 2.0.34 (some have cute names
like '2_0_34.ms' - it probably was on a FAT once - that I can only guess
what is).
I think that if inclusion of .config is going to make it into the kernel,
supporting some way of figuring what patches are applied is a very good
idea too. As others have said, the concept of a 'patches' directory that
gets listed somewhere when compiling is a good thing. I had something like
that for a while in the 2.0 series, and it worked quite well. It is a very
simple patch.
Regardless of code-forking and the like, sometimes people have to patch up
the kernel for specific needs - why not make their lives easier? I, for
example, patch my kernel to support writing Hebrew right-to-left (in
some extremely horrifying way I implemented back in 2.0 - it should never go
into the kernel. It should probably never leave my machine, too), and I
have a one-liner that fixes a problem I have with umsdos. I see nothing
wrong with me applying these two patches, but sometimes I don't apply
them for various reasons - and it is important for me to tell whether
they were applied or not.
All in all, it costs no money to support these two things if you don't want
them, the number of source lines it adds is a fraction to what is added
between every two patches, and implementing it is simple.
So I cry along with you - why not?
Nimrod
Nimrod Zimerman
> | Natch, YOU put it on the machine, but since then they've had a few
> | system crashes, and they've tried a few things, and anyway, your kernel
> | is the only one that's ever worked on their adaptec bus with the hp
> | surestore that can't be terminated actively without killing the machine,
> | and they'd _really_ like to know what the magic combo you used to
> | compile it with is.
>
> In a sense, that's a counterargument: what if the magic combo was a bit of
> code hackery? (Suggestions to embed the full kernel source code in the
> image will be laughed out of court...!)
Ah, that's where you get the 'listing the patches' bit advantage (and yes, I
think the two are pretty much related).
Obviously, people will have to be careful and actually *list* them (even if
all they say is 'adaptec-magic, 97/4/2'). At least you would know
this isn't the standard kernel. Knowing that, you've just saved yourself a
whole afternoon of compile-reboot-test cycles.
I typically patch little bits and pieces of my kernel. Currently, the only
way I can list these (without introducing yet another kernel
change) is to change the version string. I used to do that manually when
applying pre-patces and ac patches, for example.
However, this isn't a really good solution, as changing this causes a
recompilation of most of the kernel (if not all). And I'm on a 486 - it
takes an hour and 15 minutes to compile a kernel from scratch.
Being able to put a file somewhere, named 'ip-masq.patch', that has the line
'ip-masq fix (adding symbol to netsyms.c) - ac4 has it broken', and having
this line appear under /proc/patches - can make my life far easier. It can
cost nothing to those who don't want it.
Chris Adams
>> It's often a hard fight to find which server booted what kernel from
>> where and whether it still has it even for a _good_ admin. There isn't
>> room for more than one or two good admins per institute. The rest will
>
>with the production boxes around here. Now just where did that 1.2.13lmp
>kernel tree go ..
What I would like to see is a generic way for stuff to be included in
the kernel image and loaded at boot time, but then saved out somewhere
and discarded from kernel memory. Or make some kernel memory swapable.
This could be used for adding configuration info easily.
It could also be used to keep the modules for a kernel with that kernel
image. The modules could be tacked on the end of the image after it is
compiled. Then that memory could be made swapable, or be readable
through a special interface. A user mode program could read the modules
and write them to the disk and then tell the kernel it can discard them.
With a boot-time command line option to the kernel to just toss those
sections, this wouldn't take extra memory.
The System.map file could also be appended in the same way.
I think a general method to add things to the kernel image and get them
back after booting that image would be useful for many different things.
--
Chris Adams - cad...@ro.com
System Administrator - Renaissance Internet Services
I don't speak for anybody but myself - that's enough trouble.
G.W. Wettstein
} Subject: Re: Building .config into the kernel
> The situation at *this* university is a little different. The
> machine I was working on this afternoon is a case in point: the grad
> student who normally uses the machine put 2.1.131 on it, and I have
> very little idea of how it was configured. And there's no way the
> LCS grad students are going to RPM their kernels....
I probably operate out of a different set of assumptions than most
people do. If I am responsible for picking up the pieces of a broken
machine things get done my way on the machine. We have gone round and
round with departments and the like about this issue. If people want
to have the liberty of replacing kernels and rebooting machines they
get to administrate their own machines, problems and all.
> brandon s. allbery [os/2][linux][solaris][japh] all...@kf8nh.apk.net
Greg
}-- End of excerpt from "Brandon S. Allbery KF8NH"
As always,
Dr. G.W. Wettstein Enjellic Systems Development - Specialists in
4206 N. 19th Ave. intranet based enterprise information solutions.
Fargo, ND 58102
Phone: 701-281-1686 EMAIL: gr...@wind.enjellic.com
------------------------------------------------------------------------------
"POSIX semantics? Across a system crash? What POSIX standards are you
referring to?"
-- Linus Torvalds
comp.os.linux.development.system
G.W. Wettstein
} Subject: Re: Building .config into the kernel
> On Thu, 14 Jan 1999, G.W. Wettstein wrote:
>
> # This should be a non-issue in my opinion. My team runs a bunch of
> #
> # Kernels don't get installed unless they are packed like above. This
> # doesn't have the advantage of the information being physically stuck
> # but I'm not sure if I see the advantage to that.
> And if you don't run a distribution that keeps information about installed
> package? What about that scenerio?
I responded back to Brandon a few minutes ago on this issue. I think
that this is the domain of proper system's administration. I happen
to use rpm for our Enjellic Server Distribution. There is nothing
that stops anyone from making sure that a reasonable nameing
convention gets used and that things important to figuring out what
wrong follow this convention.
> G'day!
> -- n i c h o l a s j l e o n
Greg
}-- End of excerpt from "Nicholas J. Leon"
As always,
Dr. G.W. Wettstein Enjellic Systems Development - Specialists in
4206 N. 19th Ave. intranet based enterprise information solutions.
Fargo, ND 58102
Phone: 701-281-1686 EMAIL: gr...@wind.enjellic.com
------------------------------------------------------------------------------
"Samba was detected as "Samba" by WinNT 4.0 Workstation and PageMaker 6.5
was slow like hell. Now I managed to have it detected as "WinNT 4.1 Server"
and it's much faster."
-- (Ein Schelm, wer Boeses dabei denkt)
Brandon S. Allbery KF8NH
| > machine I was working on this afternoon is a case in point: the grad
| > student who normally uses the machine put 2.1.131 on it, and I have
| > very little idea of how it was configured. And there's no way the
| > LCS grad students are going to RPM their kernels....
|
| I probably operate out of a different set of assumptions than most
| people do. If I am responsible for picking up the pieces of a broken
| machine things get done my way on the machine. We have gone round and
| round with departments and the like about this issue. If people want
| to have the liberty of replacing kernels and rebooting machines they
| get to administrate their own machines, problems and all.
Nice in theory --- but.
The primary rule here is: if it's on our network, WE run it. CMU's a top
target for hackers; we can't afford to have sitting targets outside our
control on our network. (SCS doesn't use that rule... and they appear to
have a *serious* hacker problem, one which occasionally leaks into ECE. But
the concerns below apply even more so for them --- after all, we've only LCS
doing kernel munging, whereas for them it's quite normal.)
Unfortunately, that doesn't quite work with LCS, as they *need* to be able
to boot experimental kernels and the like. These folks spend most of their
time playing with derivatives of the MIT exokernel; they use 2.1/2.2pre on
non-exokernel machines because it gives them more options for testing and
experimenting with the TCP/IP stacks on the exokernel machines.
A separate network has been considered. They've rejected it so far... or
rather, so far they haven't decided what they want a separate network to
handle and what if any outside access they want to allow. And the
development machines pretty much *have* to have access to both ECE's and
SCS's AFS servers... and masquerading for AFS clients is a royal pain; it
looks like I'd have to permanently allocate a block of ports on the
masquerade server and permanently map them to ports 7000-7003/udp (at least)
on the clients. (The AFS servers have long memories as to which ports the
clients are using. I wish rx had a TCP option....)
I'm not in a position to work on 2.1/2.2pre support for them, beyond trying
to make sure things don't break too badly, i.e. fixing the 2.2-unfriendly
warts in Red Hat 5.2 (/etc/rc.d/init.d/kerneld, util-linux-2.8, etc.) and
trying to get a stable enough Arla configuration that they can at least try
to work in the heavily AFS-oriented CMU environment. And I can't build
"approved" 2.1/2.2pre kernels for them because they might well be patching
them (and regularly revising the patches) to support torture of exokernels
:-) (And no, I'm don't claim to be smart enough to keep up with these grad
students. As if I haven't made that obvious regularly on this list :-)
So a decent way to recover the configuration of a running kernel would be a
great help around here.
--
brandon s. allbery [os/2][linux][solaris][japh] all...@kf8nh.apk.net
system administrator [WAY too many hats] all...@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
We are Linux. Resistance is an indication that you missed the point.
-
Bill Heagy
storing a (2-byte?) hash of .config and System.map and whatever else is
needed, in the kernel, so you can at least tell when you have the right
combination. Then you can leave the archiving problem outside the kernel.
The hash could be logged, etc. and the kernel debugging stuff could check
that you're dealing with a consistent set of files.
---
Bill Heagy mailto:whe...@odyssey.on.ca
1006 - 1 Grosvenor Street http://www.odyssey.on.ca/~wheagy
London, Ontario N6A 1Y2 phone (519)663-9180
Canada