[Buildroot] device_table & /dev/shm

[Buildroot] device_table & /dev/shm

[Charles Krinke]

I have two issues I dont understand and am hoping for a few clues to
help me navigate through the "Swamp of Confusion" to the "Ridge of
Enlightment".

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

2. I can see that named semaphores are not working. That is,
sem_open() called from an application program fails with ENOSYS. In
researching this, I can see that this depends on part on /dev/shm and
linking with -lrt. It also appears that the default /etc/fstab does
not use /dev/shm. My second question is:

"What are the items that can go awry in an MPC8323 system that may
cause named semaphores using the sem_open() call to fail?"

-- 
Charles Krinke

[Buildroot] device_table & /dev/shm

[Khem Raj]

On 06/25/2011 11:29 AM, Charles Krinke wrote:
> I have two issues I dont understand and am hoping for a few clues to
> help me navigate through the "Swamp of Confusion" to the "Ridge of
> Enlightment".
>
> 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?"

I would check shm support in kernel is enabled or not
and /etc/mtab has /dev/shm entry or not.

>
> 2. I can see that named semaphores are not working. That is,
> sem_open() called from an application program fails with ENOSYS. In
> researching this, I can see that this depends on part on /dev/shm and
> linking with -lrt. It also appears that the default /etc/fstab does
> not use /dev/shm. My second question is:
>

I think its because of above problem.

> "What are the items that can go awry in an MPC8323 system that may
> cause named semaphores using the sem_open() call to fail?"
>

Depends if you are using applications that rely on shm_*

[Buildroot] device_table & /dev/shm

[Baruch Siach]

Hi Charles,

On Sat, Jun 25, 2011 at 11:29:46AM -0700, Charles Krinke wrote:
> 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?"

Do you have devtmpfs mounted on /dev? If so, devtmpfs takes over the content 
of /dev, and hides the device nodes and directories from your device table.  

baruch

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] device_table & /dev/shm

[Peter Korsgaard]

>>>>> "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.

-- 
Bye, Peter Korsgaard

[Buildroot] device_table & /dev/shm

[Charles Krinke]

Please bear with me as I try to understand a couple of concepts. My
experience has mostly been in kernel drivers and this application level
setup is not completely understood by me.

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

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.
>
> --
> Bye, Peter Korsgaard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110626/0f91d307/attachment.html>

[Buildroot] device_table & /dev/shm

[Baruch Siach]

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 -

[Buildroot] device_table & /dev/shm

[Peter Korsgaard]

>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:

Hi,

 >> Is there a busybox config setup for /dev/shm? I went through the busybox
 >> menuconfig this morning and I don't see one.

 Baruch> There is nothing related to Busybox here. All you need to do is
 Baruch> to create the /dev/shm directory, and then mount tmpfs on it.

You don't even need the mount if you are using devtmpfs (which you imho
should).

-- 
Bye, Peter Korsgaard