On Mon, 19 Dec 2005, Steve Langasek wrote: > > > by constraining the actual *implementation* of /run (barring ugly > > > hacking of the init scripts), you've made the system less suitable > > > for a third use case: > > > > > > - memory is at a premium, disk is not
Then IMHO Debian is NOT the appropriate system to run on that box. Get a non glibc-based one that also likes to pass -Os to gcc and compiles the kernel with -Os. > > Tmpfs memory can be swapped out, so is this even a hypothetical problem? > > Maybe it isn't on Linux. I wasn't aware tmpfs could be swapped out. All VM-based filesystems in the BSDs, Linux and Solaris swap out just fine, and they always have done so AFAIK. In fact, other than the filesystems for on-chip disks (flash or eeproms), and stuff like procfs and sysfs that aren't really there anyway, I have never heard of non-swappable in-memory filesystems. > That still leaves the question of just which features we want to require > from our non-Linux kernels for basic operation, I guess. Those are: Solaris, *BSD and The Hurd. Solaris and all of the BSDs can do VM-based filesystems that are nearly identical to tmpfs. I don't know about The Hurd. > Sounds to me like this will play havoc with idempotence of init scripts; > anyway, why would "mount /run and clean it" be anything less than an atomic > operation from the viewpoint of other init scripts? There's no reason, if we don't break the init scripts in some misguided try to run them in parallel without proper barriers/dependencies :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
