I don't know what Eric thinks about using something else than a
system call, but I think he made a quite reasonable choice.
The data structure isn't entirely trivial, so a misc device plus
ioctl would be a bit on the ugly side. I vaguely remember having
proposed something like this a while ago (may have been for
pivot_root), and everybody went "noooo!!" ;-)
insmod would be possible, although with a rather unusual parameter
passing scheme. Also, when using kexec from inside the kernel (e.g.
MCORE), the insmod solution would have to split kexec into the
interface and the kexec core.
But yes, there's always a means to avoid adding a new system
call. /dev/syscall with an ioctl
struct syscall_ioctl {
const char *symbol_name;
va_list ap;
};
anyone ? :-) (Implementing it might be a bit of a challenge :)
> So you need to register with the power management as the last thing to
> be suspended and do a suspend before kexec.
Well, kexec just calls device_shutdown. The problem isn't the
interface, it's that device_shutdown apparently doesn't work too
well (devices not supporting it, some semantics mixup, etc.).
But this is general infrastructure work, that should be done
with or without kexec.
> I'm mostly worried about how to make these things fit the least
> intrusively into the kernel.
Just look at Eric's kexec patch. It isn't particularly intrusive:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103604471723358&w=2
(For 2.5.45. The patch fails for 2.5.46, because new system calls
were added ...)
- Werner
-- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ - 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/