-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
On May 7, 2010, at 3:39 PM, Mindaugas Rasiukevicius wrote:
Michael <macal...@netbsd.org> 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-----
