On Wed, Oct 20, 2021 at 11:35:27AM -0600, Jens Axboe wrote:
On 10/20/21 11:30 AM, Christoph Hellwig wrote:
quoted
On Wed, Oct 20, 2021 at 10:49:07AM -0600, Jens Axboe wrote:
quoted
It's not used for anything, and we're wasting time passing in zeroes
where we could just ignore it instead. Update all ki_complete users in
the kernel to drop that last argument.
The exception is the USB gadget code, which passes in non-zero. But
since nobody every looks at ret2, it's still pointless.
Yes, the USB gadget passes non-zero, and aio passes that on to
userspace. So this is an ABI change. Does it actually matter?
I don't know, but you could CC the relevant maintainers and list
to try to figure that out.
True, guess it does go out to userspace. Greg, is anyone using
it on the userspace side?
I really do not know (adding linux-usb@vger) My interactions with the
gadget code have not been through the aio api, thankfully :)
Odds are it's fine, I think that something had to be passed in there so
that was chosen? If the aio code didn't do anything with it, I can't
see where the gadget code gets it back at anywhere, but I might be
looking in the wrong place.
Anyone else here know?
thanks,
greg k-h
From: John Keeping <hidden> Date: 2021-10-21 16:40:38
On Wed, 20 Oct 2021 19:49:07 +0200
Greg Kroah-Hartman [off-list ref] wrote:
On Wed, Oct 20, 2021 at 11:35:27AM -0600, Jens Axboe wrote:
quoted
On 10/20/21 11:30 AM, Christoph Hellwig wrote:
quoted
On Wed, Oct 20, 2021 at 10:49:07AM -0600, Jens Axboe wrote:
quoted
It's not used for anything, and we're wasting time passing in zeroes
where we could just ignore it instead. Update all ki_complete users in
the kernel to drop that last argument.
The exception is the USB gadget code, which passes in non-zero. But
since nobody every looks at ret2, it's still pointless.
Yes, the USB gadget passes non-zero, and aio passes that on to
userspace. So this is an ABI change. Does it actually matter?
I don't know, but you could CC the relevant maintainers and list
to try to figure that out.
True, guess it does go out to userspace. Greg, is anyone using
it on the userspace side?
I really do not know (adding linux-usb@vger) My interactions with the
gadget code have not been through the aio api, thankfully :)
Odds are it's fine, I think that something had to be passed in there so
that was chosen? If the aio code didn't do anything with it, I can't
see where the gadget code gets it back at anywhere, but I might be
looking in the wrong place.
Anyone else here know?
On Wed, 20 Oct 2021 19:49:07 +0200
Greg Kroah-Hartman [off-list ref] wrote:
quoted
On Wed, Oct 20, 2021 at 11:35:27AM -0600, Jens Axboe wrote:
quoted
On 10/20/21 11:30 AM, Christoph Hellwig wrote:
quoted
On Wed, Oct 20, 2021 at 10:49:07AM -0600, Jens Axboe wrote:
quoted
It's not used for anything, and we're wasting time passing in zeroes
where we could just ignore it instead. Update all ki_complete users in
the kernel to drop that last argument.
The exception is the USB gadget code, which passes in non-zero. But
since nobody every looks at ret2, it's still pointless.
Yes, the USB gadget passes non-zero, and aio passes that on to
userspace. So this is an ABI change. Does it actually matter?
I don't know, but you could CC the relevant maintainers and list
to try to figure that out.
True, guess it does go out to userspace. Greg, is anyone using
it on the userspace side?
I really do not know (adding linux-usb@vger) My interactions with the
gadget code have not been through the aio api, thankfully :)
Odds are it's fine, I think that something had to be passed in there so
that was chosen? If the aio code didn't do anything with it, I can't
see where the gadget code gets it back at anywhere, but I might be
looking in the wrong place.
Anyone else here know?
I really doubt anyone uses io_event::res2 with FunctionFS gadgets. The
examples in tools/usb/ffs-aio-example/ either check just "res" or ignore
the status completely.
The only other program I can find using aio FunctionFS is adbd which
also checks res and ignores res2 [1]. Other examples I know of just use
synchronous I/O.
We might consider doing a separate change to just skip status reporting,
and then once a few releases have passed and if nobody has complained,
then we can drop it entirely. If we do it separately, it'd be an easy
revert of just that part if we do run into trouble.
At least for now we'll just have the one argument bundling the two parts
for aio, so there's not a great need to eliminate the status thing on
the USB gadget side. But if it is unused, then it should get removed
regardless.
--
Jens Axboe
On Wed, 20 Oct 2021 19:49:07 +0200
Greg Kroah-Hartman [off-list ref] wrote:
quoted
On Wed, Oct 20, 2021 at 11:35:27AM -0600, Jens Axboe wrote:
quoted
On 10/20/21 11:30 AM, Christoph Hellwig wrote:
quoted
On Wed, Oct 20, 2021 at 10:49:07AM -0600, Jens Axboe wrote:
quoted
It's not used for anything, and we're wasting time passing in zeroes
where we could just ignore it instead. Update all ki_complete users in
the kernel to drop that last argument.
The exception is the USB gadget code, which passes in non-zero. But
since nobody every looks at ret2, it's still pointless.
Yes, the USB gadget passes non-zero, and aio passes that on to
userspace. So this is an ABI change. Does it actually matter?
I don't know, but you could CC the relevant maintainers and list
to try to figure that out.
True, guess it does go out to userspace. Greg, is anyone using
it on the userspace side?
I really do not know (adding linux-usb@vger) My interactions with the
gadget code have not been through the aio api, thankfully :)
Odds are it's fine, I think that something had to be passed in there so
that was chosen? If the aio code didn't do anything with it, I can't
see where the gadget code gets it back at anywhere, but I might be
looking in the wrong place.
Anyone else here know?
I really doubt anyone uses io_event::res2 with FunctionFS gadgets. The
examples in tools/usb/ffs-aio-example/ either check just "res" or ignore
the status completely.
The only other program I can find using aio FunctionFS is adbd which
also checks res and ignores res2 [1]. Other examples I know of just use
synchronous I/O.
So is there consensus on the USB side that we can just fill res2 with
zero? The single cases that does just do res == res2 puts the error
in res anyway, which is what you'd expect.
If so, then I do think that'd be cleaner than packing two values into
a u64.
--
Jens Axboe
On Fri, Oct 22, 2021 at 09:44:32AM -0600, Jens Axboe wrote:
On 10/21/21 10:40 AM, John Keeping wrote:
quoted
On Wed, 20 Oct 2021 19:49:07 +0200
Greg Kroah-Hartman [off-list ref] wrote:
quoted
On Wed, Oct 20, 2021 at 11:35:27AM -0600, Jens Axboe wrote:
quoted
On 10/20/21 11:30 AM, Christoph Hellwig wrote:
quoted
On Wed, Oct 20, 2021 at 10:49:07AM -0600, Jens Axboe wrote:
quoted
It's not used for anything, and we're wasting time passing in zeroes
where we could just ignore it instead. Update all ki_complete users in
the kernel to drop that last argument.
The exception is the USB gadget code, which passes in non-zero. But
since nobody every looks at ret2, it's still pointless.
Yes, the USB gadget passes non-zero, and aio passes that on to
userspace. So this is an ABI change. Does it actually matter?
I don't know, but you could CC the relevant maintainers and list
to try to figure that out.
True, guess it does go out to userspace. Greg, is anyone using
it on the userspace side?
I really do not know (adding linux-usb@vger) My interactions with the
gadget code have not been through the aio api, thankfully :)
Odds are it's fine, I think that something had to be passed in there so
that was chosen? If the aio code didn't do anything with it, I can't
see where the gadget code gets it back at anywhere, but I might be
looking in the wrong place.
Anyone else here know?
I really doubt anyone uses io_event::res2 with FunctionFS gadgets. The
examples in tools/usb/ffs-aio-example/ either check just "res" or ignore
the status completely.
The only other program I can find using aio FunctionFS is adbd which
also checks res and ignores res2 [1]. Other examples I know of just use
synchronous I/O.
So is there consensus on the USB side that we can just fill res2 with
zero? The single cases that does just do res == res2 puts the error
in res anyway, which is what you'd expect.
If so, then I do think that'd be cleaner than packing two values into
a u64.
I think yes, we should try that, and if something breaks, be ready to
provide a fix for it.
thanks,
greg k-h
On Fri, Oct 22, 2021 at 09:44:32AM -0600, Jens Axboe wrote:
quoted
On 10/21/21 10:40 AM, John Keeping wrote:
quoted
On Wed, 20 Oct 2021 19:49:07 +0200
Greg Kroah-Hartman [off-list ref] wrote:
quoted
On Wed, Oct 20, 2021 at 11:35:27AM -0600, Jens Axboe wrote:
quoted
On 10/20/21 11:30 AM, Christoph Hellwig wrote:
quoted
On Wed, Oct 20, 2021 at 10:49:07AM -0600, Jens Axboe wrote:
quoted
It's not used for anything, and we're wasting time passing in zeroes
where we could just ignore it instead. Update all ki_complete users in
the kernel to drop that last argument.
The exception is the USB gadget code, which passes in non-zero. But
since nobody every looks at ret2, it's still pointless.
Yes, the USB gadget passes non-zero, and aio passes that on to
userspace. So this is an ABI change. Does it actually matter?
I don't know, but you could CC the relevant maintainers and list
to try to figure that out.
True, guess it does go out to userspace. Greg, is anyone using
it on the userspace side?
I really do not know (adding linux-usb@vger) My interactions with the
gadget code have not been through the aio api, thankfully :)
Odds are it's fine, I think that something had to be passed in there so
that was chosen? If the aio code didn't do anything with it, I can't
see where the gadget code gets it back at anywhere, but I might be
looking in the wrong place.
Anyone else here know?
I really doubt anyone uses io_event::res2 with FunctionFS gadgets. The
examples in tools/usb/ffs-aio-example/ either check just "res" or ignore
the status completely.
The only other program I can find using aio FunctionFS is adbd which
also checks res and ignores res2 [1]. Other examples I know of just use
synchronous I/O.
So is there consensus on the USB side that we can just fill res2 with
zero? The single cases that does just do res == res2 puts the error
in res anyway, which is what you'd expect.
If so, then I do think that'd be cleaner than packing two values into
a u64.
I think yes, we should try that, and if something breaks, be ready to
provide a fix for it.
I've split the change in two, one that gets rid of the special arguments
on the USB side, and one that then drops it for the whole kernel since
everybody passes 0 at that point. Should make it easy to pinpoint, if
need be.
--
Jens Axboe