bug-hurd
[Top][All Lists]
Advanced

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

Re: [PATCH] System V Shared memory interface


From: Roland McGrath
Subject: Re: [PATCH] System V Shared memory interface
Date: Tue, 8 May 2001 00:15:33 -0400 (EDT)

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

This is not the kind of explanation I was looking for.
You have not described what it does in filesystem terms.
Compare shm_getid to a normal file open (i.e. dir_lookup).

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

You have yet to describe in Hurd-meaningful terms what it is you want to do
and why you can't do it with an existing filesystem.  SysV shm objects are
mappable storage objects.  In the Hurd we usually call these "files".

> 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 suggested nothing remotely like that.

> 1) We need to turn keys into ids and return the id.  How do you do it?

What's a key?  What's an id?  A key is some bits that designate a storage
object.  We usually call a collections of bits like that "file names".

> 2) When a new id is created, we need to fabricate a shmid.

What's a shmid?


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



reply via email to

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