Re: [patch -mm 1/5] mqueue namespace : add struct mq_namespace

[Cedric Le Goater <clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>]

sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org wrote:
> Eric W. Biederman [ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org] wrote:
> | sukadev-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org writes:
> | 
> | > Cedric Le Goater [clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org] wrote:
> | > | > I think you and Eric (and I) are disagreeing about those limitations.
> | > | > You take it for granted that a sibling pidns is off limits for signals.
> | > | > But the signal wasn't sent using a pid, but using a file (in SIGIO
> | > | > case).  So since the fs was shared, the signal should be sent.  An
> | > | > event happened, and the receiver wants to know about it.
> | > | 
> | > | seen that way I agree. 
> | > | 
> | > | si_code is set to SI_MESGQ, but what do we put in si_pid ? 0 ?
> | > | 
> | > | we could use the si_errno to pass extra info, like the sending process 
> | > | lives in a // world ...
> | >
> | > Does the receiver need to know that sender is in a // world ? 

probably not. it would mean that the user is container aware. bad idea.
 
> | What is a // world ?
> 
> Parallel world/universe :-)
> 
> I am assuming Cedric used that to refer to a sibling pid ns.

yes :) 
 
Thanks !

C.