On 21/10/14 08:10, Martin Lucina wrote: > If I change this to do: > > rump_sys_reboot (0x08 /* RB_HALT */, NULL); > > Then my calling thread hangs at that point. I guess I expected that, after > all I did ask it to "halt the processor". However, if I do: > > rump_sys_reboot (0, NULL); > > Then then calling thread appears to exit instead, which is not what I want > either.
Right. There's a simple reason why rump_sys_reboot() doesn't return: there are code paths within the NetBSD kernel which are marked __attribute__((noreturn)), and returning from those is not possible without invoking a jump to hyperspace. Plus, what Justin said. > So, what is the preferred way to accomplish this? Should we have a > companion rump_term () to rump_init () for these use cases? > > I'm thinking ahead here, where someone might use this as part of library > functionality, which then gets re-used in unexpected ways. I think "don't call rump_sys_reboot()" is a good rule of thumb for a library. ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
