On 10/25/24 2:09 PM, Lorenzo Stoakes wrote:
On Fri, Oct 25, 2024 at 01:31:49PM -0700, John Hubbard wrote:
On 10/25/24 12:49 PM, Lorenzo Stoakes wrote:
On Fri, Oct 25, 2024 at 11:44:34AM -0700, John Hubbard wrote:
On 10/25/24 11:38 AM, Pedro Falcato wrote:
On Fri, Oct 25, 2024 at 6:41 PM John Hubbard <jhubbard@xxxxxxxxxx> wrote:
...
I'll admit to being easily cowed by "you're breaking userspace" arguments.
Even when they start to get rather absurd. Because I can't easily tell where
the line is.
Maybe "-std=c89 -pedantic" is on the other side of the line. I'd like it
to be! :)
Well, apparently not...
Why not? Your arguments are clear and reasonable. Why shouldn't they prevail?
Please don't think that I have some sort of firm position here. I'm simply
looking for the right answer. And if that's different than something I
proposed earlier, no problem. The best answer should win.
...
The bike shed should be blue! Wait no no, it should be red... Hang on
yellow yes! Yellow's great!
Putting a header in the right location, so as to avoid breakage here or
there, is not bikeshedding. Sorry.
There are 312 uses of "static inline" already in UAPI headers, not all
quite as obscure as claimed.
OK, good. Let's lead with that. It seems very clear, then, that a new one
won't cause a problem.
Specifically requiring me and only me to support ansi C89 for a theorised
scenario is in my opinion bikeshedding, but I don't want to get into an
argument about something so petty :)
An argument about the definition of bikeshedding sounds delightfully
recursive, but yes, let's not. :)
...
ANyway if you guys feel strong enough about this, I'll respin again and
just open-code this trivial check where it's used.
No strong feelings, just hoping to help make a choice that gets you
closer to getting your patches committed.
I mean, you are saying I am breaking things and implying the series is
blocked on this, that sounds like a strong opinion, but again I'm not going
to argue.
Actually, Pedro's request kicked this off, and I was hoping to dismiss
it--again, in order to help move things along. My opinion is that we
should shun ancient toolchains and ancient systems whenever possible.
Somehow that got turned into "I'm trying to block the patchset". Really,
whatever works, follows The Rules (whatever we eventually understand
them to be), and doesn't cause someone *else* to come out of the
woodwork and claim a problem, is fine with me.
As with the requirement that I, only for my part of the change, must fix up
test header import, while I disagree I should be doing the fix, I did it
anyway as I am accommodating and reasonable.
I agree that pre-existing problems in selftests should not be your
problem.
By the way, I'm occasionally involved in helping fix up various
selftest-related problems, especially when they impact mm. Send me a
note if you have anything in mind that ought to be fixed up, I might be
able to help head off future grief in that area.
So fine - I'll respin and just open-code this as it's trivial and there's
no (other) sensible place to put it anyway.
A P.S. though - a very NOT theoretical issue with userspace is the import
of linux/fcntl.h in pidfd.h which seems to me to have been imported solely
for the kernel's sake.
A gentle suggestion (it seems I can't win - gentle suggestions are ignored,
tongue-in-cheek parody is taken to be mean... but anyway) is to do
Actually, these come across as sarcasm, especially in the context of
these emails that show you are becoming quite distraught.
I've met you several times at the conferences. We get along well. And
your work is top notch. So please consider that I'm very much supportive
of you and your work here.
I'm still trying to understand why you are recently sending these very
strong emails (Vlastimil also took some heat), but I see that you also
mentioned some long hours.
If my feedback is making things worse here, I'll try to adjust.
Selftests in general are a frustrating area.
thanks,
--
John Hubbard
something like:
#ifdef __KERNEL__
#include <linux/fcntl.h>
#else
#include <fcntl.h>
#endif
At the top of the pidfd.h header. This must surely sting a _lot_ of people
in userland otherwise.
But this is out of scope for this change.
