<br><div class="gmail_quote"><font size="2"><font face="comic sans ms,sans-serif">I also patch it to solve this problem by myself several months ago. I added the compilation macros to disable parsing the ccl's arguments, so that I can get another kernel which not to parse the ccl's arguments. Then I add a new optional argument to save-application, so that I can indicate which kernel to append to the image.<br>
<br clear="all"></font></font> Best regards,<br>Ṇakṛakīya Yang, 杨晓峰<div><div></div><div class="h5"><br>
<br><br><div class="gmail_quote">2011/6/4 Waldek Hebisch <span dir="ltr"><<a href="mailto:hebisch@math.uni.wroc.pl" target="_blank">hebisch@math.uni.wroc.pl</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>><br>
> The problem as I see it is as follows: When only one argument (which =<br>
> does not begin with a '-') is provided to a binary which consists of =<br>
> (kernel + heap-image), the current kernel code automatically tries to =<br>
> load that argument as the image even though it should clearly use the =<br>
> image attached to the binary itself. As a result, one has to always use =<br>
> the '--' argument to end processing of the kernel arguments. This =<br>
> behavior is not expected for unix command line tools and shouldn't be =<br>
> expected here either IMHO.<br>
><br>
<br>
</div>Yes, this is a serious problem.<br>
<div><br>
> The attached patch provides a sub-optimal solution which basically =<br>
> detects the case when the heap image is already included in the binary =<br>
> and so does not try to load the image from that first argument. The =<br>
> problem with this is that since '--' is not required, other kernel level =<br>
> command line flags, such as -I, -R, -S, etc, that are not passed on to =<br>
</div>> the application may cause some confusion.=20<br>
<div>><br>
> Another solution is to completely disable those kernel level flags if =<br>
> the heap image is attached to the kernel, but the loss of control over =<br>
> those parameters is also undesirable.<br>
><br>
> Any other suggestions?<br>
><br>
<br>
</div>IIRC the kernel flags have short and long forms. Short forms are<br>
very likely to cause conflicts, but long forms are not so bad.<br>
So as cheap compromise one may disable only short form.<br>
<br>
Better solution would be to let application choose if/which kernel<br>
flags are respected and allow to rename them. This would require<br>
ability to embed list of strings into image and recover it when<br>
checking for presence of the image.<br>
<font color="#888888"><br>
--<br>
Waldek Hebisch<br>
<a href="mailto:hebisch@math.uni.wroc.pl" target="_blank">hebisch@math.uni.wroc.pl</a><br>
</font><div><div></div><div>_______________________________________________<br>
Openmcl-devel mailing list<br>
<a href="mailto:Openmcl-devel@clozure.com" target="_blank">Openmcl-devel@clozure.com</a><br>
<a href="http://clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://clozure.com/mailman/listinfo/openmcl-devel</a><br>
</div></div></blockquote></div><br>
</div></div></div><br>