Re: allocating memory during kernel startup

[Michael <macallan%netbsd.org@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On May 7, 2010, at 3:39 PM, Mindaugas Rasiukevicius wrote:

> Michael <macallan%netbsd.org@localhost> wrote:
> > > > Any chance to just have kmem_alloc() immediately return NULL if it
> > > > isn't ready yet so we can fail gracefully instead of hanging?
> > >
> > > Such handling, i.e. in kmem(9), seems like a wrong approach to me.
> > >
> > > Caller can check the 'cold' variable, which is unset in  
> > > configure2().
> > > Although it does not clearly define what condition is "non-cold".
> >
> > We get out of cold WAY later than that. In fact kmem is ready before
> > autoconfig starts and cold is only cleared after that.
>
> Well, kmem(9) is initialised very early, just after pool(9), in  
> uvm_init(),
> where I moved it couple years ago.  Yes, 'cold' is unset very late.   
> Since
> allocation gets postponed anyway, is that a problem?  You did not  
> describe
> your use case. :)

In fact I did describe it in another mail.
And the problem is that macppc sets up its console extremely early. If  
I move consinit() after uvm_init() then debugging uvm_init() problems  
becomes a lot harder and as I said before, the parts that need uvm to  
be up and running are strictly optional, we only need to know wether  
we can use them or not.

have fun
Michael

> --
> Mindaugas

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBS+Rx6MpnzkX8Yg2nAQKrBQf/ZHfkuOxZNmJD+jp9rHP5GhkccjpewCLd
8YcrD3rLZDCCgkiEaOqMGhjyNrRZpuXmIW8kq+TbWf34rx1CuYrtjebFMb/DCAG9
J2b/ZFP9GPKb9bOubdEP2cW8xNmi6K6h/sSUAGJolYWXaSi3yaSJeuB4s6MT5f92
Z6J+QGJL37MZ1Sm5J/cm8Ai9O7NYumd7M+fGhLfC0meI75EfXDCXRB/Ay1Fzc5Dh
wnDLtXDDs/qAM3Fen2YjWGhhEU0TESuY0kBBRjGFtwSwEf2r6FS30VoYgZJKoVKs
GqF4X18GqyuudgHbs6o2POked4RumB65/byn4Y9QOnM0Xh/dghQDtg==
=sG6d
-----END PGP SIGNATURE-----