Hi, On Tue, Mar 11, 2003 at 08:49:20PM +1000, Anthony Towns wrote: > On Tue, Mar 11, 2003 at 11:17:07AM +0100, Emile van Bergen wrote: > > True. The same goes for /mem though, and because it's a bit broader than > > /run, I still think it's named more appropriately. > > "/mem" implies it's going to be in memory, just like "shm" implies > it's for shared memory. We don't have /nfs, or /disk. Not that "usr" or > "etc" are particularly descriptive, but at least they're not actively > misleading. Well, I stipulate that /mem will be in memory in 90 % of the cases if implemented, and exhibit memory-fs-like qualities in 100 % (gone at reboot, except for an explicitly preserved part). So actively misleading goes a bit far ;-) > /mem is a great name for something the sysadmin sets up, and then points > things at; but it's a bad name for apps to use to get at their data. Most apps would continue to use /var/run, which would be a symlink to /mem/run on systems that have /mem. Only things that need writable storage before /var is available need /mem as a hardcoded path directly; other apps that /like/ to store their files in memory but do not /require/ it can also use /mem. > "/early" perhaps? "/etc/early-var" ? (The latter being a configuration > option indicating where to put variable data that's needed early in the > boot process; in the form of a symlink) Yes, or /volatile, as the most prominent requirement other than it being writable early is that it's empty after a reboot. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgpIMexI2xZlf.pgp
Description: PGP signature