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

[Alexander Holler]

Am 26.03.2014 22:55, schrieb Alexander Holler:
> Am 26.03.2014 22:38, schrieb Levente Kurusa:
> > > 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.

Why do you try to discuss stuff you don't know about and haven't looked 
at? You could have taken the time to try out the description of my patch 
insgtead of just checking it for typos. Thats why I did spend the time 
to write that description.

The include is already there and is used. And that completly renders any 
further call of make broken, including make clean, distclean and 
mrproper. And is isn't obvious how to fix a once broken make. Even git 
clean -df doesn't help.

> > > - 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?

I've already suggest an example for that. If you have a machine with 
bluetooth, look at /var/lib/bluetooth and you will discover directories 
with colons. So, guess what happens if you want to have (preset) 
link-keys in an initramfs to avoid an otherwise necessary pairing.

And spaces in filenames are used by a lot of people for various reasons. 
And you might wonder, but there exists software one might want to use in 
an initramfs which needs some file(s) with an hardcoded name wich 
contains spaces.


Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/