Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
MIME-Version: 1.0
References: <CAJgzZorfiG26TCfwNBVYJkkkVBAQowJhRUtX4EzWSxwZbfNoyw@mail.gmail.com>
 <fb983fa3-bf4d-42aa-b5c3-4927504c32d9@acm.org>
In-Reply-To: <fb983fa3-bf4d-42aa-b5c3-4927504c32d9@acm.org>
From:   enh <enh@google.com>
Date:   Mon, 16 Oct 2023 15:06:30 -0700
Message-ID: <CAJgzZooT78F996rW3ax2nVf4S=HWfhqkHjYCkXOEHdK5tf3Y3g@mail.gmail.com>
Subject: Re: [PATCH] scsi_status_is_good() uses __KERNEL__ constants.
To:     Bart Van Assche <bvanassche@acm.org>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-scsi@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Oct 16, 2023 at 1:48=E2=80=AFPM Bart Van Assche <bvanassche@acm.org=
> wrote:
>
> On 10/16/23 13:42, enh wrote:
> > Without this missing #ifdef, userspace code trying to use this header
> > directly won't compile. glibc manually removes it, bionic removes it
> > using a script. If we add this, the preprocessor can remove it instead.
>
> Is that the right solution? Shouldn't these software projects be
> modified such that <scsi/scsi.h> is *not* included?

i'm not sure that's practical? all linux libcs i know of include these
headers. (though bionic only has them because glibc did. i'm assuming
the same is true for musl?)

i think there's obviously a question of "why aren't these uapi
headers, if stuff is using them?". just looking at Android, i see
sg3_utils, mtools, compiler-rt (for ioctls), and toybox (for the eject
command).

or perhaps --- even if most of the scsi headers should be non-uapi, is
there a subset of stuff that should be in uapi?

but "libc can use this header directly like it does uapi headers,
rather than having to need a human manually fix the header" seemed
like a step forward from the status quo where everyone's shipping
their own hacked-up versions of these headers?

> Thanks,
>
> Bart.
>