Re: [PATCH] System V Shared memory interface

[Roland McGrath]

I'm going to start the new list off by picking up the discussion with Neal
about sysvshm that started on bug-hurd.

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

I have not proposed anything in particular.  My general proposal is to milk
generic interfaces as far as you can do without really bending over
backwards, before adding new ones.  And moreover, to add the minimal
appropriate interfaces that are the extensions necessary to fill the need
in a reasonably natural and clean way within the framework of existing
facilities, rather than adding new interfaces with their own independent
abstractions.

All that said, I really don't have enough context about what functionality
the sysvshm interfaces are supposed to provide to the user to respond very
specifically.  As I mentioned before, I recall at some point in the past
thinking about this in detail and hatching a plan that required less work
and fewer interfaces than what you've been talking about.  But I recall
neither the details of my plan nor the sysvshm interfaces or what docs or
specs I found at the time to tell me what they are supposed to do.

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

I don't understand this whole notion at all.  As I understand it, a shm
"id" is a live identifier to an object, i.e. it's a file descriptor.  The
"key" is the global naming element, i.e. it's the file name
(e.g. "/var/run/sysvshm/%08x" for a 32-bit key_t).  For IPC_PRIVATE, the
file is anonymous (a la dir_mkfile).  

It's beginning to come back to me.

shmget  ->      open
shmat   ->      mmap
shmdt   ->      munmap

You maybe need to keep some local state because the size of the mapping is
implicit in shmat/shmdt.  

I had thought that the only quirk that prevents you from implementing it
wholly with the vanilla interfaces is that you can shmctl(IPC_RMID) a key
and that means to destroy it only after all mapping are detached.  But on
reading the Linux shmctl man page just now, it says you get EIDRM in that
case.  So the only failing of a vanilla file-based Hurdish implementation
would be returning ENOENT instead of EIDRM--or letting you create a new
segment with the same key as one that has mappings but is marked for
deletion.  

So what I'd had in mind for sysvshmfs was like tmpfs but you could have a
single flat root directory that is just an ihash.  (You could then
implement the EIDRM behavior, i.e. leave a node in the directory ihash with
st_nlink==0 until it loses its refs.)  And since shm segments are not
supposed to be variable-sized after creation, it can be even simpler than
tmpfs (it can punt support for all but regular files, too).  Such a
filesystem (i.e. in the tmpfs model but much simpler) would probably fit
easily in one source file.

General principles aside, one thing I like about this approach to the
interface is that it means that shm functionality would work at least 95%
right even if /var/run/sysvshm is just a plain directory in your filesystem.