[PATCH] init: allow to preserve init's command-line

[Daniel Thompson]

On 03/02/16 12:29, Nicolas CARRIER wrote:
> Honestly, I hesitated to propose the inverse feature.
> I think the key point is : what we consider "normal" behavior ?
> I tend to consider it's "keep your arguments as they were passed to
> you", but I felt there was more people favoring the "do as you've
> always done".

Defaults are enough to handle "normal" behavior; inverting the 
definition of a feature isn't helpful.

It is far better (and more intuitive) if: feature off -> smaller code


> About being "brave", I hesitated also, but I imagined it would be
> easier to see a conservative patch integrated.

To be honest I feel much less strongly about the need for bravery. 
However in a long thread few use cases have come up that are not 
cosmetic legacy compatibility.


Daniel.

> 2016-02-03 13:02 GMT+01:00 Daniel Thompson <daniel.thompson at linaro.org>:
>> On 01/02/16 18:09, Nicolas CARRIER wrote:
>>>
>>> Thank you for all your comments.
>>> Please find a new version attached.
>>
>>
>>> +//config:config FEATURE_PRESERVE_CMDLINE
>>> +//config:      bool "Prevent init from altering its command-line after
>>> parsing"
>>> +//config:      default n
>>> +//config:      depends on INIT
>>> +//config:      help
>>> +//config:        When launched as PID 1 and after parsing its arguments,
>>> init
>>> +//config:        wipes all the arguments but argv[0] and rewrites argv[0]
>>> to
>>> +//config:        contain only "init", so that its command-line appears
>>> solely as
>>> +//config:        "init" in tools such as ps.
>>> +//config:        If you set this option to Y, all the arguments including
>>> argv[0]
>>> +//config:        will be preserved, be they parsed or ignored by init.
>>> +//config:        The original command-line used to launch init can then
>>> be
>>> +//config:        retrieved in /proc/1/cmdline on Linux, for example.
>>
>>
>> Having reviewed the thread I read FEATURE_PRESERVE_CMDLINE like a
>> double-negative.
>>
>> The feature is not preserving the cmdline; the feature is scrubbing the
>> command line. It would be *much* easier to document the feature when we can
>> say what is does do (i.e. increase compatibility with legacy unix
>> environments) than by saying what it doesn't do.
>>
>> I also think keeping scrubbing on by default is rather conservative. Why not
>> be brave and default to smaller code size!
>>
>>
>> Daniel.