re: allocating memory during kernel startup
FWIW, i just noticed this in subr_extent.c. gross, but what you want :-) .mrg. #include uvm/uvm_extern.h #define KMEM_IS_RUNNING (kmem_map != NULL)
Re: allocating memory during kernel startup
I recently ran into this problem - there is no easy way to determine wether it is safe to call kmem_alloc() yet ( as in, are we far enough through startup ) and when we call it too early the whole thing just hangs. Any chance to just have kmem_alloc() immediately return NULL if it isn't ready yet so we can fail gracefully instead of hanging? I guess you need it on console initialization. Some ports have own flags that indicate malloc is safe for early bus_space(9) ops: sys/arch/arc/arc/machdep.c:cpu_startup() sys/arch/arc/arc/bus_space.c:arc_bus_space_extent_malloc_flag() etc. I have no idea if we should have a more generic flag. --- Izumi Tsutsui
Re: allocating memory during kernel startup
On Fri, May 07, 2010 at 11:19:58AM +0900, Masao Uebayashi wrote: On Thu, May 06, 2010 at 02:32:57PM -0400, Michael wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I recently ran into this problem - there is no easy way to determine wether it is safe to call kmem_alloc() yet ( as in, are we far enough through startup ) and when we call it too early the whole thing just hangs. We have no clear definition of the kernel state - what is boot, startup, and when it's done. Any chance to just have kmem_alloc() immediately return NULL if it isn't ready yet so we can fail gracefully instead of hanging? I like panic(). Even better, KASSERT(). I think that complicating memory allocation in bootstrap is not a good thing. What is your purpose? Right, on the face of it I don't see why this is something to be handled at runtime. Masao have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBS+MLWcpnzkX8Yg2nAQIQUAf/S9Sr9flxPytiLSIoQ9TqLx3NraBPKF0x SFQMVRnvHDR2imaexL1lab/tdrwmZcs1uUvmgdDravx8DfYEm6k7Y3rzr273T2b2 LuXQC5OxEL3ZRfhAYbWn06nEdDGoBDxlzz7bNT1TY7T7+6ZQeweyX51Ez89RM3us MpeDeLAAPWtXaSm5Yo1jf7j7Uz0cblENkUetxp2YvUPKIHGRLn1iz0Xn7bdYqdHN XaQi2WrE4Rsw8ee9se/NJdqFprsUaQLwRsSLGxm1FMYTho8IaOlX8i3z/tARMGpe 3cRfHzS7ARGyjlWXJTPm1TtcXa5+0S4v9RoqJrDowNC6r3699RkqUg== =AP9s -END PGP SIGNATURE- -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: allocating memory during kernel startup
On Fri, May 07, 2010 at 09:28:31AM +, Andrew Doran wrote: Right, on the face of it I don't see why this is something to be handled at runtime. Move consinit() past uvm_init() ;-} Martin
Re: allocating memory during kernel startup
Right, on the face of it I don't see why this is something to be handled at runtime. Move consinit() past uvm_init() ;-} Probably we should classify console devices and split consinit()? - dumb device working without VM (though we still have to consider about bus_space(9)) - complicated framebuffer with large memory - and others? (arc and ews4800mips set up wired map for framebuffer) --- Izumi Tsutsui
Re: allocating memory during kernel startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On May 7, 2010, at 5:54 AM, Izumi Tsutsui wrote: Right, on the face of it I don't see why this is something to be handled at runtime. Move consinit() past uvm_init() ;-} Probably we should classify console devices and split consinit()? - dumb device working without VM (though we still have to consider about bus_space(9)) - complicated framebuffer with large memory - and others? (arc and ews4800mips set up wired map for framebuffer) Well, the part I'm talking about can happily live without VM - it may want to use it however so it needs to know wether it can. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBS+Rmb8pnzkX8Yg2nAQLo7gf+L1gpis4r7M8ZyY8rEOPqzcATo6bgv3hS oHaA2uVdqAz58dfiOp5QgoVnUnUjKH5XT+haWDH+2/1bR9bj4avd5L+dzzRN0gAy Ko3pziLpG666yADrewlibAmiua8hf78vteeI1V3Gf6cz0mEu1mgqPkb3kwRYlFpY ho0fhYMlTYy8A4on2uDAcSYzy2mdfVcaEVjqkdfFmo8iBS9P+3KZB1h9WPA9AwIa 3kYYhs5OlJRg2cuYU6PF2nW7wXk3QBcr+Ct2+BRFmlXkLy97yuMLtcndt/UqeUOl B0fntKVDi219X2l2TpUDLRZcNT67HDtZMnJnEDj4z+pHATnaDwy2xQ== =j3aY -END PGP SIGNATURE-
Re: allocating memory during kernel startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On May 7, 2010, at 10:37 AM, Mindaugas Rasiukevicius wrote: Hello, Michael macal...@netbsd.org wrote: I recently ran into this problem - there is no easy way to determine wether it is safe to call kmem_alloc() yet ( as in, are we far enough through startup ) and when we call it too early the whole thing just hangs. 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. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBS+Rm68pnzkX8Yg2nAQKe5AgAuawn7E2sZscnUJA5JEOfqNQm/VSy5rnf z8V7+SUOjGyrys+5uaBe/hM9VWgc1vw6A/8e2nbzQGlES4dyVBr13IU8ZKTCKoFg nZwUEPXNToRY/WGWQQce6RcaGIoJKT/Pp5NIlAZ72o7dW1m/MUf7pS8QohD8sI/2 3ZC8bMGYjFCmmEWghjJO/HCjkPOVQzmaxKfwn+y5/hqGW1KccqK1gRs6yuKSWuit XHsm8qW0pb2KCc4RG3X9xDh5+vK2bULXTqEG5vfiUM3Ze3AIBP+DMs/BKBwpbI44 7Xei4FA9oePAphr9pAfS7zUbYZIgiOC7CM5f3aLDu+MdApkK5N0dKQ== =wSo/ -END PGP SIGNATURE-
Re: allocating memory during kernel startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On May 6, 2010, at 10:19 PM, Masao Uebayashi wrote: On Thu, May 06, 2010 at 02:32:57PM -0400, Michael wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I recently ran into this problem - there is no easy way to determine wether it is safe to call kmem_alloc() yet ( as in, are we far enough through startup ) and when we call it too early the whole thing just hangs. We have no clear definition of the kernel state - what is boot, startup, and when it's done. Yeah, we only have cold and that's not what I need. Any chance to just have kmem_alloc() immediately return NULL if it isn't ready yet so we can fail gracefully instead of hanging? I like panic(). I think that complicating memory allocation in bootstrap is not a good thing. What is your purpose? It's rasops_reconfig(). It may want to autogenerate box drawing characters, which needs to allocate memory, but it can happily live without them and some ports ( macppc for example ) setup a rasops- based console very early in the boot process. In this case rasops_reconfig() should simply skip the character generating process instead of something nasty like a panic to happen. Also, the man page suggests that kmem_alloc(KM_NOSLEEP) would return NULL if memory can't be allocated which would be the case. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBS+Rl5MpnzkX8Yg2nAQIc6gf8DbtjWUHxRRrjdMyVqZ1zC2uMfQrmCDi2 AdTzXDkXt1t8Ef08BiQi5sCx+Rwtm7bfPxM9UCvgJC6DRFBhkUa8mHjfM8c0u/RT ijz6oHi8LRBzdkC3bMAubBV/khHIHNjJWSD3vmgN3im6V9YCJkipfoGt+MSepqEA tB5g2NY3O8JxdQQEBe2FIy5PdICfc7BUTcn5wBIAITnm/Lmcr4JZQ+MhHtcLHz51 SX3WBLlyXYeJzUdXY6ZwexxOOSbzrQSCfYEQL0Mop9aTuOSl+4XHoffiZ3e09zdf Dz/W1YjMaRIEwnmMjQIwcEQCEgmNWWYiEt95Eg23kKnaj1F8gvQA/A== =9O6K -END PGP SIGNATURE-
Re: allocating memory during kernel startup
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. :) -- Mindaugas
Re: allocating memory during kernel startup
On Fri, May 07, 2010 at 08:39:51PM +0100, Mindaugas Rasiukevicius wrote: 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. :) consinit(), run just before uvm_init(). It may need to initialize raspos, which will allocate memory for fonts, screens, ... Martin
Re: allocating memory during kernel startup
Martin Husemann mar...@duskware.de wrote: 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. :) consinit(), run just before uvm_init(). It may need to initialize raspos, which will allocate memory for fonts, screens, ... OK, that is something I am not familiar with. Any reason why one could not have rasops_sysinit() after uvm_init()? I see consinit() as a bare minimum to printf() very early errors (which should not happen, normally). -- Mindaugas
Re: allocating memory during kernel startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On May 7, 2010, at 4:01 PM, Mindaugas Rasiukevicius wrote: Martin Husemann mar...@duskware.de wrote: 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. :) consinit(), run just before uvm_init(). It may need to initialize raspos, which will allocate memory for fonts, screens, ... OK, that is something I am not familiar with. Any reason why one could not have rasops_sysinit() after uvm_init()? If anything goes wrong in uvm_init() you don't see any output. I see consinit() as a bare minimum to printf() very early errors (which should not happen, normally). Exactly, the parts that need uvm are strictly optional - not needed at all for basic kernel output. We only need to know if we can use them or not. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBS+Ry/MpnzkX8Yg2nAQLrgQf+NvuRy4jaQCCCkNeWlIvk1rAn0gJdNnTg XzUZHkUWKWWuXha8kX8cefRff07s2eE9M7re3uaBsQT4DUG/qks5/DltmR19NcvP QDJHhCM9sZhAlmXge/eRp7fFbuyuraCdPDos+0nJ/sBN+1790Gb4/2Bqb1iQsLuZ bsdeV5fHwTduL2kZHDts6LvSwVr1j1C6nnbj7T1JrDRhpiF45KMki+8GXYkglhww lY0qffrmHI6ORPuusQE8DXDD+rdwl1NhSBDH8YbyftHbDr7r2YnVmRBH/livZd0F ibWOUe3eJKt/XxkGDgEFJditn/URkysulU6YTfbxRVTMtEY4YTWEZg== =YbXx -END PGP SIGNATURE-
Re: allocating memory during kernel startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On May 7, 2010, at 3:45 PM, Martin Husemann wrote: On Fri, May 07, 2010 at 08:39:51PM +0100, Mindaugas Rasiukevicius wrote: 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. :) consinit(), run just before uvm_init(). It may need to initialize raspos, which will allocate memory for fonts, screens, ... It doesn't allocate any screens ( that's wsdisplay, not rasops ), only some memory for box drawing characters which are strictly optional - it can live happily without them and its not like we need them for kernel output anyway. All it needs is a sane way to decide wether it can allocate memory or not. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBS+RyispnzkX8Yg2nAQI2eAf8C1THaTziezZwl5aIoZrs0Wtljh+OZ0Ms igoGuYs1AwfIiqNCdrGerwRAO3QYvOq7mT1QDkOyL5hWWfWrpfU180S/p4kshni2 GUKB5D7UklTw544A9P9G7utyHt9mPE36rxbKy959jeNi0MZFSQ2BogZcOKMnf1lK aZ801gLIBM1Sbfy3cc6Xhnqh6TojeHxmh30095lXgJMcBF/GiHGw1G/Qd/fhkGbv CY5rg5hdQFXRQAMsqYp/WKtxM91Othyb92XN83+duUvqNpgGmeKyWpeUKu/f+CyI enD/9nqt2WT6IIDmcKXT5//Br/XLlq+YIod2sftxPtOG8/lsfPbFkA== =iA/O -END PGP SIGNATURE-
Re: allocating memory during kernel startup
macal...@netbsd.org said: the parts that need uvm are strictly optional - not needed at all for basic kernel output. We only need to know if we can use them or not. So as Martin said: if called from consinit(), static memory should be used. At autoconf time and later, *alloc is OK. If we can get away with that simple scheme, we shouldn't complicate things needlessly. (which means that it might make sense to carry a flag around if some helper function can be called in both contexts) best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: allocating memory during kernel startup
On Fri, May 07, 2010 at 03:11:32PM -0400, Michael wrote: It's rasops_reconfig(). It may want to autogenerate box drawing characters, which needs to allocate memory, but it can happily live without them and some ports ( macppc for example ) setup a rasops- based console very early in the boot process. In this case rasops_reconfig() should simply skip the character generating process instead of something nasty like a panic to happen. How much memory are talking about? If it is small, don't bother. If it makes the difference between reaching init or not, you won't have much fun with the system later anyway. If it is large, consider doing it later e.g. when wscons is initialised and recompute until then. Pretty much all cases of alloc may fail here are either due to being in interrupt context or due to explicit limits in place (mbufs) or due to missing limits. Most if not all allocations by drivers etc should be sleeping and never allowed to fail. Some dead lock detection for before init is started might be nice, but there isn't really a sane error handling way. Joerg
Re: allocating memory during kernel startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On May 7, 2010, at 3:21 PM, Martin Husemann wrote: On Fri, May 07, 2010 at 03:15:55PM -0400, Michael wrote: We get out of cold WAY later than that. In fact kmem is ready before autoconfig starts and cold is only cleared after that. Realistically, besides all the problems we already solved by rearranging intializiation order, it is only consinit(). So you just need to take care what you call from there (and maybe pass some flags). I took the pass-some-flag approach for now but I don't really like it. Maybe rasops can do minimal configuration early and complete at driver attach time? It needs to know that it's doing a minimal attach if there is no way for itself to know wether it can do the real thing ( which leads us back to pass-some-flag ) have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBS+RxHcpnzkX8Yg2nAQIrpwf+MDG56QagKBKBaeRawC4nufG//1KSXjnL MlBTJJll3Riyd4vI7wU6fwHcYIFadFGNgK+dnjHk49mtU0iL28PXoUFkfSRg9CmS 1Mrn2J8OrePaHNyxZthBWhKn2xPxNYbpONlfJyqgRoqiegjqVJ/4QEuTziAT0erC WhhK8YBJZsKd+E83oo9fg6n73T3II/fhbxBOtYChTaemc04fYayWPDzsRCV9qll2 o3JX/jUn8R0CcIyoMR8dNaMvGfh5Q3M+ThZt0JC95t1xGQgcXVzYpyisY7AXD2sE xhtM27HejB1PDxfm9d+mCoIzmlI9yftYcS27AvJ57YOAzSHlofmLTA== =L/dI -END PGP SIGNATURE-
Re: allocating memory during kernel startup
On Fri, May 07, 2010 at 04:05:30PM -0400, Michael wrote: kernel output anyway. All it needs is a sane way to decide wether it can allocate memory or not. So split init in a minimal (optional) version called from the consinit functions, and a full grown init called at driver attach time (and have the latter skip the parts already done by the first if it ran already). Martin
Re: allocating memory during kernel startup
-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-
Re: allocating memory during kernel startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On May 7, 2010, at 4:26 PM, Martin Husemann wrote: On Fri, May 07, 2010 at 04:05:30PM -0400, Michael wrote: kernel output anyway. All it needs is a sane way to decide wether it can allocate memory or not. So split init in a minimal (optional) version called from the consinit functions, and a full grown init called at driver attach time (and have the latter skip the parts already done by the first if it ran already). Well, I already have a flag that skips the non-essential, memory- allocating part. The question was for a way for rasops itself to know if it can do it instead of depending on the caller. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBS+SAJspnzkX8Yg2nAQKomAf+LyWQ53cKuZfTgwOmlHONuQStJFHT0kto Z1zBjPVjFhPD117IF6D1BWoLnX8TmSMM6v2UqVpkQCsNYbKcnagDBn5Ppe4V7HjZ jIuCcw5Lz7VudcLgnF365VCCDWQ0RUFd/+D/2NhlevJj2tNLuQYGQVF8dfTecZPt F2zUMGQHs2mjE2y0Pck6fTb7LoxVXMtNpZWKW4sfbH8qC9I+ff5HuPiYXLZA2fIG pqALWXqEguZTRgZ+635AXIWjtV734KuJv6WODLv8ZmDNJxQ+7rgdh3QlaU1CVpgr F5mkkDc90ME5M2D2ZZ14gcnnw537+rCL7NPAMor9QNg5gkXfIfGE8A== =aNFH -END PGP SIGNATURE-
Re: allocating memory during kernel startup
On Fri, 7 May 2010, Michael wrote: 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. You could also do what I did on sparc64: early on attach an OFW console and replace it with the real console during the device probe. Eduardo
Re: allocating memory during kernel startup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On May 7, 2010, at 5:31 PM, Eduardo Horvath wrote: On Fri, 7 May 2010, Michael wrote: 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. You could also do what I did on sparc64: early on attach an OFW console and replace it with the real console during the device probe. I think macppc had an OF console at some point ( there's code that looks like it ), I have no idea why it hasn't been used at least since 1.6. I'd almost bet there are different weirdnesses with different versions of Apple's OF even with simple character output though. Either way, the early rasops console works fine and the problem has been solved ( pass a flag that tells rasops not to allocate any memory ) - I was just looking for something simpler that doesn't need changes all over the place. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBS+SKBspnzkX8Yg2nAQLeaAf/RUkA5tHxdBviGSa8EHg099+ihU9zpbtI cosP9Guw9NL59r3MbREqbXLMVnZZlW/IuHNS2h/dV2D7X9u1EoXuBrou/aXkUrH3 JhpKn8d3CHUkHRLF7KMJQPH6Q18cfEhhSPGVHZxGaGk6BkwwXtCRqtbOSpOoESD8 KOc/V7k3AuLj4JWFgT6vnCcoUNKARtoQhT9SlNigpoDoMXyXu301dy75xGRlK41y Z4DqpjhDvQHtXLnFf1lc3SCtypleQiE8OgKRQBEzGH+I9Js1nS6Zi9+40CevdrUw w7onT7npArbSmwkCZe1adVDEET3jTCRHWhqCc7risrwWR2lR2S1cPA== =KMEb -END PGP SIGNATURE-
Re: allocating memory during kernel startup
On Thu, May 06, 2010 at 02:32:57PM -0400, Michael wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I recently ran into this problem - there is no easy way to determine wether it is safe to call kmem_alloc() yet ( as in, are we far enough through startup ) and when we call it too early the whole thing just hangs. We have no clear definition of the kernel state - what is boot, startup, and when it's done. Any chance to just have kmem_alloc() immediately return NULL if it isn't ready yet so we can fail gracefully instead of hanging? I like panic(). I think that complicating memory allocation in bootstrap is not a good thing. What is your purpose? Masao have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBS+MLWcpnzkX8Yg2nAQIQUAf/S9Sr9flxPytiLSIoQ9TqLx3NraBPKF0x SFQMVRnvHDR2imaexL1lab/tdrwmZcs1uUvmgdDravx8DfYEm6k7Y3rzr273T2b2 LuXQC5OxEL3ZRfhAYbWn06nEdDGoBDxlzz7bNT1TY7T7+6ZQeweyX51Ez89RM3us MpeDeLAAPWtXaSm5Yo1jf7j7Uz0cblENkUetxp2YvUPKIHGRLn1iz0Xn7bdYqdHN XaQi2WrE4Rsw8ee9se/NJdqFprsUaQLwRsSLGxm1FMYTho8IaOlX8i3z/tARMGpe 3cRfHzS7ARGyjlWXJTPm1TtcXa5+0S4v9RoqJrDowNC6r3699RkqUg== =AP9s -END PGP SIGNATURE- -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
