Extend sys_clone and sys_unshare system calls API

I use the last bit in the clone_flags for CLONE_LONGARG. When set it will denote that the child_tidptr is not a pointer to a tid storage, but the pointer to the struct long_clone_struct which currently looks like this:

Hi, Pavel,

[Adding Ulrich]

Quoted 4 lines

I use the last bit in the clone_flags for CLONE_LONGARG. When set it will denote that the child_tidptr is not a pointer to a tid storage, but the pointer to the struct long_clone_struct which currently looks like this:

I'm probably just totally off the deep end, but something did occur to
me: this looks an awful lot like a special version of the sys_indirect() idea. Unless it has been somehow decided that sys_indirect() is the wrong idea, might it not be better to look at making that interface solve the extended clone() problem as well?

jon

Hi, Pavel,

[Adding Ulrich]

Quoted 4 lines

I use the last bit in the clone_flags for CLONE_LONGARG. When set it will denote that the child_tidptr is not a pointer to a tid storage, but the pointer to the struct long_clone_struct which currently looks like this:

I'm probably just totally off the deep end, but something did occur to
me: this looks an awful lot like a special version of the sys_indirect() idea. Unless it has been somehow decided that sys_indirect() is the wrong idea, might it not be better to look at making that interface solve the extended clone() problem as well?

Quoted 8 lines · Jonathan Corbet

Hi, Pavel,

[Adding Ulrich]

Quoted 4 lines

I use the last bit in the clone_flags for CLONE_LONGARG. When set it will denote that the child_tidptr is not a pointer to a tid storage, but the pointer to the struct long_clone_struct which currently looks like this:

Quoted 5 lines

I'm probably just totally off the deep end, but something did occur to
me: this looks an awful lot like a special version of the sys_indirect() idea. Unless it has been somehow decided that sys_indirect() is the wrong idea, might it not be better to look at making that interface solve the extended clone() problem as well?

Nah, just put an XML parser into the kernel to have the form match the contents...

Al "perhaps we should newgroup alt.tasteless.api for all that stuff" Viro

Nah, just put an XML parser into the kernel to have the form match the contents...

Al "perhaps we should newgroup alt.tasteless.api for all that stuff" Viro

Heh, indeed. But we do seem to have a recurring problem of people wanting to extend sys_foo() beyond the confines of its original API. I've observed a few ways of doing that:

- create sys_foo2() (or sys_foo64(), or sys_fooat(), or sys_pfoo(), or...) and add the new stuff there.

The first approach has traditionally been the most popular. If we have a consensus that this is the way to extend system calls in the future, it would be nice to set that down somewhere. We could avoid a lot of API blind alleys that way.

There's only one bit in the clone_flags left, so we won't be able to create more namespaces after we make it busy. Besides, for checkpoint/restart jobs we might want to create tasks with given pids (virtual of course). And nobody knows for sure what else might be required from clone() in the future.

This is an attempt to create a extendable API for clone and unshare. Actually this patch is a request for comment about the overall design. If it will turn out to "look good", then we'll select some better names for new flag and data types.

I use the last bit in the clone_flags for CLONE_LONGARG. When set it will denote that the child_tidptr is not a pointer to a tid storage, but the pointer to the struct long_clone_struct which currently looks like this:

struct long_clone_arg {
	int size;
};

Quoted 16 lines · Pavel Emelyanov

There's only one bit in the clone_flags left, so we won't be able to create more namespaces after we make it busy. Besides, for checkpoint/restart jobs we might want to create tasks with given pids (virtual of course). And nobody knows for sure what else might be required from clone() in the future.

This is an attempt to create a extendable API for clone and unshare. Actually this patch is a request for comment about the overall design. If it will turn out to "look good", then we'll select some better names for new flag and data types.

I use the last bit in the clone_flags for CLONE_LONGARG. When set it will denote that the child_tidptr is not a pointer to a tid storage, but the pointer to the struct long_clone_struct which currently looks like this:

Quoted 3 lines

struct long_clone_arg {
	int size;
};

Ugly as night, I'd say. (Al said it better). What about just adding clone2 syscall, that takes u64?

yes but we would need more something like :

long sys_clone64(unsigned long flags_high, unsigned long flag_low)

if we want the syscall to be supported on 32bit arch. clone2 is also being used on ia64 already.

Quoted 6 lines · Cedric Le Goater

yes but we would need more something like :

long sys_clone64(unsigned long flags_high, unsigned long flag_low)

if we want the syscall to be supported on 32bit arch. clone2 is also being used on ia64 already.

Did we decide not to do something with a variable number of arguments?

	sys_clonefoo(unsigned long *flags, int len);

Quoted 1 line

Did we decide not to do something with a variable number of

arguments?

Quoted 2 lines

      sys_clonefoo(unsigned long *flags, int len);

That is evil, because that means strace can no longer reliably print flags being used (for example).

Quoted 5 lines · Pavel Machek

Quoted 1 line

Did we decide not to do something with a variable number of

arguments?

Quoted 2 lines

      sys_clonefoo(unsigned long *flags, int len);

Quoted 2 lines

That is evil, because that means strace can no longer reliably print flags being used (for example).

Ahhh. Just like it can't print strings for "buf"?

write(int fd, char *buf, size_t len)

Man, strace is stupid! ;)

If that's *really* a concern, why don't we just pass, say 4 or 5 longs in:

	sys_clonebig(unsigned long flags0, unsigned long flags1,
		     unsigned long flags2, unsigned long flags3);