This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Simplify sendmmsg code



On 12/05/2017 06:17, Florian Weimer wrote:
> On 05/10/2017 02:14 PM, Adhemerval Zanella wrote:
>> Indeed the emulation brings a lot of issue, but it allows us to use the system
>> specific syscalls on generic code without relying on additional checks for
>> functionality existence.  However I think we can to Linux optimizations in
>> generic code less intrusive way if necessary with a different approach, maybe
>> by implementing the functionally in a more constrained way and reimplement
>> in the target system.
> 
> Yes, optimizations are fine.  But I think it is wrong to expose the fallback implementation to applications as an implementation of the system call, when in fact the semantics are different.  Every time we do this, it comes back to haunt as eventually (see posix_fallocate or euidaccess for examples).

I tend to agree with you, but I think we should at least lay ground on how we 
will handle possible future GNU extensions and/or new syscall wrapper.  My 
understanding is we should aim to provide fallback implementation iff the
semantics of the implementation matches the one we aim to emulate, otherwise
we should return ENOTSUP/EINVAL.

That is what I am aiming for p{read,write}v2 and the p{read,write}v.  For 
former my current proposal returns ENOTSUPP for all flags different than
zero and for former we still use p{read,pwrite} with an aligned buffer
(p{read,write} may still be emulated, although not current in Linux).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]