Re: /run vs /var/run
-----BEGIN PGP SIGNED MESSAGE-----
md@Linux.IT (Marco d'Itri) writes:
> On Dec 19, Henrique de Moraes Holschuh <email@example.com> wrote:
>> > > 1. It exists only on Linux-based OS's
>> > > 2. There is no gaurentee that it will continue to be there at all
>> > > 3. There is no guareteee that it will remain a filesystem in the future
>> > > even if it is there.
>> > > 4. There is no gaurentee that it exists at all.
>> > These points apply to the proposed tmpfs-based /run as well.
>> /run would have no other special function, so it is much more future-proof
>> than using /dev/shm for stuff it was not created for.
> You keep saying this, but fail to provide any arguments except
I provided you with a functional program code sample that demonstrates
how shm_open interacts with the filesystem. Did you try it? [link
with -lrt, BTW]
With this example, it's trivial to trigger namespace conflicts and
break shm_open(). "mkdir /dev/shm/foobar", for example, or create a
symbolic link. These fail outright. If a regular file was opened, it
would be ftruncated, zeroed and corrupted beyond repair. Depending on
who alters it last, this will
1) Cause POSIX-SHM using applications to fail with SIGBUS as the
backing store is removed.
2) Cause POSIX-SHM using applications to segfault or misbehave as
their data gets changed behind their back.
3) Cause the program abusing /dev/shm to fail as its datafiles are
trashed and/or unlinked behind their back.
Namespace conflicts aren't pretty. Sure, you can call it
"handwaving", but to me it's something that's going to break at some
point in the future. I can't believe you are condoning that,
especially when the fix is so simple.
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
-----END PGP SIGNATURE-----