> > Basically, half of shmid_ds and retreived with
> > `shmctl (id, IPC_STAT, &shmid_ds)', e.g. number of current attaches,
> > shm_atime, shm_dtime and shm_ctime.
>
> Blech. Why not just keep track of that information in a file
> somewhere?
If I interpret what Roland says correctly, he is quit
Neal H Walfield <[EMAIL PROTECTED]> writes:
> Basically, half of shmid_ds and retreived with
> `shmctl (id, IPC_STAT, &shmid_ds)', e.g. number of current attaches,
> shm_atime, shm_dtime and shm_ctime.
Blech. Why not just keep track of that information in a file
somewhere?
On Thu, May 10, 2001 at 11:09:48AM -0700, Thomas Bushnell, BSG wrote:
> Neal H Walfield <[EMAIL PROTECTED]> writes:
>
> > If so, how are we going to create a POSIX conforming implementation
> > without rewriting parts of a filesystem anyway (e.g. statistic
> > collection).
>
> What do you mean b
Neal H Walfield <[EMAIL PROTECTED]> writes:
> If so, how are we going to create a POSIX conforming implementation
> without rewriting parts of a filesystem anyway (e.g. statistic
> collection).
What do you mean by "statistic collection"?
___
Bug-hur
> 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 positio
> 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 requ
Roland McGrath <[EMAIL PROTECTED]> writes:
> 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 j
> > 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:
> 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
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?
2. What functionality does your shmfs provide over a normal filesystem?
When pro
On Tue, May 01, 2001 at 01:50:51PM -0700, Thomas Bushnell, BSG wrote:
> Neal H Walfield <[EMAIL PROTECTED]> writes:
>
> > This patch adds a shared memory interface to the hurd.
> >
> > 2001-04-22 Neal H Walfield <[EMAIL PROTECTED]>
> >
> > * sysvshm.defs: New file. Support for System V s
Neal H Walfield <[EMAIL PROTECTED]> writes:
> This patch adds a shared memory interface to the hurd.
>
> 2001-04-22 Neal H Walfield <[EMAIL PROTECTED]>
>
> * sysvshm.defs: New file. Support for System V shared memory.
> * hurd_types.defs: Import .
> (sysvshm_t): New type.
This patch adds a shared memory interface to the hurd.
2001-04-22 Neal H Walfield <[EMAIL PROTECTED]>
* sysvshm.defs: New file. Support for System V shared memory.
* hurd_types.defs: Import .
(sysvshm_t): New type. System V shm server port.
(key_t): New type.
13 matches
Mail list logo
