Marcus's suggestions sound fine to me. Any of those paths require some work.
Using proxy objects is the only nice thing there, but has the kernel work.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Marcus Brinkmann wrote:
Hi,
I have some patches now (that I have to clean up and further test)
that do sysv shm to the extent which is required by applications
(except those rare ones which check nattch == 1 or something).
The requirements for the underlying filesystem are:
* Use of --inherit-dir-g
Hi,
I have some patches now (that I have to clean up and further test)
that do sysv shm to the extent which is required by applications
(except those rare ones which check nattch == 1 or something).
The requirements for the underlying filesystem are:
* Use of --inherit-dir-group to get SysV sema
At Tue, 1 Mar 2005 13:11:03 -0800 (PST),
Roland McGrath wrote:
>
> >IMMAP0 IMMAP1 Meaning
> > 0 0 Not supported.
> > 1 0 Exactly no user.
> > 0 1 Maybe only one user (or more).
> > 1 1 Definitely more than one user.
It turns out that we can not actually det
>IMMAP0 IMMAP1 Meaning
> 0 0 Not supported.
> 1 0 Exactly no user.
> 0 1 Maybe only one user (or more).
> 1 1 Definitely more than one user.
That is fine by me, but in that case the two bits are not indicating
independent things. So it should be a mask of
At Mon, 28 Feb 2005 14:35:14 -0800 (PST),
Roland McGrath wrote:
>
> > Ok. Should we change diskfs_get_filemap to accept a flag that says we do
> > not want to create the memory object if it doesn't exist already? That
> > seems to be an important optimization to me if we call it in io_stat.
>
>
> Ok. Should we change diskfs_get_filemap to accept a flag that says we do
> not want to create the memory object if it doesn't exist already? That
> seems to be an important optimization to me if we call it in io_stat.
diskfs shouldn't be assuming anything about the filesystem's memory object
p
Roland McGrath wrote:
#define S_IMAPPED0001 /* Might be mmap'd. */
#define S_IMAPPEDM 0002 /* Might be mmap'd more than once. */
Actually, for compatibility purposes it's better to reverse the sense of
those bits. i.e.
#define S_IMMAP00001 /* Definitely
> #define S_IMAPPED0001 /* Might be mmap'd. */
> #define S_IMAPPEDM 0002 /* Might be mmap'd more than once. */
Actually, for compatibility purposes it's better to reverse the sense of
those bits. i.e.
#define S_IMMAP00001 /* Definitely no mmap's to this.
> our reference is not a reference to the shared memory object, but to the
> filenode.
> So we need three states: no senders, one, or many (the "one" is useful
> if we want to know
> if we are the only mapper).
>
> This is as much as we need to make users of nattach in SysV SHM happy.
> We know
Roland McGrath wrote:
This is a real questionable interface to add. "Number of send rights" is
really not an appropriate notion for the Hurd protocol object abstraction.
It doesn't even necessarily mean very much useful even in a Mach-based
context. It may not be really accurate to say anything o
This is a real questionable interface to add. "Number of send rights" is
really not an appropriate notion for the Hurd protocol object abstraction.
It doesn't even necessarily mean very much useful even in a Mach-based
context. It may not be really accurate to say anything other than yes/no
to "a
OK, I tied Marcus down here in Brussels and forced him to start on SYSV
shm support. Tomorrow night when he falls asleep I will steal his
laptop and commit it unless I hear too much bitching!! :-)
Here is our cool patch:
This patch adds a new interface io_get_refs which returns the number of
ex
13 matches
Mail list logo