Re: [PATCH v2] initramfs: print error and shell out for unsupported content

[Alexander Holler <holler@ahsoftware.de>]

Am 26.03.2014 22:38, schrieb Levente Kurusa:
> Hi,
>
> 2014-03-26 22:16 GMT+01:00 Alexander Holler <holler@ahsoftware.de>:
>> Am 22.03.2014 00:07, schrieb Alexander Holler:
>>>
>>> Am 21.03.2014 23:55, schrieb Andrew Morton:
>>>
>>>> On Fri, 21 Mar 2014 23:49:57 +0100 Alexander Holler
>>>> <holler@ahsoftware.de> wrote:
>>>>
>>>>> Am 21.03.2014 22:03, schrieb Andrew Morton:
>>>>>>
>>>>>> On Thu, 20 Mar 2014 23:00:45 +0100 Alexander Holler
>>>>>> <holler@ahsoftware.de> wrote:
>>>>>>
>>>>>>> The initramfs generation is broken for file and directory names which
>>>>>>> contain
>>>>>>> colons or spaces. Print an error and don't try to continue.
>>>>>
>>>>>
>>>>>> It would be better to fix the it-doesnt-work-with-all-filenames bug.
>>>>>> Any details on that?
>>>>>
>>>>>
>>>>> IMHO not worth the time. The whole process which is curently used is
>>>>> extremly fragile.
>>>>>
>>>>> E.g it's almost guaranteed to fail trying to include arbitrary filenames
>>>>> as dependencies in a Makefile. Besides the one problem I've discoverd
>>>>> with colons, there could be much more things happen, e.g. with filenames
>>>>> which do include other special Makefile characters you all would have to
>>>>> escape correctly.
>>
>>
>> To be a bit more verbose, (gnu)make doesn't support quoted filenames. That
>> means one has to escape all kind of characters which might have a special
>> meaning for make. Not really doable. Furthermore escaped characters are not
>> very well supported by make and are usable only by a few rules.
>>
>>
>>>>> And the problem with spaces isn't as easy to fix as it first does look
>>>>> like. I think it might be easier to write the whole stuff new instead of
>>>>> trying to escape the spaces in various ways needed to end up correctly
>>>>> in the cpio (it first goes through shell code and is then feeded as some
>>>>> list to a C program).
>>
>>
>> To be a bit more verbose here, the shell script
>> (scripts/gen_initramfs_list.sh) identifes filenames based on the position in
>> a string which is delimited by the usual (shell) whitespace. E.g. $1 =
>> filename, $2 = mode, ...
>> And this stuff is then feeded to usr/gen_init_cpio.c,which uses a similiar
>> approach like
>>
>> sscanf(line, "%" str(PATH_MAX) "s %" str(PATH_MAX) "s %o %d %d", name,
>> target, ...
>>
>> which obviously fails for filenames with whitspace too.
>>
>> What I think might be reasonable is:
>>
>> - get rid of the dependency list in form of a include into the Makefile and
>> just generate the cpio-archive every time make is called. Common initramfs
>> sizes are about a few megabytes and with today machines such a cpio-archive
>> is build in about a second,
>>
>
> I don't understand what kind of include would you want.
>
>> - get rid of gen_initramfs_list.sh and rewrite gen_init_cpio.c such that it
>> reads the filenames, modes and similiar itself (e.g. by using stat(2)).
>
> This is walkable but probably not worth the effort. Besides, why would
> anyone want to put spaces, colons and arbitrary characters to filenames
> in the initramfs?
>
>>
>>
>> But I don't have any motivation to do so. Sorry.
>>
>> Maybe Levente Kurusa is interested in doing so, he seems to have an interest
>> in the topic as he was quiet fast to send an answer to my patch.
>
> All I wonder now is why are you being so arrogant. You are not a 'remote
> keyboard' as you had called yourself, since when you send a patch
> you not only have to send it but communicate WHY maintainers
> should take that patch, and if somebody has a comment

The patch clearly explained what's broken.

> spotting an obvious mistake you shouldn't become angry.
> It was only a simple typo and a suggestion. Nobody told you
> to blindly accept my suggestion. Everybody can have opinions.
> It's open-source, the community suggests you new changes,
> it's normal, get used to it. Writing up this nonsense sentence
> (I feel the irony) probably took more time than actually resending
> the patch did.

So please accept my opinion that I'm not interested in fixing silly 
typos until I had at least some feedback with reasonable content. E.g. a 
Tested-By would have been nice.

And please forgive me that I'm unable to differentiate between feedback 
from "someone" or by a maintainer. Maybe I was fooled by that linux.com 
in your email, I had forgotten that this is a public available mail address.

So, Thanks for supporting the Linux Foundation.

Regards,

Alexander Holler