W dniu 04.04.2011 11:10, Moritz Wilhelmy pisze:

Dear CRUXers,

TODO28 in the wiki mentions the possible inclusion of /run in the next release. While I see the point of this for other distributions, I'm not completely convinced we should do so as well. I didn't want to break this discussion from the fence in the wiki (because a wiki is not the place to discuss that kind of things), and I didn't notice any discussion at all on the matter, so I decided to post here.

Here my few points:

* /run is not yet in FHS.

Well - /usr/share/man is in FHS, but Crux goes on with /usr/man pretty fine. FHS also prefers /lib64 over /lib, regardless if we're on pure amd64 system or not. Point being - I've always seen FHS more like a set of suggestions, than something that would have to be followed to the letter. Note, pretty old suggestions.

* Early boot should start udev, and then /var will be mounted. We don't use systemd, and creating /run just for udev seems out of place. I don't mind if udev creates it's directories in /dev/.udev, because udev is halfway related to /dev anyway. I see the point on distros using systemd, since they need to cram other, unrelated stuff into /dev, so /run is probably a better design choice for them; Nevertheless, CRUX is not fedora. So unless anyone wants to switch from SysV-init to systemd for the next release, I vote against /run.

It's not only about systemd. Whole point was to standarize the way of transferring data from initramfs to the real [file]system. As /dev is usually mount --move'd (along with /sys and /proc) before chrooting - it became kinda "natural" to keep runtime data there, that should be handed over (as a bonus /dev is also persistent with devtmpfs). For example - mdadm keeps/ed its stuff there during incremental assembly. So to clean things up: The first option was to simply use /dev/.run tmpfs and mount --move that subdirectory to /var/run . But that was a bit ugly as well - e.g. init scripts would have to make sure /var is not overmounted (so: mount --move "away", mount /var, mount --move /var/run "back in place"). So to not complicate things, they settled for a clean and simple method: /run tmpfs, --mount move to /run on real filesystem before chroot. KISS and no problems with accidental overmounting. As a bonus /dev is finally only for the device related stuff (not even .udev there anymore). The adopting is completely (I think) neutral: - tmpfs mount over /run (possibly with some reasonable limits) - if it's not already a mountpoint (similary like udev checks if /dev is an exisiting mountpoint, eventually remount to enforce limits). - symlink /var/run -> /run and /var/lock -> /run/lock Few trivial patches could do the thing at any moment, without causing any compatibility problems (I don't think anything freaks out if /var/run is a symlink) or surprising less technical people.