On Wed, Mar 12, 2003 at 10:00:31AM -0800, John H. Robinson, IV wrote: > Steve Langasek wrote: > > On Wed, Mar 12, 2003 at 03:47:47PM +0100, Emile van Bergen wrote: > > > > > Again, your proposal is fine, but I still think offering a generic ram-based > > > fs is more elegant. > > > > It is not elegant, it's second-guessing the admin. > emile has been saying that /mem (/ram) does not need to be on a > ramfs/tmpfs filesystem, just that they need to have those qualities > (cleared at reboot) and could easily be placed onto a ramfs at the > admins discretion to minimize disk accesses for laptops and the ilk. > so /mem (/ram) is less about the implementation, and more about the > properties. > this makes /mem (/ram) name potentially misleading. using something like > /volatile or /vtl here's one: /tmp/run > /tmp needs to be r/w anyway. /tmp can be implemented in a ramfs, but it > does not need to, and it gets cleaned out at reboot also. so instead of > a /etc/mem.skel you have a /etc/tmp.skel that contains the /tmp/run > prototype that is remade at boot time. the best part: no new top level > directory. is /tmp available early enough? can /tmp be network mounted > for non-diskless systems? any problems with that that i cannot think of > at the moment? > you can include your /tmp/run/preserved also, but that seems more of an > admin thing than an OS thing. Not /tmp -- it's kosher for admin scripts to wipe out /tmp while the machine is still running. Losing resolv.conf this way would be a Bad Thing. :) -- Steve Langasek postmodern programmer
Attachment:
pgpGOmCXiP5Ac.pgp
Description: PGP signature