> You can get the Linux special behaviour to be able to attach to a
> removed segment by its shmid by passing the file descriptor for the
> posix shm from the attached process to the attaching process.
>
> Did I miss something?
Not that I've ever used 8)
-
To unsubscribe from this list: send
Alan Cox <[EMAIL PROTECTED]> writes:
> There are fundmental things shm* can do that mmap cannot. Does posix
> shm handle those (leaving segments alive but unattached being the
> obvious one)
Yes:
shmget == shm_open (+ ftruncate(fd, size))
shmat== mmap (0,
> > So should we go for SUSv2?
>
> No.
> I regard shm* as obsolete. New programs will probably not use it.
> So, the less we change the better. Moreover, the SUSv2 text is broken.
There are fundmental things shm* can do that mmap cannot. Does posix shm
handle those (leaving segments alive but
On Thu, Dec 28, 2000 at 01:01:53PM +0100, Christoph Rohland wrote:
> > My first reaction is that this patch is broken, since
> > one usually specifies size 0 in shmget to get an existing
> > bit of shared memory
> That's still covered: The check is moved out of shmget into the create
>
Andries Brouwer <[EMAIL PROTECTED]> writes:
> On Wed, Dec 27, 2000 at 01:16:44PM -0200, Marcelo Tosatti wrote:
> I happen to see this post, but have not followed earlier discussion.
> See a patch fragment
(The patch does not show a lot of context. You should look at the
whole files)
>
>
Andries Brouwer [EMAIL PROTECTED] writes:
On Wed, Dec 27, 2000 at 01:16:44PM -0200, Marcelo Tosatti wrote:
I happen to see this post, but have not followed earlier discussion.
See a patch fragment
(The patch does not show a lot of context. You should look at the
whole files)
On Thu, Dec 28, 2000 at 01:01:53PM +0100, Christoph Rohland wrote:
My first reaction is that this patch is broken, since
one usually specifies size 0 in shmget to get an existing
bit of shared memory
That's still covered: The check is moved out of shmget into the create
function. So you
So should we go for SUSv2?
No.
I regard shm* as obsolete. New programs will probably not use it.
So, the less we change the better. Moreover, the SUSv2 text is broken.
There are fundmental things shm* can do that mmap cannot. Does posix shm
handle those (leaving segments alive but
Alan Cox [EMAIL PROTECTED] writes:
There are fundmental things shm* can do that mmap cannot. Does posix
shm handle those (leaving segments alive but unattached being the
obvious one)
Yes:
shmget == shm_open (+ ftruncate(fd, size))
shmat== mmap (0, size,
You can get the Linux special behaviour to be able to attach to a
removed segment by its shmid by passing the file descriptor for the
posix shm from the attached process to the attaching process.
Did I miss something?
Not that I've ever used 8)
-
To unsubscribe from this list: send the
On Wed, Dec 27, 2000 at 01:16:44PM -0200, Marcelo Tosatti wrote:
>
> On 27 Dec 2000, Christoph Rohland wrote:
>
> > Hi Linus,
> >
> > The following patchlet bring the handling of shmget with size zero
> > back to the 2.2 behaviour. There seem to be programs out, which
> > (erroneously) rely on
Marcelo Tosatti <[EMAIL PROTECTED]> writes:
> On 27 Dec 2000, Christoph Rohland wrote:
> > The following patchlet bring the handling of shmget with size zero
> > back to the 2.2 behaviour. There seem to be programs out, which
> > (erroneously) rely on this.
>
> Just curiosity: do you know if
On 27 Dec 2000, Christoph Rohland wrote:
> Hi Linus,
>
> The following patchlet bring the handling of shmget with size zero
> back to the 2.2 behaviour. There seem to be programs out, which
> (erroneously) rely on this.
Just curiosity: do you know if any specification (POSIX?) defines this
Dave Gilbert <[EMAIL PROTECTED]> writes:
> I think I've come to the conclusion that Xine does not in the case
> I've found, rely on this - it is a separate bug related to Xv
> telling xine that it needs 0 bytes.
Yes, but this bug did not show on 2.2. It simply failed in shmget.
Probably it
On 27 Dec 2000, Christoph Rohland wrote:
> Hi Linus,
>
> The following patchlet bring the handling of shmget with size zero
> back to the 2.2 behaviour. There seem to be programs out, which
> (erroneously) rely on this.
Hi Christoph,
I think I've come to the conclusion that Xine does not in
Hi Linus,
The following patchlet bring the handling of shmget with size zero
back to the 2.2 behaviour. There seem to be programs out, which
(erroneously) rely on this.
Greetings
Christoph
diff -uNr c/include/linux/shm.h c1/include/linux/shm.h
--- c/include/linux/shm.h
Hi Linus,
The following patchlet bring the handling of shmget with size zero
back to the 2.2 behaviour. There seem to be programs out, which
(erroneously) rely on this.
Greetings
Christoph
diff -uNr c/include/linux/shm.h c1/include/linux/shm.h
--- c/include/linux/shm.h
On 27 Dec 2000, Christoph Rohland wrote:
Hi Linus,
The following patchlet bring the handling of shmget with size zero
back to the 2.2 behaviour. There seem to be programs out, which
(erroneously) rely on this.
Hi Christoph,
I think I've come to the conclusion that Xine does not in the
Dave Gilbert [EMAIL PROTECTED] writes:
I think I've come to the conclusion that Xine does not in the case
I've found, rely on this - it is a separate bug related to Xv
telling xine that it needs 0 bytes.
Yes, but this bug did not show on 2.2. It simply failed in shmget.
Probably it makes
On 27 Dec 2000, Christoph Rohland wrote:
Hi Linus,
The following patchlet bring the handling of shmget with size zero
back to the 2.2 behaviour. There seem to be programs out, which
(erroneously) rely on this.
Just curiosity: do you know if any specification (POSIX?) defines this
Marcelo Tosatti [EMAIL PROTECTED] writes:
On 27 Dec 2000, Christoph Rohland wrote:
The following patchlet bring the handling of shmget with size zero
back to the 2.2 behaviour. There seem to be programs out, which
(erroneously) rely on this.
Just curiosity: do you know if any
On Wed, Dec 27, 2000 at 01:16:44PM -0200, Marcelo Tosatti wrote:
On 27 Dec 2000, Christoph Rohland wrote:
Hi Linus,
The following patchlet bring the handling of shmget with size zero
back to the 2.2 behaviour. There seem to be programs out, which
(erroneously) rely on this.
22 matches
Mail list logo
