All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Holler <holler@ahsoftware.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, Levente Kurusa <levex@linux.com>
Subject: Re: [PATCH v2] initramfs: print error and shell out for unsupported content
Date: Wed, 26 Mar 2014 22:16:03 +0100	[thread overview]
Message-ID: <53334393.5050008@ahsoftware.de> (raw)
In-Reply-To: <532CC625.7020509@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,

- 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)).


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.


Regards,

Alexander Holler

  parent reply	other threads:[~2014-03-26 21:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-20 21:35 [PATCH] initramfs: print error and shell out for unsupported content Alexander Holler
2014-03-20 21:43 ` Levente Kurusa
2014-03-20 22:00   ` [PATCH v2] " Alexander Holler
2014-03-20 22:25     ` Alexander Holler
2014-03-21 21:03     ` Andrew Morton
2014-03-21 22:49       ` Alexander Holler
2014-03-21 22:55         ` Andrew Morton
2014-03-21 23:07           ` Alexander Holler
2014-03-22  9:53             ` Alexander Holler
2014-03-22 12:29             ` [PATCH 1/2] initramfs: don't include filenames from the initramfs for make goals (dist)clean Alexander Holler
2014-03-22 12:29               ` [PATCH 2/2 v3] initramfs: print error and shell out for unsupported content Alexander Holler
2014-03-22 18:22                 ` Alexander Holler
2014-03-31 20:31                   ` Michal Marek
2014-04-01 11:23                     ` Alexander Holler
2014-04-01 12:23                       ` Michal Marek
2014-04-01 17:52                         ` Alexander Holler
2014-10-19  7:18                           ` [PATCH 1/2 v4] initramfs: don't include filenames from the initramfs for make goals (dist)clean Alexander Holler
2014-10-19  7:18                             ` [PATCH 2/2 v4] initramfs: print error and shell out for unsupported content Alexander Holler
2014-03-26 21:16             ` Alexander Holler [this message]
2014-03-26 21:38               ` [PATCH v2] " Levente Kurusa
2014-03-26 21:55                 ` Alexander Holler
2014-03-26 22:37                   ` Alexander Holler
2014-03-27  8:25                     ` Alexander Holler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53334393.5050008@ahsoftware.de \
    --to=holler@ahsoftware.de \
    --cc=akpm@linux-foundation.org \
    --cc=levex@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.