Quoting Serge E. Hallyn (serge@xxxxxxxxxx):Funny. I played with it and decided that it can happen :)
Quoting Badari Pulavarty (pbadari@xxxxxxxxxx):
On Thu, 2007-06-07 at 15:37 -0500, Serge E. Hallyn wrote:Should be nothing stopping it.
Quoting Badari Pulavarty (pbadari@xxxxxxxxxx):Only if we generate same ID in two different namespaces. Is it currently
On Thu, 2007-06-07 at 12:48 -0700, Andrew Morton wrote:It will, but could lead to two different inodes with the same i_ino,
On Thu, 07 Jun 2007 10:06:37 -0700Yes. Albert, please correct me if I am wrong.
Badari Pulavarty <pbadari@xxxxxxxxxx> wrote:
On Thu, 2007-06-07 at 12:43 -0400, Albert Cahalan wrote:yup, we should put it back. The change was, afaik, accidental.
On 6/7/07, Badari Pulavarty <pbadari@xxxxxxxxxx> wrote:Nope. Currently "key" is part of the name (but its not unique).
BTW, I agree with Eric that its would be nice to use shmid as partIt is not at all nice.
of name instead of forcing to be as inode number. It should be
possible for pmap to workout shmid from "key" or name. Isn't it ?
1. it's incompatible ABI breakage
2. where will you put the key then, in the inode? :-)
Changing to "SYSVID%d" is no good either. Look, peopleI am not breaking ABI. Its already broken in the current
are ***parsing*** this stuff in /proc. The /proc filesystem
is not some random sandbox to be playing in.
Before you go messing with it, note that the device number
also matters. (it's per-boot dynamic, but that's OK)
That's how one knows that /SYSV00000000 is not just
a regular file; sadly these didn't get a non-/ prefix.
(and no you can't fix that now; it's way too late)
Next time you feel like breaking an ABI, mind putting
"LET'S BREAK AN ABI!" in the subject of your email?
mainline. I am trying to fix it by putting back the ino#
as shmid. Eric had a suggestion that, instead of depending
on the inode# to be shmid, we could embed shmid into name
(instead of "key" which is currently not unique).
BTW, I suspect this kind of thing also breaks:If you strongly feel that "old" behaviour needs to be retained,
a. fuser, lsof, and other resource usage display tools
b. various obscure emulators (similar to valgrind)
here is the patch I originally suggested.Confused. Will this one-liner fix all the userspace breakage to which
Albert refers?
right?
possible ?
(just to be more certain, a quick test showed I can get id 0 for
different keys, and different ids for the same key 0xff, in different
ipc namespaces)