Re: [CRIU] [PATCH 2/3] signalfd: add ability to return siginfo in araw format (v2)

[Andrew Vagin]

> > signalfd is a special descriptor, so I think it
> > is not a big deal, that it works a bit strange.
> 
> Sure, but the more we special case things, the uglier the ABI as a
> whole becomes. So special casing should be avoided as far as we can.
> 
> > If all other would
> > decides, that a new syscall is better, I will not ague.
> 
> And that's more or less how I see it too. I'm not going to argue for a
> new syscall, based on what I know so far.
> 
> Here is one idea to think about though, while more or less maintaining
> your proposed interface.
> 
> At the moment, you select signal queues in the pread() call. An
> alternative would be to do it in the signalfd() call. In other words,
> you could have the following flags used with signalfd()
> 
> SFD_RAW
> SFD_SHARED_QUEUE -- reads will be from process-wide shared signal queue
> SFD_PER_THREAD_QUEUE --reads will be from per-thread signal queue

I suggested this variant in the initial series, but then we decided to
avoid adding new flags. Oleg, what do you think about this?

> 
> Specifying both SFD_SHARED_QUEUE  and SFD_PER_THREAD_QUEUE would be
> the same as omitting them both, providing the default behavior of
> slecting from both queues.
> 
> My point here is that you can then separate the RAW functionality from
> the queue selector functionality. Now, it might be that at the moment
> you always require that if the caller specifies SFD_SHARED_QUEUE  or
> SFD_PER_THREAD_QUEUE, then they must also specify SFD_RAW. But later,
> that constraint might be relaxed, so that users could use signalfd()
> to select from a particular queue when reading traditional (non-RAW)
> signalfd_siginfo structures from a signalfd.

I am not sure, that you understood this moment correctly.
Currently SFD_RAW is independent on SFD_*_QUEUE. If signalfd is
created without SFD_RAW, pread returns signalfd_siginfo-s.
If SFD_RAW is set, read returns siginfo_t-s.

One more point for two flags is that we will be able to choose a queue
from which signals will be dequeued. Currently we can choose a queue only
for pread.

Thanks

> This does seem like a
> very sensible design optimization to make now (and an easy one, I
> would suppose). What do you think?
> 
> Cheers,
> 
> Michael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/