From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] busybox: provide /etc/mdev.conf if mdev is used
Date: Mon, 11 Jul 2011 12:09:07 +0200 [thread overview]
Message-ID: <4E1ACBC3.7020806@lucaceresoli.net> (raw)
In-Reply-To: <8739igy7e9.fsf@macbook.be.48ers.dk>
Il 08/07/2011 20:06, Peter Korsgaard ha scritto:
>>>>>> "Luca" == Luca Ceresoli<luca@lucaceresoli.net> writes:
>
> Luca> Without an mdev.conf file installed, mdev generates some /dev entries in
> Luca> an incorrect or non-standard way. Some examples:
> Luca> 1. /dev/null has permissions 660, but it should be accessible to normal
> Luca> users;
> Luca> 2. alsa devices get created in /dev, not /dev/snd as is more common,
> Luca> and as the default value of BR2_PACKAGE_ALSA_LIB_DEVDIR suggests;
> Luca> 3. event<N> files are created in /dev, not /dev/input.
>
> Luca> This mdev.conf is a selection from the examples provided in the busybox
> Luca> sources with minor tweaks.
>
> Looks good, except for ..
>
> Luca> diff --git a/package/busybox/busybox.mk b/package/busybox/busybox.mk
> Luca> index 509c3bb..30b7ab6 100644
> Luca> --- a/package/busybox/busybox.mk
> Luca> +++ b/package/busybox/busybox.mk
> Luca> @@ -33,6 +33,9 @@ ifeq ($(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV),y)
> Luca> define BUSYBOX_INSTALL_MDEV_SCRIPT
> Luca> install -m 0755 package/busybox/S10mdev $(TARGET_DIR)/etc/init.d
> Luca> endef
> Luca> +define BUSYBOX_INSTALL_MDEV_CONF
> Luca> + install -m 0644 package/busybox/mdev.conf $(TARGET_DIR)/etc
>
> Please use install -D, and only install if the file is not already
> there in the rootfs.
Will do both changes, but I'd like to better understand why this file
should not be installed if already present, which differs from how some
other files are installed.
For example, S10mdev is installed just before mdef.conf (see quoted
lined above) without -D and without checking for existence.
Is there a general policy about this? I did not find one in the docs,
but I might have missed it.
Additionally, if there is a clear policy, it may be useful to have
macros to automate it and make it verifiable, such as:
INSTALL_FILE = $(INSTALL) -D
INSTALL_DIR = $(INSTALL) -d
INSTALL_FOO = $(INSTALL)
or, maybe better, macros with parameters that would be easier to use:
$(call install_file, $(@D)/foo.conf, 0640, etc/foo)
which may translate to something like:
[ -f $(TARGET_DIR)/etc/foo/foo.conf ] || \
$(INSTALL) -D -m 0640 $(@D)/foo.conf $(TARGET_DIR)/etc/foo/foo.conf
Luca
next prev parent reply other threads:[~2011-07-11 10:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-08 15:47 [Buildroot] [PATCH] busybox: provide /etc/mdev.conf if mdev is used Luca Ceresoli
2011-07-08 18:06 ` Peter Korsgaard
2011-07-11 10:09 ` Luca Ceresoli [this message]
2011-07-11 10:23 ` Peter Korsgaard
2011-07-11 10:44 ` Luca Ceresoli
2011-07-11 11:40 ` Peter Korsgaard
2011-07-11 10:25 ` [Buildroot] [PATCH v2] " Luca Ceresoli
2011-07-11 11:42 ` Peter Korsgaard
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=4E1ACBC3.7020806@lucaceresoli.net \
--to=luca@lucaceresoli.net \
--cc=buildroot@busybox.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox