[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] System V Shared memory interface

From: Neal H Walfield
Subject: Re: [PATCH] System V Shared memory interface
Date: Mon, 7 May 2001 15:15:51 +0200
User-agent: Mutt/1.3.15i

> Can you give concise answers to these questions?


> 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:

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.


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


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. 


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.

Attachment: pgpg0OgbwLFr4.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]