<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<tt>Stefan Hajnoczi wrote:</tt>
<blockquote type="cite" cite="mid:fbd9d3991003190254j5489cc6ag26f3775539192b7f@mail.gmail.com">
<title>Re: [gPXE-devel] [PATCH] [script] Allow control over error
handling</title>
<!-- Converted from text/plain format -->
<p><tt><font size="2">Will this patch work for nested script
execution?</font></tt></p>
</blockquote>
<tt><br>
gPXE's current behaviour is to exit all scripts upon error. Scripts
developed by users might expect this behaviour and expect the regular
fall-back mechanism. Suppose 'autoboot' is implemented as a script
some day or that the user uses some other top-level script which clears
exit-on-error... I would not want the behaviour of the lower-level
scripts to mysteriously change without the user explicitly clearing
exit-on-error in each script, so this patch requires one to clear the
exit-on-error state in each script.<br>
<br>
It might be the case that user B uses a gPXE obtained from user A,
where user B does not know user A's embedded script, but expects
classic gPXE exit-on-error behaviour. I'm thinking particularly about
any services that offer custom gPXEs, such as Boot.Kernel.Org or
NetBoot.Me. Someone, somewhere, could potentially be middle-manning
BKO by using another gPXE script as "pxelinux.0". Since BKO would
likely use this feature, that person's middle-man script will continue
to function with the classic behaviour.<br>
<br>
It's certainly open to opinions, since it's easy to implement either
way. What do you think? :)<br>
<br>
- Shao Miller<br>
</tt>
</body>
</html>