From: Baruch Siach <baruch@tkos.co.il>
To: buildroot@busybox.net
Subject: [Buildroot] device_table & /dev/shm
Date: Mon, 27 Jun 2011 06:32:41 +0300 [thread overview]
Message-ID: <20110627033240.GA3046@jasper.tkos.co.il> (raw)
In-Reply-To: <BANLkTi=hr=U5eMmPbsUB-WH_QYjamGR5qA@mail.gmail.com>
Hi Charles,
On Sun, Jun 26, 2011 at 10:51:19AM -0700, Charles Krinke wrote:
> I would appreciate understanding more the two concepts of a) overriding
> target/generic/device_table. txt so I can understand how the mounted jffs2
> became different then the contents of output/target/dev
This is the general behaviour of mount on Unix like operating systems.
Whenever you mount a filesystem on a directory, the previous content of this
directory in no longer directly visible until umount. Instead, the content of
the mounted filesystem takes over.
> and the b) How we
> get from what appears to be the default /etc/fstab mounting tmpfs to one
> where we mount /dev/shm instead in our application space.
>
> Is there a busybox config setup for /dev/shm? I went through the busybox
> menuconfig this morning and I don't see one.
There is nothing related to Busybox here. All you need to do is to create the
/dev/shm directory, and then mount tmpfs on it.
baruch
> Charles
> On Jun 26, 2011 3:17 AM, "Peter Korsgaard" <jacmet@uclibc.org> wrote:
> >>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:
> >
> > Hi,
> >
> > >> 1. I can see the generic device_table.txt and it includes a /dev/shm
> > >> node. I can also see the /dev structure in output/target and it
> > >> matches the generic device_table.txt. But, ... when I build the jffs2
> > >> and load it on my MPC8323 target, what I see in /dev does not include
> > >> /dev/shm. In fact it is significantly different. So, my first question
> > >> is:
> > >>
> > >> "What besides generic/device_table.txt can determine the contents of
> > >> /dev on an MPC8323 target?"
> >
> > Baruch> Do you have devtmpfs mounted on /dev? If so, devtmpfs takes
> > Baruch> over the content of /dev, and hides the device nodes and
> > Baruch> directories from your device table.
> >
> > If so, it would be better to use the 'Dynamic using devmtpfs only'
> > device table option to not waste jffs2 space on device nodes you are not
> > going to use anyway.
> >
> > We might need to add a mkdir -p /dev/shm in inittab like we already do
> > for /dev/pts, as those are not device nodes and hence do not get created
> > by devtmpfs.
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
next prev parent reply other threads:[~2011-06-27 3:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-25 18:29 [Buildroot] device_table & /dev/shm Charles Krinke
2011-06-25 23:40 ` Khem Raj
2011-06-26 3:22 ` Baruch Siach
2011-06-26 10:17 ` Peter Korsgaard
2011-06-26 17:51 ` Charles Krinke
2011-06-27 3:32 ` Baruch Siach [this message]
2011-06-27 10:12 ` 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=20110627033240.GA3046@jasper.tkos.co.il \
--to=baruch@tkos.co.il \
--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.