[Openmcl-devel] Command line argument behavior

[Xiaofeng Yang]

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.

     Best regards,
Ṇ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
> http://clozure.com/mailman/listinfo/openmcl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20110614/61d61b09/attachment.htm>