On Fri, 20 Mar 2020 19:17:46 +0100 Toke Høiland-Jørgensen wrote: > Jakub Kicinski <kuba@xxxxxxxxxx> writes: > > >> > If we do please run this thru checkpatch, set .strict_start_type, > >> > >> Will do. > >> > >> > and make the expected fd unsigned. A negative expected fd makes no > >> > sense. > >> > >> A negative expected_fd corresponds to setting the UPDATE_IF_NOEXIST > >> flag. I guess you could argue that since we have that flag, setting a > >> negative expected_fd is not strictly needed. However, I thought it was > >> weird to have a "this is what I expect" API that did not support > >> expressing "I expect no program to be attached". > > > > I see it now, not entirely unreasonable. > > > > Why did you choose to use the FD rather than passing prog id directly? > > Is the application unlikely to have program ID? > > For consistency with other APIs. Seems the pattern is generally that > userspace supplies program FDs, and the kernel returns IDs, no? This API just predates the IDs. "From kernel" API was added when IDs already existed. I'd think for cmpxchg it may be easier if user space provides ID directly, since it's what it get returned.
