linux-kernel - Re: [PATCH 1/2] habanalabs/uapi: move uapi file to drm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFCwf11GO4n-nOhyLDAG9k9MSJ1xfjj6_1nH=X9vKgdbvY62yw@mail.gmail.com>
Date:   Tue, 27 Dec 2022 14:04:14 +0200
From:   Oded Gabbay <ogabbay@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     airlied@...il.com, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 1/2] habanalabs/uapi: move uapi file to drm

On Tue, Dec 27, 2022 at 9:26 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Mon, Dec 26, 2022 at 11:32:26PM +0200, Oded Gabbay wrote:
> > Move the habanalabs.h uapi file from include/uapi/misc to
> > include/uapi/drm, and rename it to habanalabs_accel.h.
> >
> > This is required before moving the actual driver to the accel
> > subsystem.
>
> What requires this?  Isn't this going to break userspace code?
Yes, most definitely it will break userspace code. Moreover, the
patches I'll send in 1-2 weeks to change the device char files will
also break it.
Having said that, I'm not worried because I don't believe anyone is
working with the upstream version because there is no NIC support
(yet).

If this is unacceptable, I can offer a couple of alternatives and we
can discuss what's best:

1. Do what AMD did a couple of years ago with radeon and amdgpu. We
keep the habanalabs original driver in misc to support Goya, Gaudi1
and Gaudi2 (only with the current features). Create a new habanalabs
driver in accel that will support only Gaudi2 and beyond. Our NIC
driver (which I will start upstreaming in a few months) anyway will
only support Gaudi2, so it will only work with the new driver. Make
the drivers mutually exclusive in Kconfig.
Gaudi2 as-is will be supported in the current driver, but if users
want to use new features (and NIC), they will need to move to the new
driver.

2. Move the driver to the new accel, but keep a copy of the uapi file
in misc (to prevent breaking include paths). In addition, expose both
new accel device char file (through drm code) and current habanalabs
char file. Users can "acquire" the device through either
/dev/accel/accel0 or /dev/hl0. Add new uapi content only to the uapi
file in include/uapi/drm. This is what I'm going to do in our internal
tree that we release as an out-of-tree driver to customers.

3. Keep the driver in misc. Clone it to accel only for next-gen ASIC,
whenever that may be.

WDYT ?
I'm sure there are additional variations of the three options above,
or a different option entirely.

Thanks,
Oded

>
> thanks,
>
> greg k-h