Purpose of #if 0 in boot code

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Purpose of #if 0 in boot code

Nick Gonella
Hey Misc,
As I read through the code, especially in the boot code, there
seem to be quite a few blocks of code of the style:

#if 0
/* some code here */
#endif

On example of this is in sys/arch/amd64/amd64/pmap.c:2326

#if 0
      pool_cache_invalidate(&pmap_pdp_cache);
#endif

Obviously, this code needs to be modified if we want it to be
included, but my question is, is this old, dead code, or is
there some reason it's still in the source?
Regards,
- Nick Gonella

Reply | Threaded
Open this post in threaded view
|

Re: Purpose of #if 0 in boot code

Alexander Hall
On Sat, Dec 31, 2016 at 05:03:18PM -0800, Nick Gonella wrote:

> Hey Misc,
> As I read through the code, especially in the boot code, there
> seem to be quite a few blocks of code of the style:
>
> #if 0
> /* some code here */
> #endif
>
> On example of this is in sys/arch/amd64/amd64/pmap.c:2326
>
> #if 0
>       pool_cache_invalidate(&pmap_pdp_cache);
> #endif
>
> Obviously, this code needs to be modified if we want it to be
> included, but my question is, is this old, dead code, or is
> there some reason it's still in the source?

Considering cvs history says it's been disabled since 2007 (the 2014
change by sf@ was whitespace removal), I'd say it's old and dead at
best, with very little probability of ever being used or useful again.

Maybe this will summon The Tedu to go on a stampede in there to finish
it off. ;-)

$ cvs blame pmap.c | grep -C1 pool_cache_invalidate  
Annotations for pmap.c
***************
1.72         (sf       24-Aug-14): #if 0
1.1          (mickey   28-Jan-04):              pool_cache_invalidate(&pmap_pdp_cache);
1.30         (tedu     09-Dec-07): #endif

$ cvs log -r1.30 pmap.c | sed '1,/---/d'
revision 1.30
date: 2007/12/09 00:24:04;  author: tedu;  state: Exp;  lines: +10 -9;
big patch to simplify pool code.

remove pool_cache code.  it was barely used, and quite complex.  it's
silly to have both a "fast" and "faster" allocation interface.  provide
a ctor/dtor interface, and convert the few cache users to use it.  no
caching at this time.

use mutexes to protect pools.  they should be initialized with pool_setipl
if the pool may be used in an interrupt context, without existing spl
protection.

ok art deraadt thib
=============================================================================

/Alexander


> Regards,
> - Nick Gonella