[klibc] [patch] s390: vfork support

[H. Peter Anvin]

Heiko Carstens wrote:
>>
>> On that subject, though, I assume s390[x] is going to need arch-specific code
>> (or a stub generator overhaul) to support pselect()?  Or does the kernel
>> automatically grab the sixth argument (or seventh if it have sys_pselect7)
>> from the user stack (which isn't a bad way to deal with it)?
> 
> s390 has two ways to deal with syscalls with six parameters: the old one
> is to put all six arguments in a structure and pass a pointer to the
> structure with the syscall (see e.g. s390 mmap implementation).
> The new one is to put the additional parameters in registers too, that
> is %r7 for the 6th argument.
> And yes, you're right. We need special arch code for the following syscalls:
> sys_futex (not supported in klibc, yet(?))
> sys_pselect6
> sys_splice
> sys_sync_file_range (only on s390 because of the off_t arguments)
> 

Many of the other platforms simply have a syscall pattern which sets up 
all six registers, even if some of them are not used.  This usually 
forces them to have a separate vfork function, though.

> Btw.: in usr/klibc/syscalls/Kbuild you just changed:
> 
> -                                -ansi -x assembler-with-cpp -E -o $@ $<
> +                                -ansi -x c++ -E -o $@ $<
> 
> This kills my crosscompiler which worked for ages:
> "s390x-ibm-linux-gcc: language c++ not recognized"
> 
> Guess I need to rebuild the compiler, but: is this change really necessary?
> Until now it was possible to build a kernel without c++ support...
> 

I've dropped this in favour of -x c.  We'll see if this causes an issue 
for anyone; if so, I'll have to do something more radical.

	-hpa