Julian Anastasov wrote:
> I'm talking about test8. __SI_CODE is in 2.4, not in 2.2.
> The handling is very different. We can't wait for si_code==SI_SIGIO
> in 2.4 anymore. SI_SIGIO is used only in 2.2:fs/fcntl.c. 2.4 stores
> POLL_xxx in si_code instead of SI_SIGIO.
Why does it do that? si
Hello,
On Wed, 20 Sep 2000, Robert H. de Vries wrote:
> > This is not needed for SI_SIGIO. It is not generated from
> >the kernel. It seems this interface is already obsoleted.
>
> I think you are mistaking. The purpose of SIGIO is to notify user programs of
> IO events detected by
On Wed, 20 Sep 2000, Julian Anastasov wrote:
>Hello,
>
>On Tue, 19 Sep 2000, Robert H. de Vries wrote:
>> It would be better to change SI_SIGIO in all the
>> include/asm-*/siginfo.h files from -5 to __SI_CODE(__SI_SIGIO, -5)
>> __SI_SIGIO would become (6 << 16).
>
> This is not needed for SI
Hello,
On Tue, 19 Sep 2000, Robert H. de Vries wrote:
> It would be better to change SI_SIGIO in all the
> include/asm-*/siginfo.h files from -5 to __SI_CODE(__SI_SIGIO, -5)
> __SI_SIGIO would become (6 << 16).
This is not needed for SI_SIGIO. It is not generated from
the kerne
Hello,
On Tue, 19 Sep 2000, Chuck Lever wrote:
> also, the test at issue here (from line 363 of kernel/signal.c):
>
> /* If this was sent by a rt mechanism, try again. */
> if (info->si_code != SI_USER) {
> ret = -
On Mon, 18 Sep 2000, Alan Cox wrote:
>> The problem is really that SI_SIGIO is negative, but it should be positive
>> to make SI_FROMUSER return false on it.
>>
>> Changing it would unfortunately break binary compatibility. This patch
>
It would be better to change SI_SIGIO in all the
include/as
On Tue, 19 Sep 2000, Julian Anastasov wrote:
> On Mon, 18 Sep 2000, Andi Kleen wrote:
>
> > > SI_SIGIO is not generated from kernel. The same is for the
> > > other SI_ consts < 0 not defined with __SI_CODE.
> >
> > Ok, then you have already broken binary compatibility between 2.2 and 2.4
>
>
Hello,
On Mon, 18 Sep 2000, Andi Kleen wrote:
> > SI_SIGIO is not generated from kernel. The same is for the
> > other SI_ consts < 0 not defined with __SI_CODE.
>
> Ok, then you have already broken binary compatibility between 2.2 and 2.4
Looking in the old kernels, it see
On Mon, Sep 18, 2000 at 08:04:21PM +0200, Julian Anastasov wrote:
>
> Hello,
>
> Everything looks good after test1 except the extra
> '<< 16' in __SI_CODE.
>
> SI_SIGIO is not generated from kernel. The same is for the
> other SI_ consts < 0 not defined with __SI_CODE.
Ok, th
On Mon, Sep 18, 2000 at 08:56:58PM +0200, Jamie Lokier wrote:
[...making SI_FROMUSER exclude SI_ASYNCIO and SI_TIMER...]
I haven't checked, but I suspect that would break the glibc user space
implementations.
Overall the concept of kernel reserved numbers doesn't make too much
sense as a API be
Linus, please think this over before applying Andi's patch.
Andi Kleen wrote:
> The problem is really that SI_SIGIO is negative, but it should be positive
> to make SI_FROMUSER return false on it.
This is an old problem. There was a thread on this topic last March.
Look for "accept() improveme
Hello,
Everything looks good after test1 except the extra
'<< 16' in __SI_CODE.
SI_SIGIO is not generated from kernel. The same is for the
other SI_ consts < 0 not defined with __SI_CODE.
We don't need to mention how broken is 2.2
Regards
--
Julian Anastasov <
On Mon, Sep 18, 2000 at 01:44:04PM +0200, Alan Cox wrote:
> > On Mon, Sep 18, 2000 at 12:34:03PM +0200, Alan Cox wrote:
> > > > The problem is really that SI_SIGIO is negative, but it should be positive
> > > > to make SI_FROMUSER return false on it.
> > > >
> > > > Changing it would unfortunate
> On Mon, Sep 18, 2000 at 12:34:03PM +0200, Alan Cox wrote:
> > > The problem is really that SI_SIGIO is negative, but it should be positive
> > > to make SI_FROMUSER return false on it.
> > >
> > > Changing it would unfortunately break binary compatibility. This patch
> >
> > Why ?
>
> If a p
On Mon, Sep 18, 2000 at 12:34:03PM +0200, Alan Cox wrote:
> > The problem is really that SI_SIGIO is negative, but it should be positive
> > to make SI_FROMUSER return false on it.
> >
> > Changing it would unfortunately break binary compatibility. This patch
>
> Why ?
If a program checks info
> The problem is really that SI_SIGIO is negative, but it should be positive
> to make SI_FROMUSER return false on it.
>
> Changing it would unfortunately break binary compatibility. This patch
Why ?
> It'll break programs that try to send SI_SIGIO (=-5) signals from userspace,
> but I think t
Linus, please think this over before applying Andi's patch.
Andi Kleen wrote:
> The problem is really that SI_SIGIO is negative, but it should be positive
> to make SI_FROMUSER return false on it.
This is an old problem. There was a thread on this topic last March.
Look for "accept() improveme
Hallo Linus,
The siginfo signal sending uses SI_FROMUSER to see if it should look
at current to check if the sending process is allowed to send the
signal. Unfortunately SI_FROMUSER() is true for SI_SIGIO signals generated
by the network stack for queued SIGIO. This leads to the SIGIO behaviour
v
18 matches
Mail list logo
