Re: [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets

["H. Peter Anvin" <hpa@zytor.com>]

Ulrich Drepper wrote:
> > And I agree with all of the objections raised by both H. Pater Anvin
> > and Eric Dumazet.
>
> Eric had no arguments and HP's comments lack a viable alternative proposal.

That's only because you're being, deliberately or accidentally, vague 
about what your actual (as opposed to imagined) requirements are.

The only thing concrete that I have seen is that the limitation to 6 
system call arguments is insufficient.  This is clearly true, as 
evidenced by things like pselect.  To which I responded that I'd *much* 
rather see a systematized way to handle the the system call ABI beyond 6 
arguments... the system call interface is a calling convention and 
should be treated as such, and the last thing we need is something that 
ends up looking like the MS-DOS kernel interface where every call has 
its own random convention.

The easy answer, to repeat myself, is to adopt the convention that for > 
6 system calls, the sixth argument register carries a pointer to the 6+ 
arguments.  This has minor performance disadvantages on platforms which 
use the stack for return addresses AND uses exactly six registers for 
arguments (a surprisingly common number.)  On those platforms we have 
the option of either take the extra user space copies, or pick a method 
for passing the in-memory copy in a pointer.

If the whole thing about "a dozen new [system calls]" then a dozen 
system calls added to the existing tables are better than this mess.

Inside the kernel, a lot of things could be cleaned up substantially by 
automating the generation of stubs, where necessary.  I did a lot of 
work in klibc to automatically generate stubs of various sorts; some of 
that work may be possible to re-use.

	-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/