Messages in this thread | | | Subject | Re: [Fastboot] /x86_64-machine_shutdown.patch breaks sysrq-b | From | (Eric W. Biederman) | Date | 28 Mar 2005 02:15:29 -0700 |
| |
Andrew Morton <akpm@osdl.org> writes:
> ebiederm@xmission.com (Eric W. Biederman) wrote: > > > > Hmm. Looking a little more closely sysrq-o calls schedule work > > which I assume places the code into a context where it can schedule. > > Does that sound like a good approach to rebooting as well? > > Not really - if keventd is stuck somewhere, the reboot attempt won't work. > > One could try schedule_work() once, and on the next attempt do something > drastic I suppose. > > Or just bypass all the shutdown logic and just reboot the machine, dammit - > is that not possible?
Given the giant variation in hardware out there I don't know if it is possible in the general case. The previous code does seem to work on most hardware. But I'm not certain it is desirable to promise something that only works most of the time from a code maintenance standpoint.
From a maintenance standpoint code that is robust and useful from in an interrupt context is harder to write. In addition it sets up a promise to do something that may well be impossible.
The bottom line is that the various bits and pieces on the reboot path have such inconsistent semantics that making a correct change seems to be nearly impossible. And irritatingly enough obviously correct pieces of code like calling set_cpus_allowed() aren't acceptable because they are not interrupt safe.
The bottom line is that if we want correct code on the reboot path that hole chunk of the kernel needs to ripped apart and put back together.
Like I said earlier I am torn on how to approach this. One part of me wants code that is maintainable without a lot of work, another part of me want something that just works for the interesting cases.
The best way I can see to approach this is to rework the code with the assumption that only sys_reboot() is the only caller who matters. Fix everything so that case works properly, and has clear semantics. And then evolve code that is non longer a maintenance nightmare back to the best effort machine_restart() code in sysrq-B. My big problem is I'm not certain if I have enough time to follow through on my ambitions.
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |