All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] makedevs and symbolic links
Date: Wed, 6 Feb 2013 17:57:11 +0100	[thread overview]
Message-ID: <20130206175711.51603415@skate> (raw)
In-Reply-To: <CAJkQPOmpY_aT1DhDpxe2rw_endLzFkhmOWAkrbt1CzeG+7c=0Q@mail.gmail.com>

Dear Aras Vaichas,

On Wed, 6 Feb 2013 16:50:37 +0000, Aras Vaichas wrote:

> I understand that it doesn't make sense if you approach it from a non-root
> user point of view.
> 
> From a maintenance point of view, it's a "nice to have" if the creation of
> the root fs can be defined in as few places as possible. I like how
> makedevs works because I can look at a single file and I see a nice list of
> all the files in my system. Ideally it would be great if I could remove my
> skeleton/ directory and put everything into the BR2_ROOTFS_DEVICE_TABLE
> file.

I don't see how this would be possible. The skeleton have files with
contents in them. makedevs doesn't allow to create a /etc/inittab that
contains something, a /etc/passwd that contains something, etc.

The current design is really:

 * We have a base skeleton in system/skeleton that generally never
   needs to be modified. The base system/device_table.txt and
   system/device_table_dev.txt take care of setting the appropriate
   permissions/ownerships on the files part of the base skeleton.

 * For each project, we encourage people to create a rootfs overlay in
   board/<company>/<project>/rootfs-overlay/, where they can add their
   specific configuration files, symbolic links and so on. And a
   project-specific device table in
   board/<company>/<project>/device_table.txt sets the appropriate
   owernship for the files part of the rootfs-overlay.

I think a real filesystem view (be it in the skeleton or in the
overlay) is much nicer to look at and modify than the device table.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2013-02-06 16:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-06 16:17 [Buildroot] makedevs and symbolic links Aras Vaichas
2013-02-06 16:26 ` Thomas Petazzoni
2013-02-06 16:50   ` Aras Vaichas
2013-02-06 16:57     ` Thomas Petazzoni [this message]
2013-02-07 10:14       ` Aras Vaichas
2013-02-07 10:43         ` Thomas Petazzoni
2013-02-07 17:14         ` Arnout Vandecappelle
2013-02-07 21:58         ` [Buildroot] [PATCH] rootfs-overlay: also exclude .empty files Arnout Vandecappelle
2013-02-08  5:15           ` Samuel Martin
2013-02-08 21:18           ` 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=20130206175711.51603415@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --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 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.