Date: Wed, 13 Aug 1997 01:27:04 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: smp@csn.net (Steve Passe) Cc: msmith@atrad.adelaide.edu.au, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-sys@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern init_main.c Message-ID: <199708121557.BAA08791@genesis.atrad.adelaide.edu.au> In-Reply-To: <199708121549.JAA19349@Ilsa.StevesCafe.com> from Steve Passe at "Aug 12, 97 09:49:12 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Passe stands accused of saying: > Mike, > > > > Log: > > > Fixes kern/3835: SMP kernel crash on enable "dumps on wd0" > > > > > > - SMP: set value of curproc in main(), before the SYSINIT stuff > > > > If I read this correctly, this means that nothing hung off a SYSINIT() > > macro needs to worry about curproc being invalid, ie. one can > > explicitly expect curproc to be useful for subsystem locking etc. at a > > very early stage? > > no, its a hack to prevent code in configure() from panic()ing when trying > to dereference (struct proc*)p->xxx thingies. there is code that does this > early in the boot process that knows that curproc is incomplete and is careful > to not use the missing parts. There is nothing SMP specific about this. The > only reason its needed is that the UP kernel "sets" it at compile time via: Ok, perhaps I should be more explicit : - at what point is curproc filled out adequately for use with lockmgr() and friends? - if I don't know "when" I am, how can I work this out? -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708121557.BAA08791>