2.4: BUG_ON (2/2)
Subsystems (9)
PATCH 1/1 2.4: BUG_ON (2/2)
Marcelo,
This patch, which requires the previous BUG_ON part 1 patch, changes a few uses of BUG -> BUG_ON in fast paths in the kernel, partly to demonstrate readability, partly for the optimization, mostly to give a reason to take part 1. ;)
Patch is against 2.4.19-pre5, please apply.
Robert Love
arch/i386/kernel/smp.c +1 -2
@@ -301,8 +301,7 @@*/ static void inline leave_mm (unsigned long cpu) { -if (cpu_tlbstate[cpu].state ==TLBSTATE_OK ) -BUG (); +BUG_ON (cpu_tlbstate[cpu].state ==TLBSTATE_OK );clear_bit (cpu, &cpu_tlbstate[cpu].active_mm->cpu_vm_mask); }
kernel/exit.c +1 -1
@@ -316,7 +316,7 @@mm_release ();if (mm) {atomic_inc (&mm->mm_count); -if (mm != tsk->active_mm)BUG (); +BUG_ON (mm != tsk->active_mm);/* more a memory barrier than a real lock */ task_lock (tsk); tsk->mm =NULL ;
kernel/fork.c +1 -1
@@ -251,7 +251,7 @@*/ inline void __mmdrop (struct mm_struct *mm) { -if (mm == &init_mm)BUG (); +BUG_ON (mm == &init_mm);pgd_free (mm->pgd);destroy_context (mm);free_mm (mm);
kernel/sched.c +3 -3
@@ -556,7 +556,7 @@spin_lock_prefetch (&runqueue_lock); -if (!current->active_mm)BUG (); +BUG_ON (!current->active_mm); need_resched_back: prev = current; this_cpu = prev->processor;
@@ -675,12 +675,12 @@struct mm_struct *mm = next->mm;struct mm_struct *oldmm = prev->active_mm;if (!mm) { -if (next->active_mm)BUG (); +BUG_ON (next->active_mm); next->active_mm = oldmm;atomic_inc (&oldmm->mm_count);enter_lazy_tlb (oldmm, next, this_cpu); }else { -if (next->active_mm != mm)BUG (); +BUG_ON (next->active_mm != mm);switch_mm (oldmm, mm, next, this_cpu); }
mm/slab.c +1 -2
@@ -665,8 +665,7 @@* Always checks flags, a caller might be expecting debug * support which isn't available. */ -if (flags & ~CREATE_MASK ) -BUG (); +BUG_ON (flags & ~CREATE_MASK );/* Get cache's description obj. */ cachep = (kmem_cache_t *)kmem_cache_alloc (&cache_cache,SLAB_KERNEL );
mm/vmscan.c +3 -6
@@ -233,8 +233,7 @@ pgdir =pgd_offset (mm, address); end = vma->vm_end; -if (address >= end) -BUG (); +BUG_ON (address >= end); do { count = swap_out_pgd(mm, vma, pgdir, address, end, count, classzone); if (!count)
@@ -353,10 +352,8 @@ page = list_entry(entry, struct page, lru); -if (unlikely (!PageLRU (page))) -BUG (); -if (unlikely (PageActive (page))) -BUG (); +BUG_ON (!PageLRU (page)); +BUG_ON (PageActive (page));list_del (entry);list_add (entry, &inactive_list);
PATCH 1/1 2.4: BOOTPC /proc info.
Marcelo,
This patch is against 2.4.19-pre5, please apply.
The following change would primarily interest people using linux on
embedded boards, but should be usable by any system.
This patch creates one new entry in the proc filesystem. "/proc/net/bootpc" is now created and contains information if the kernel received a bootp packet during bootup. The output format is identical to the "bootpc" userspace program. On an embedded system, this can save 10-15 seconds from boot time (if running 'bootpc' as one of your init scripts). Also, this removes a possible point of failure during bootup.
We think this patch would be useful to put in the 2.4.x stream.
But there's no reason it can't also go in 2.5.x as well. We also have a 2.2.x version availble if there's any interest in that as well. So what do people think? Should this go in 2.4 or 2.5?
Is this worthwhile to pursue putting this in (it's very useful to us, so we figured others could use it)?
Should i send this to Linus for 2.5 inclusion as well?
Here's some sample output from the code:
bash-2.04$ cat /proc/net/bootpc
SERVER='10.40.4.101'
IPADDR='10.40.14.83'
BOOTFILE='/tftpboot/core_24work'
NETMASK='255.255.255.0'
GATEWAYS_1='10.40.14.1'
GATEWAYS='10.40.14.1'
YPDOMAIN='locoland'
HOSTNAME='somecard'
T129='configfile_1a'
NTPSRVS_1='10.40.4.101'
NTPSRVS='10.40.4.101'
Patch is below. Thanks.
--
Craig Arsenault.
+------------------------------------------------------+ http://www.wombat.ca Why? Why not. http://www.washington.edu/pine/ Pine @ the U of Wash. +-------------=*sent via Pine4.42*=--------------------+
Documentation/Configure.help +6 -0
@@ -5241,6 +5241,12 @@ want to use BOOTP, a BOOTP server must be operating on your network. Read <file:Documentation/nfsroot.txt> for details. +Provide bootpc style /proc file +CONFIG_IP_BOOTP_PROC + If you say Y here, the file /proc/net/bootpc will output the bootp + record retrieved at boot time in a format identical to the bootpc + client program. + DHCP support CONFIG_IP_PNP_DHCP If you want your Linux box to mount its whole root file system (the
net/ipv4/Config.in +3 -0
@@ -20,6 +20,9 @@ if [ "$CONFIG_IP_PNP" = "y" ]; then bool ' IP: DHCP support' CONFIG_IP_PNP_DHCP bool ' IP: BOOTP support' CONFIG_IP_PNP_BOOTP + if [ "$CONFIG_IP_PNP_BOOTP" = "y" ]; then + bool ' Provide bootpc style /proc file' CONFIG_IP_BOOTP_PROC + fi bool ' IP: RARP support' CONFIG_IP_PNP_RARP # not yet ready.. # bool ' IP: ARP support' CONFIG_IP_PNP_ARP
net/ipv4/ipconfig.c +429 -0
462 lines not on this page · raw message
Re: [PATCH] 2.4: BOOTPC /proc info.
Quoted 4 lines
So what do people think? Should this go in 2.4 or 2.5?
Is this worthwhile to pursue putting this in (it's very useful to us, so we figured others could use it)?
Should i send this to Linus for 2.5 inclusion as well?
The longer term goal is to remove this stuff from the kernel and push it into the initrd support. Instead of kernel hacks you use an initrd that runs the real bootpc.