On Mon, Sep 18, 2023 at 09:41:02AM -0700, Raghavendra Rao Ananta wrote:
> On Fri, Sep 15, 2023 at 12:33 PM Oliver Upton <[email protected]> wrote:
[...]
> > This would eliminate the possibility of returning ENODEV to userspace
> > where we shouldn't.
> >
> I understand that we'll be breaking the API contract and userspace may
> have to adapt to this change, but is it not acceptable to document and
> return ENODEV, since ENODEV may offer more clarity to userspace as to
> why the ioctl failed? In general, do we never extend the APIs?
Yes, we extend the existing interfaces all the time, but we almost
always require user opt in for user-visible changes in behavior. Look at
the way arm64_check_features() is handled -- we hide the 'detailed'
error and return EINVAL due to UAPI.
--
Thanks,
Oliver
On Mon, Sep 18, 2023 at 9:47 AM Oliver Upton <[email protected]> wrote:
>
> On Mon, Sep 18, 2023 at 09:41:02AM -0700, Raghavendra Rao Ananta wrote:
> > On Fri, Sep 15, 2023 at 12:33 PM Oliver Upton <[email protected]> wrote:
>
> [...]
>
> > > This would eliminate the possibility of returning ENODEV to userspace
> > > where we shouldn't.
> > >
> > I understand that we'll be breaking the API contract and userspace may
> > have to adapt to this change, but is it not acceptable to document and
> > return ENODEV, since ENODEV may offer more clarity to userspace as to
> > why the ioctl failed? In general, do we never extend the APIs?
>
> Yes, we extend the existing interfaces all the time, but we almost
> always require user opt in for user-visible changes in behavior. Look at
> the way arm64_check_features() is handled -- we hide the 'detailed'
> error and return EINVAL due to UAPI.
>
Got it. Let's return EINVAL then. Thanks!
- Raghavendra
> --
> Thanks,
> Oliver