|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] libxl: fix build on rather old systems
> On Jan 11, 2019, at 9:18 PM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
>
> On Fri, Jan 11, 2019 at 03:09:35AM -0700, Jan Beulich wrote:
>> CLONE_NEWIPC has been introduced in Linux 2.6.19 only (and into glibc
>> at around that time as well). Cope with it being undefined as well as
>> with the underlying kernel not knowing of it.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> Considering how old "old" here really means, I could understand if
>> this was rejected, in which case I'd carry a simplified version locally.
>> I don't run such old kernels together with modern Xen, but I do
>> occasionally build on such old systems.
But why do you build on it if you don’t run it?
>>
>> --- a/tools/libxl/libxl_linux.c
>> +++ b/tools/libxl/libxl_linux.c
>> @@ -334,12 +334,24 @@ int libxl__local_dm_preexec_restrict(lib
>> unsigned i;
>>
>> /* Unshare mount and IPC namespaces. These are unused by QEMU. */
>> - r = unshare(CLONE_NEWNS | CLONE_NEWIPC);
>> + r = unshare(CLONE_NEWNS);
>> if (r) {
>> - LOGE(ERROR, "libxl: Mount and IPC namespace unfailed");
>> + LOGE(ERROR, "libxl: Mount namespace unshare failed");
>> return ERROR_FAIL;
>> }
>>
>> +#ifndef CLONE_NEWIPC /* Available as of Linux 2.6.19 / glibc 2.8 */
>> +# define CLONE_NEWIPC 0x08000000
>
> I have no problem making it build with this.
>
>> +#endif
>> + r = unshare(CLONE_NEWIPC);
>> + if (r) {
>> + if (r && errno != EINVAL) {
>> + LOGE(ERROR, "libxl: IPC namespace unshare failed");
>> + return ERROR_FAIL;
>> + }
>> + LOG(WARN, "libxl: IPC namespace unshare unavailable");
>
> But I guess whether it should be allowed to continue or not is another
> question. Do we consider this IPC namespace "must-have”?
On the contrary, the mount and IPC namespaces are “might-as-well” (or perhaps,
“why-not-it-cant-hurt”).
I don’t really see any point making something build on a system that you’re not
going to run it on; but I don’t feel strongly enough to do more than say so.
I’ll leave it up to the toolstack maintainers.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |