Skip to contentSkip to conversation

/proc/sys/kernel/bootloader_type

PATCH In review H. Peter Anvin 6 participants 8 messages Dec 30, 2004 – Jan 2, 2005 Proc sysctl

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 /proc/sys/kernel/bootloader_type

This patch exports to userspace the boot loader ID which has been exported by (b)zImage boot loaders since boot protocol version 2.

Tested on i386 and x86-64; as far as I know those are the only architectures which use zImage/bzImage format.

-hpa

Index: linux-2.5/arch/i386/Makefile
===================================================================
RCS file: /home/hpa/kernel/bkcvs/linux-2.5/arch/i386/Makefile,v retrieving revision 1.73

arch/i386/Makefile +4 -0
diff -u -r1.73 Makefile
@@ -20,6 +20,10 @@
 LDFLAGS_vmlinux :=
 CHECKFLAGS	+= -D__i386__
 
+# This allows compilation with an x86-64 compiler
+CC_M32		:= $(call cc-option,-m32)
+CC 		+= $(CC_M32)
+
 CFLAGS += -pipe -msoft-float
 
 # prevent gcc from keeping the stack 16 byte aligned

Index: linux-2.5/arch/i386/kernel/setup.c
===================================================================
RCS file: /home/hpa/kernel/bkcvs/linux-2.5/arch/i386/kernel/setup.c,v retrieving revision 1.128

arch/i386/kernel/setup.c +4 -0
diff -u -r1.128 setup.c
@@ -97,6 +97,9 @@
 /* For PCI or other memory-mapped resources */
 unsigned long pci_mem_start = 0x10000000;
 
+/* Boot loader ID as an integer, for the benefit of proc_dointvec */
+int bootloader_type;
+
 /* user-defined highmem size */
 static unsigned int highmem_pages = -1;
 
@@ -1338,6 +1341,7 @@
 		BIOS_revision = SYS_DESC_TABLE.table[2];
 	}
 	aux_device_present = AUX_DEVICE_INFO;
+	bootloader_type = LOADER_TYPE;
 
 #ifdef CONFIG_BLK_DEV_RAM
 	rd_image_start = RAMDISK_FLAGS & RAMDISK_IMAGE_START_MASK;

Index: linux-2.5/arch/x86_64/kernel/setup.c
===================================================================
RCS file: /home/hpa/kernel/bkcvs/linux-2.5/arch/x86_64/kernel/setup.c,v retrieving revision 1.59

arch/x86_64/kernel/setup.c +4 -0
diff -u -r1.59 setup.c
@@ -78,6 +78,9 @@
 /* For PCI or other memory-mapped resources */
 unsigned long pci_mem_start = 0x10000000;
 
+/* Boot loader ID as an integer, for the benefit of proc_dointvec */
+int bootloader_type;
+
 unsigned long saved_video_mode;
 
 #ifdef CONFIG_SWIOTLB
@@ -452,6 +455,7 @@
 	edid_info = EDID_INFO;
 	aux_device_present = AUX_DEVICE_INFO;
 	saved_video_mode = SAVED_VIDEO_MODE;
+	bootloader_type = LOADER_TYPE;
 
 #ifdef CONFIG_BLK_DEV_RAM
 	rd_image_start = RAMDISK_FLAGS & RAMDISK_IMAGE_START_MASK;

Index: linux-2.5/include/asm-i386/processor.h
===================================================================
RCS file: /home/hpa/kernel/bkcvs/linux-2.5/include/asm-i386/processor.h,v retrieving revision 1.78

include/asm-i386/processor.h +3 -0
diff -u -r1.78 processor.h
@@ -283,6 +283,9 @@
 extern unsigned int BIOS_revision;
 extern unsigned int mca_pentium_flag;
 
+/* Boot loader type from the setup header */
+extern int bootloader_type;
+
 /*
  * User space process size: 3GB (default).
  */

Index: linux-2.5/include/asm-x86_64/processor.h
===================================================================
RCS file: /home/hpa/kernel/bkcvs/linux-2.5/include/asm-x86_64/processor.h,v retrieving revision 1.48

include/asm-x86_64/processor.h +2 -0
diff -u -r1.48 processor.h
@@ -456,5 +456,7 @@
 #define cache_line_size() (boot_cpu_data.x86_cache_alignment)
 
 extern unsigned long boot_option_idle_override;
+/* Boot loader type from the setup header */
+extern int bootloader_type;
 
 #endif /* __ASM_X86_64_PROCESSOR_H */

Index: linux-2.5/include/linux/sysctl.h
===================================================================
RCS file: /home/hpa/kernel/bkcvs/linux-2.5/include/linux/sysctl.h,v retrieving revision 1.82

include/linux/sysctl.h +1 -0
diff -u -r1.82 sysctl.h
@@ -134,6 +134,7 @@
 	KERN_SPARC_SCONS_PWROFF=64, /* int: serial console power-off halt */
 	KERN_HZ_TIMER=65,	/* int: hz timer on or off */
 	KERN_UNKNOWN_NMI_PANIC=66, /* int: unknown nmi panic flag */
+	KERN_BOOTLOADER_TYPE=67, /* int: boot loader type */
 };
 
 

Index: linux-2.5/kernel/sysctl.c
===================================================================
RCS file: /home/hpa/kernel/bkcvs/linux-2.5/kernel/sysctl.c,v retrieving revision 1.96

kernel/sysctl.c +10 -0
diff -u -r1.96 sysctl.c
@@ -624,6 +624,16 @@
 		.proc_handler   = &proc_unknown_nmi_panic,
 	},
 #endif
+#if defined(CONFIG_X86)
+	{
+		.ctl_name	= KERN_BOOTLOADER_TYPE,
+		.procname	= "bootloader_type",
+		.data		= &bootloader_type,
+		.maxlen		= sizeof (int),
+		.mode		= 0444,
+		.proc_handler	= &proc_dointvec,
+	},
+#endif
 	{ .ctl_name = 0 }
 };
 
#1 lore raw
Quoted 3 lines · H. Peter Anvin

This patch exports to userspace the boot loader ID which has been
exported by (b)zImage boot loaders since boot protocol version 2.

Why does userspace need to know this?

Quoted 9 lines

--- linux-2.5/arch/i386/Makefile 24 Dec 2004 21:09:54 -0000 1.73
+++ linux-2.5/arch/i386/Makefile 28 Dec 2004 04:56:17 -0000
@@ -20,6 +20,10 @@
LDFLAGS_vmlinux :=
CHECKFLAGS += -D__i386__

+# This allows compilation with an x86-64 compiler
+CC_M32 := $(call cc-option,-m32)
+CC += $(CC_M32)

Was this hunk deliberately a part of this patch?

#2 lore raw
Quoted 6 lines · Andrew Morton
Quoted 3 lines · H. Peter Anvin

This patch exports to userspace the boot loader ID which has been
exported by (b)zImage boot loaders since boot protocol version 2.

Why does userspace need to know this?

so that update tools that update kernels from vendors know which bootloader file they need to update; eg right now those tools do all kinds of hairy heuristics to find out if it's grub or lilo or .. that installed the kernel. Those heuristics are fragile in the presence of more than one bootloader (which isn't that uncommon in OS upgrade situations).

#3 lore raw
Quoted 6 lines · Arjan van de Ven
Quoted 5 lines · Andrew Morton
Quoted 3 lines · H. Peter Anvin

This patch exports to userspace the boot loader ID which has been
exported by (b)zImage boot loaders since boot protocol version 2.

Quoted 9 lines
Quoted 1 line

Why does userspace need to know this?

so that update tools that update kernels from vendors know which bootloader file they need to update; eg right now those tools do all kinds of hairy heuristics to find out if it's grub or lilo or .. that installed the kernel. Those heuristics are fragile in the presence of more than one bootloader (which isn't that uncommon in OS upgrade situations).

This boot loader ID doesn't help much for system upgrade. The running kernel may boot from removable drive.

Signature · 2 lines
Coywolf Qi Hunt
Homepage http://sosdg.org/~coywolf/
#4 lore raw
Quoted 18 lines · Coywolf Qi Hunt
Quoted 6 lines · Arjan van de Ven
Quoted 5 lines · Andrew Morton
Quoted 3 lines · H. Peter Anvin

This patch exports to userspace the boot loader ID which has been
exported by (b)zImage boot loaders since boot protocol version 2.

Quoted 9 lines
Quoted 1 line

Why does userspace need to know this?

so that update tools that update kernels from vendors know which bootloader file they need to update; eg right now those tools do all kinds of hairy heuristics to find out if it's grub or lilo or .. that installed the kernel. Those heuristics are fragile in the presence of more than one bootloader (which isn't that uncommon in OS upgrade situations).

Quoted 2 lines

This boot loader ID doesn't help much for system upgrade. The running kernel may boot from removable drive.

but then it says syslinux or so...
means that the lilo-or-grub question still needs the heuristics, it's just that in the normal case, the bootloader type can help make the heuristics reliable.

#5 lore raw
In reply to Andrew Morton
Quoted 6 lines · Andrew Morton
Quoted 1 line · H. Peter Anvin

This patch exports to userspace the boot loader ID which has been exported by (b)zImage boot loaders since boot protocol version 2.

Why does userspace need to know this?

In order to try to figure out what the boot medium was. For some boot loaders, like grub, it could be more or less anything, but others, e.g. syslinux, knowing what the boot loader is lets you know what the medium was.

Quoted 7 lines
Quoted 7 lines
arch/i386/Makefile +0 -0
@@ -20,6 +20,10 @@
 LDFLAGS_vmlinux :=
 CHECKFLAGS	+= -D__i386__
 
Quoted 6 lines

arch/i386/Makefile line 25

Quoted 3 lines
arch/i386/Makefile +3 -0
+# This allows compilation with an x86-64 compiler
+CC_M32		:= $(call cc-option,-m32)
+CC 		+= $(CC_M32)

Was this hunk deliberately a part of this patch?

No, that was a separate patch I submitted several weeks ago which was apparently still in that tree. Would be good to get that patch into the tree, though; it allows an x86-64 setup to compile an i386 kernel with only make ARCH=i386.

-hpa

#6 lore raw
In reply to H. Peter Anvin
Quoted 3 lines · H. Peter Anvin <hpa <at> zytor.com> writes:

This patch exports to userspace the boot loader ID which has been exported by (b)zImage boot loaders since boot protocol version 2.

Isn't /sys/kernel/bootloader_type a better place than /proc for new values?

Thanks,
Kay

#7 lore raw
Quoted 11 lines · Kay Sievers
Quoted 1 line · H. Peter Anvin <hpa <at> zytor.com> writes:

This patch exports to userspace the boot loader ID which has been exported by (b)zImage boot loaders since boot protocol version 2.

Isn't /sys/kernel/bootloader_type a better place than /proc for new values?

Thanks,
Kay

In fact it's stored in /proc/sys/kernel/bootloader_type as sysctl does...