Re: [PATCH] System V Shared memory interface

[Neal H Walfield]

> Can you give concise answers to these questions?

Hopefully.

> 1. What facility does your new RPC interface provide
>    over using the normal filesystem interfaces with
>    some convention of fixed-length file names for shm keys?

It adds 2.1 new functions.  First, it adds:

        shm_getid:
        
This takes a key and turns it into a shmid.  At the same time, it
creates an internal shm data structure.  This is (basically) equivalent
to the `standard' call: shmget.

It happens to take the size of the desired object.  This can be achieved
in other ways, however, that would create a potential race and as
sysvshm is a rather specific interface, I choose to add this.

        shm_stat:

This serves the role of `shmctl (id, IPC_STAT, &shm_ds)'.

        shm_statall:

Returns the stats on all of the memory objects.  This is not necesary,
however, it makes life a lot easier and faster.

> 2. What functionality does your shmfs provide over a normal
> filesystem?

I am not sure what you mean: It implements the required protocol.  I
aimed for SUSv2 conformance and I do not see how to do this without
adding new calls.  If you propose that we should generate text files
that you can `cat' for the information, I think that is quite foolish as
it is taking overloading to a new extreme and only complicates parsing.

> I think you need to
> first justify why the current facilities don't suffice and explore how
> they might be tweaked or extended slightly to cover the need. 

Ok.

1) We need to turn keys into ids and return the id.  How do you do it?
2) When a new id is created, we need to fabricate a shmid.
3) We dump statistics into the shmid_ds.

> At some point in the not too distant past I went over the shm
> interfaces in contemplation of a Hurd implementation.  I don't really
> recall anything specific about it, but my vague recollection is that I
> concluded there was just one new interface or quirk of functionality
> that would be required to meet the basic shm semantics (leaving aside
> the pid reporting and all that).  Maybe shm lets you continue to open
> a file after it's been deleted but still has live users?  Something
> like that.  

> I am strongly in favor of an approach where using any vanilla
> filesystem directory for /var/run/sysvshm works in a pinch (and maybe
> loses on some obscure point of shm behavior).  

Propose something better.

pgpg0OgbwLFr4.pgp
Description: PGP signature