[Openmcl-devel] Command line argument behavior
n.akr.akiiya at gmail.com
Mon Jun 13 22:10:37 CDT 2011
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.
Ṇakṛakīya Yang, 杨晓峰
2011/6/4 Waldek Hebisch <hebisch at math.uni.wroc.pl>
> > The problem as I see it is as follows: When only one argument (which =
> > does not begin with a '-') is provided to a binary which consists of =
> > (kernel + heap-image), the current kernel code automatically tries to =
> > load that argument as the image even though it should clearly use the =
> > image attached to the binary itself. As a result, one has to always use =
> > the '--' argument to end processing of the kernel arguments. This =
> > behavior is not expected for unix command line tools and shouldn't be =
> > expected here either IMHO.
> Yes, this is a serious problem.
> > The attached patch provides a sub-optimal solution which basically =
> > detects the case when the heap image is already included in the binary =
> > and so does not try to load the image from that first argument. The =
> > problem with this is that since '--' is not required, other kernel level
> > command line flags, such as -I, -R, -S, etc, that are not passed on to =
> > the application may cause some confusion.=20
> > Another solution is to completely disable those kernel level flags if =
> > the heap image is attached to the kernel, but the loss of control over =
> > those parameters is also undesirable.
> > Any other suggestions?
> IIRC the kernel flags have short and long forms. Short forms are
> very likely to cause conflicts, but long forms are not so bad.
> So as cheap compromise one may disable only short form.
> Better solution would be to let application choose if/which kernel
> flags are respected and allow to rename them. This would require
> ability to embed list of strings into image and recover it when
> checking for presence of the image.
> Waldek Hebisch
> hebisch at math.uni.wroc.pl
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel