linux-kernel - Re: [RFC PATCH v2 1/3] drivers/accel: define kconfig and register a new major

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]

Date:   Fri, 4 Nov 2022 08:23:32 +0100
From:   Stanislaw Gruszka <stanislaw.gruszka@...ux.intel.com>
To:     Randy Dunlap <rdunlap@...radead.org>
Cc:     Oded Gabbay <ogabbay@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
        Jacek Lawrynowicz <jacek.lawrynowicz@...ux.intel.com>,
        Jeffrey Hugo <quic_jhugo@...cinc.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Arnd Bergmann <arnd@...db.de>,
        John Hubbard <jhubbard@...dia.com>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Christoph Hellwig <hch@...radead.org>,
        Jason Gunthorpe <jgg@...dia.com>,
        Jiho Chu <jiho.chu@...sung.com>,
        Alex Deucher <alexander.deucher@....com>,
        stanislaw.gruszka@...el.com,
        Yuji Ishikawa <yuji2.ishikawa@...hiba.co.jp>,
        Kevin Hilman <khilman@...libre.com>,
        Maciej Kwapulinski <maciej.kwapulinski@...ux.intel.com>,
        Jagan Teki <jagan@...rulasolutions.com>
Subject: Re: [RFC PATCH v2 1/3] drivers/accel: define kconfig and register a
 new major

On Thu, Nov 03, 2022 at 04:01:08PM -0700, Randy Dunlap wrote:
> >>> Module name if "M" is chosen?
> >> Will add
> > So, unfortunately, the path of doing accel as a kernel module won't
> > work cleanly (Thanks stanislaw for pointing this out to me).
> > The reason is the circular dependency between drm and accel. drm calls
> > accel exported symbols during init and when devices are registering
> > (all the minor handling), and accel calls drm exported symbols because
> > I don't want to duplicate the entire drm core code.
> 
> But DRM is a tristate symbol, so during drm init (loadable module), couldn't
> it call accel init code (loadable module)?
> 
> Or are you saying that they only work together if both of them are builtin?

Yes, with current state of the patches, we can not build code as modules.
There are symbols in accel that are from drm and we use accel symbols
in drm. This could be fixed by separating symbols accel requires in 
separate module i.e. drm_file_helper.ko, however Oded proposed to make
CONFIG_ACCEL compile option for DRM and all accel code will be
build in drm.ko . I think that ok, since accel is not big. 

Regards
Stanislaw