Hi,
Michael Banck tried to build my crappy patch and found a couple of
omissions. Thanks to him!
Here is a new patch. I moved sysvshm to hurd/, because it is not a
replacement for generic stuff, but an extension of the internal
interfaces. I didn't test if it works to have the files there, but
At Tue, 12 Jul 2005 00:20:05 +0200,
Marcus [EMAIL PROTECTED] de wrote:
>
> Below is a temporary patch for ext2fs to support the bit used for
> nattch. Only few programs will require this, though.
groan.
2005-03-09 Marcus Brinkmann <[EMAIL PROTECTED]>
* pager.c: Include .
At Mon, 11 Jul 2005 23:52:35 +0200,
Marcus [EMAIL PROTECTED] de wrote:
> this patch is for glibc, but it needs to get more testing before it
> can go in. Please give it a good beating.
Here is a resent in a more sane format. I have no idea why it didn't
do this the first time around---it's defin
At Mon, 11 Jul 2005 23:52:35 +0200,
Marcus [EMAIL PROTECTED] de wrote:
>
> Hi,
>
> this patch is for glibc, but it needs to get more testing before it
> can go in. Please give it a good beating.
I should add some information on how to test this.
The shm node is /dev/shm. Normally, tmpfs is in
Hi,
this patch is for glibc, but it needs to get more testing before it
can go in. Please give it a good beating.
This patch adds System V Shared Memory support to the GNU Hurd.
There is a small extension to the filesystem interface that allows the
filesystem to report to the application if
Hi,
> At Wed, 9 Feb 2005 13:03:17 -0500,
> Barry deFreese wrote:
> > Roland, marcus, etc, can someone comment on the following patch neal made
> > two years ago for sysv shared memory?
> >
> > http://lists.gnu.org/archive/html/bug-hurd/2002-04/msg00288.html
Here is a list of issues I found, and
On Mon, Apr 15, 2002 at 05:11:17PM -0400, Neal H Walfield wrote:
> 2002-04-15 Neal H Walfield <[EMAIL PROTECTED]>
>
> * sysdeps/mach/hurd/Makefile (sysdep_routines) [$(subdir) =
> sysvipc]: Add sysvshm.
I notice conversation has stalled on this. Is it at a point where you
re
Neal,
> My problem is not so much with setting the owner and changing the file
> mode, but rather, using the author field for the creator uid and the
> flags for the pid of the last operation, etc. Please understand that
> I was sloppy as it was not my intention to decide what to overload
> with
> I have a couple of questions on your implementation, however, that I
> just
> don't understand. You commented out the entire 'IPC_SET' case from the
> shmctl function. I'm not clear on why you did this. How else can we
> enforce permissions on shared memory segments? I'm not sure why you
> o
Neal,
Thanks for doing the cleanup. I'll try to study your changes and
improve
next time. I'll concede that there was probably a logic error or two
in there and I didn't throw any mutexes in for thread safety. My fault.
The file 'list.h' comes from the Linux source and I like to use it
becuase
I have rewritten your patch. There were a variety of problems with
it.:
o Coding and logic errors.
o Not robust.
o Not thread safe.
o You should use the libc functions, not hurd rpcs.
o You need to use the GNU coding standards.
o You need to follow the glibc conventions
o Where did
mctl.c
which
implement the required functionality in terms of mmap, __file* and
__io*.
I settled on the mapping shared memory ID = file inode as obtained from
stat.
As far as testing goes, I ran Neal's tests as well as a few others I
cooked up. I also managed to run the Gimp and created an im
Neal did something on this before. Look through the bug-hurd and
hurd-devel archives for "System V Shared Memory" (or just google for that
plus hurd). I think the conclusion of that was he had a proposal that used
existing filesystem calls to implement almost everything. I don&#x
> > 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]>
> >
> >
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 .
This patch adds a shared memory filesystem to the Hurd based on the
recently proposed interface. This code is based off of tmpfs. It
allows conformance to SUSv2 except where noted (and where I have made
mistakes).
I have made the assumption that standard conformance will occur in libc
and, as s
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): Ne
27 matches
Mail list logo
