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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox