> If sysvshm were some magical new kind of facility, it wouldn't be so easy
> to implement it with code just like other facilities we already have. So
> you can relate what the actual meat of the sysvshm functionality is to
> other facilities, and not just say "it does what it does". (My position is
> that if you do this you will find there is very little meat left. Then it
> will become clear how to implement the sysvshm C interfaces without wholly
> new servers.)
So what you are proposing is the following:
/var/run/sysvshm/
+- id-1
+- id-2
+- id-3
+- id-4
+- id-6
+- id-7
+- id-10
+- key-1 -> id-3
+- key-2000 -> id-10
+- key-9856 -> id-7
Thus, when a user does:
id = shmget (key, size, IPC_CREAT | flags);
shmget creates the link `/var/run/sysvshm/key-KEY' to a
`/var/run/sysvshm/id-ID', a new id. If a user does a lookup:
id = shmget (key, 0, 0);
shmget then looks up `/var/run/sysvshm/key-KEY' and returns the target
of the link. And, finally, if a user does:
id = shmget (0, size, flags);
shmget creates a new file, `/var/run/sysvshm/id-ID', and returns ID.
shmat, shmdt and parts of shmctl follow logically.
Am I correct?
If so, how are we going to create a POSIX conforming implementation
without rewriting parts of a filesystem anyway (e.g. statistic
collection).
PGP signature
