Re: [PATCH] System V Shared memory interface

[Neal H Walfield]

> 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).

pgpmhdTZUXQ9i.pgp
Description: PGP signature