Bug 3181

I would suggest that we correctly create the symlink for /run to /var/run since this is targeted for embedded systems, having multiple tmpfs may not be the best.

Here's an article on this issue. http://article.gmane.org/gmane.linux.redhat.fedora.devel/146976

As this article suggests, I suggest a directory hierarchy like this.

tmpfs on /run
/var/run -> /run
/var/run/lock -> /run/lock
/var/run/log -> /run/log
....

This approach has already adopted by major distribution in their new releases.

Also, if we make /run the standard directory for volatile runtime data, /var/volatile would not be necessary any more.

%solution%
1) change base-file package, make /run a standard directory
   /run /run/tmp /run/lock ...

2) improve populate-volatile.sh, change the way it deals with links
   In current system, if we change /etc/default/volatile/<config file>,
   and then run command '/etc/init.d/populate_volatile.sh update', it is
   very likely the result is not what we expect.
   For example, changing 'l root root 0755 /var/run /var/volatile/run' to
   'l root root 0755 /var/run /run' in the config file does not have any real effect.
   This is caused by the way populate_volatile.sh deals with 'l'-type config items.
   It first examines if the <target> (in this example /var/run) exists, and if so, it does nothing.
   I don't think this is appropriate. The script should do things as the configuration file tells it.
   So I suggest the following way to deal with links in populate_volatile.sh. (similar to Ubuntu's way to deal with mounted-var. See attachment for more detail.)
   <type> <user> <group> <mode> <target> <link_source>
   if <target> exists as a dir:
      cp -rf <target> <link_source>; rm -rf <target>; 
   if <target> exists as a link or a file:
      rm -f <target>
   ln -sf <link_source> <target>

3) change /etc/fstab
   make /run a mount point for tmpfs
   /var/volatile is no more a mount point for tmpfs
   
4) change /etc/default/volatiles/<default config>, make the following directory hierarchy
   /var/run -> /run
   /var/cache -> /run/cache
   /var/lock -> /run/lock
   ...
   /var/volatile/run -> /run
   /var/volatile/cache -> /run/cache
   ...

   I still keep /var/volatile in system for backward compatibility reason. Because I'm not sure whether some packages in yocto will need it. But no tmpfs mounted at /var/volatile. 

(Any suggestion would be welcome.)

Please look at the base_files recipe also since it lays down some of the original layout so we do not need to do the cp or rm, also continue to implement a prototype this so we can confirm it's operation.

We've added code which links /run to /var/run in the recent udev upgrade.

Whilst I appreciate the desire to match "standards", is there a strong reason to change these defaults and break backwards compatibility with existing systems? I have a suspicion this is going to be a very disruptive change for users and I'm not sure we have a good reason for it?

Thank you for your advices. Here's a few thoughts of mine, please feel free to give me your opinions and suggestions.

1) Backward compatibility
Backward compatibility is the first thing that came into my mind when I first looked at this issue. That's why I still keep /var/volatile directory in my design.
After applying changes as stated above, I built a sato image and tested it on beagleboard. The weekly test cases all passed. 

2) populate_volatile.sh
Three major files (of course there're others) in yocto that change the directory hierarchy are 'fs-perms.txt', which is used by package.bbclass, 'base_files_xxx.bb' and 'initscripts' (volatiles and populate_volatile.sh).
Syntax in volatiles:    <type> <user> <group> <mode> <target> <link_source>
In current system, if <target> has been created in fs-perms.txt or base_file_xxx.bb (or other recipes), populate_volatile.sh has no real effect on that <target>. In other words, it has the lowest 'priority' (forgive me if I used the wrong word). However, /etc/default/volatiles/<config> and populate_volatile.sh are files that the end user actually see. They don't see fs-perms.txt or base_files_xxx.bb. If that script doesn't behave as expected, the user may be confused. So I suggest improve the script. Also, as Saul suggested, implementing a prototype for user confirmation is necessary.

3) problem with linking /run to /var/run
I think linking /run to /var/run in current system is OK. It's simple and seems to work so far. 
However, there may be two potential problems.
*) what if some application needs /run/lock or /run/cache, as udev needs /run
*) symlink /run to /var/run is specified in /etc/default/volatiles/<config>, if /run or /run/xxx is created by some recipes in yocto, the symlink will not be correctly created by the current populate_volatile.sh script. Actually, we have 'meta/recipes-core/initrdscripts/files/init-live.sh:    mkdir -p /run' and 'meta/recipes-core/initrdscripts/initramfs-framework/udev:	     mkdir -p /run '. I'm not sure wehther other recipes may use /run.
With these two problems considered, I prefer making /run dir a mount point for tmpfs. We can symlink /var/run to it, and also, symlink /var/volatile/run to /run for backward compatibility.

4) summary
There're two things we have to decide.
*) whether we should improve the populate_volatile.sh script
*) whether we should make /run dir a mount point for tmpfs or just symlink link it to /var/run

For now, everything seems OK to symlink /run to /var/run.

There seems no compelling reason to do this, so I'll mark this bug as RESOLVED/NOTABUG.

Setting to VERIFIED.
/run and /var/run/ symlink to /var/volatile/run, which is working fine now.