Re: [PATCH] wrapper: add workaround for open() returning EINTR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> On Tue, Feb 23, 2021 at 11:43:16PM -0500, Jeff King wrote:
>
>> The workaround here is enabled all the time, without a Makefile knob,
>> since it's a complete noop if open() never returns EINTR. I did push it
>> into its own compat/ source file, though, since it has to #undef our
>> macro redirection. Putting it in a file with other code risks confusion
>> if more code is added after that #undef.
>
> Whoops, sorry, I had a last-minute change of heart here and just stuck
> it in wrapper.c with a bit of preprocessor magic to guard it. It felt
> weird having compat/open.c, when the rest of compat/ is always
> conditional on Makefile knobs. But I'm happy to go the other way if
> anybody feels strongly.

Hmph, just like other workarounds, shouldn't this be "if your
platform screws this up, define this knob to work it around"?  That
would make it fit better with the rest of compat/.

I dunno.  A no-op wrapper makes the code less transparent, which I
am somewhat unhappy.  But a wrapper that is always used even on
platforms that do not need might give us a better chance of noticing
a bug in the wrapper itself, making it less likely for us to leave
only the users of minority broken platforms behind.  So...





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux