printk: modify printk interface for syslog_namespace
Subsystems (2)
Quoted 4 lines · Serge E. Hallyn
I notice that you haven't made any changes to the struct cont. I suspect this means that to-be-continued msgs from one ns can be erroneously mixed with another ns.
Yes, I confirmed this problem. There will be erroneously mixed with another ns. Thank you very much.
Quoted 5 lines
You said you don't mind putting the syslogns into the userns. If there's no reason not to do that, then we should do so as it will remove a bunch of code (plus the use of a new CLONE flag) from your patch, and the new
syslog(NEW_NS)command from mine.
I agree with you, both are removable.
Quoted 10 lines
Now IMO the ideal place for
syslog_nswould be in the devices ns, but that does not yet exist, and may never. The bonus to that would be that the consoles sort of belong there. I avoid this by not having consoles in child syslog namespaces. You put the console in the ns. I haven't looked closely enough to see if what you do is ok (will do so soon).WOuld you mind looking through my patch to see if it suffices for your needs? Where it does not, patches would be greatly appreciated if simple enough.
follow your patch, I can see inject message by "dmesg call" in container, is right? I am worry that I debug or see messages from serial ports console in some embedded system, since console belongs to init_syslog, so the message in container can`t be printed.
Quoted 4 lines
Note I'm not at all wedded to my patchset. I'm happy to go with something else entirely. My set was just a proof of concept.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 23 lines · Libo Chen
Quoted 4 lines · Serge E. Hallyn
I notice that you haven't made any changes to the struct cont. I suspect this means that to-be-continued msgs from one ns can be erroneously mixed with another ns.
Yes, I confirmed this problem. There will be erroneously mixed with another ns. Thank you very much.
Quoted 5 lines
You said you don't mind putting the syslogns into the userns. If there's no reason not to do that, then we should do so as it will remove a bunch of code (plus the use of a new CLONE flag) from your patch, and the new
syslog(NEW_NS)command from mine.I agree with you, both are removable.
Quoted 7 lines
Now IMO the ideal place for
syslog_nswould be in the devices ns, but that does not yet exist, and may never. The bonus to that would be that the consoles sort of belong there. I avoid this by not having consoles in child syslog namespaces. You put the console in the ns. I haven't looked closely enough to see if what you do is ok (will do so soon).
Quoted 5 lines
Quoted 3 lines
WOuld you mind looking through my patch to see if it suffices for your needs? Where it does not, patches would be greatly appreciated if simple enough.
follow your patch, I can see inject message by "dmesg call" in container, is right?
If I understand you right, yes.
Quoted 2 lines
I am worry that I debug or see messages from serial ports console in some embedded system, since console belongs to
init_syslog, so the message in container can`t be printed.
Sorry, I don't understand which way you're going with that. Could you rephrase? You want to prevent console messages from going to a container? (That should definately not happen) Or something else?
Quoted 2 lines
Quoted 2 lines
Note I'm not at all wedded to my patchset. I'm happy to go with something else entirely. My set was just a proof of concept.
thanks,
-serge
A message that is not in the archive (sent off-list or not yet received): [email protected]
From: Libo Chen <[email protected]>
Quoted 30 lines · Serge E. Hallyn
Quoted 23 lines · Libo Chen
Quoted 4 lines · Serge E. Hallyn
I notice that you haven't made any changes to the struct cont. I suspect this means that to-be-continued msgs from one ns can be erroneously mixed with another ns.
Yes, I confirmed this problem. There will be erroneously mixed with another ns. Thank you very much.
Quoted 5 lines
You said you don't mind putting the syslogns into the userns. If there's no reason not to do that, then we should do so as it will remove a bunch of code (plus the use of a new CLONE flag) from your patch, and the new
syslog(NEW_NS)command from mine.I agree with you, both are removable.
Quoted 7 lines
Now IMO the ideal place for
syslog_nswould be in the devices ns, but that does not yet exist, and may never. The bonus to that would be that the consoles sort of belong there. I avoid this by not having consoles in child syslog namespaces. You put the console in the ns. I haven't looked closely enough to see if what you do is ok (will do so soon).Quoted 5 lines
Quoted 3 lines
WOuld you mind looking through my patch to see if it suffices for your needs? Where it does not, patches would be greatly appreciated if simple enough.
follow your patch, I can see inject message by "dmesg call" in container, is right?
Quoted 9 lines
If I understand you right, yes.
Quoted 2 lines
I am worry that I debug or see messages from serial ports console in some embedded system, since console belongs to
init_syslog, so the message in container can`t be printed.Sorry, I don't understand which way you're going with that. Could you rephrase? You want to prevent console messages from going to a container? (That should definately not happen) Or something else?
I reviewed your patch, and found that console could only print messages belonging to init_syslog.
So the message belongs to container syslog can not be printed from console, but only "dmesg call" in user space. Is that right?
For example, the messages can not be outputed automatically from serial port as a kind of consoles on some embedded system.
And I am not sure if there are no other problems.
thanks!
Quoted 11 lines
Quoted 2 lines
Quoted 2 lines
Note I'm not at all wedded to my patchset. I'm happy to go with something else entirely. My set was just a proof of concept.
thanks,
-serge
_______________________________________________
Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 43 lines · Libo Chen
From: Libo Chen <[email protected]>
Quoted 30 lines · Serge E. Hallyn
Quoted 23 lines · Libo Chen
Quoted 4 lines · Serge E. Hallyn
I notice that you haven't made any changes to the struct cont. I suspect this means that to-be-continued msgs from one ns can be erroneously mixed with another ns.
Yes, I confirmed this problem. There will be erroneously mixed with another ns. Thank you very much.
Quoted 5 lines
You said you don't mind putting the syslogns into the userns. If there's no reason not to do that, then we should do so as it will remove a bunch of code (plus the use of a new CLONE flag) from your patch, and the new
syslog(NEW_NS)command from mine.I agree with you, both are removable.
Quoted 7 lines
Now IMO the ideal place for
syslog_nswould be in the devices ns, but that does not yet exist, and may never. The bonus to that would be that the consoles sort of belong there. I avoid this by not having consoles in child syslog namespaces. You put the console in the ns. I haven't looked closely enough to see if what you do is ok (will do so soon).Quoted 5 lines
Quoted 3 lines
WOuld you mind looking through my patch to see if it suffices for your needs? Where it does not, patches would be greatly appreciated if simple enough.
follow your patch, I can see inject message by "dmesg call" in container, is right?
Quoted 9 lines
If I understand you right, yes.
Quoted 2 lines
I am worry that I debug or see messages from serial ports console in some embedded system, since console belongs to
init_syslog, so the message in container can`t be printed.Sorry, I don't understand which way you're going with that. Could you rephrase? You want to prevent console messages from going to a container? (That should definately not happen) Or something else?
Quoted 8 lines
I reviewed your patch, and found that console could only print messages belonging to
init_syslog.So the message belongs to container syslog can not be printed from console, but only "dmesg call" in user space. Is that right?
For example, the messages can not be outputed automatically from serial port as a kind of consoles on some embedded system.
Oh, I see. I basically thought this was a feature, not a problem :) But that wasn't meant to be a core part of my patchset, rather I wasn't quite sure how best to handle it, so I put it off for later. My main concern is that if consoles in containers are supported, this must NOT lead to kernel module loading from the container.
Quoted 1 line
And I am not sure if there are no other problems.
Ok, I will write a new patch which would (a) try to address the consoles,
(b) move the syslogns into the user_ns (making it no longer a syslog_ns), and (c) adding some users of ns_printk (borrowing the ones from your set for starters).
thanks,
-serge