linux-kernel - Re: [RFC PATCH 3/5] firmware_loader: Split fw

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: <ca6ad2ef-455e-c6c5-f766-2a64a5caec0f@intel.com>
Date:   Thu, 10 Feb 2022 18:24:11 -0800
From:   Russ Weight <russell.h.weight@...el.com>
To:     Tom Rix <trix@...hat.com>, <mcgrof@...nel.org>,
        <gregkh@...uxfoundation.org>, <rafael@...nel.org>,
        <linux-kernel@...r.kernel.org>
CC:     <lgoncalv@...hat.com>, <yilun.xu@...el.com>, <hao.wu@...el.com>,
        <matthew.gerlach@...el.com>, <basheer.ahmed.muddebihal@...el.com>,
        <tianfei.zhang@...el.com>
Subject: Re: [RFC PATCH 3/5] firmware_loader: Split fw_sysfs support from
 fallback

On 2/6/22 7:43 AM, Tom Rix wrote:
>
> On 2/3/22 1:30 PM, Russ Weight wrote:
>> In preparation for sharing the "loading" and "data" sysfs nodes with the
>> new firmware upload support, split out sysfs functionality from fallback.c
>> and fallback.h into fw_sysfs.c and fw_sysfs.h. This includes the firmware
>> class driver code that is associated with the sysfs files and the
>> fw_fallback_config support for the timeout sysfs node.
>>
>> CONFIG_FW_LOADER_SYSFS is created and is selected by
>> CONFIG_FW_LOADER_USER_HELPER in order to include fw_sysfs.o in
>> firmware_class-objs.
>>
>> This is mostly just a code reorganization. There are a few symbols that
>> change in scope, and these can be identified by looking at the header
>> file changes. A few white-space warnings from checkpatch are also
>> addressed in this patch.
>>
>> Signed-off-by: Russ Weight <russell.h.weight@...el.com>
>
> Consider how bisectable and reviewable this patch is.
>
> I think this patch should be first since reorganizing should not depend on anything new.

Hi Tom,

The first two patches are very small and stand on there own. I put them first because they could be taken independent of the rest of the patches.

>
> Other users of fallback will want to know if this change is going to break them, so the reorganization should be as mechanical as possible to make the review as easy as possible and easy to revert if something goes wrong.  Ex/ the whitespace changes made as a separate patch to the old file, not embedded in the new file.  The new Kconfig added later if needed.
>
> Also consider if this move is needed at all, generalizing in the existing file is ok.

I did give this a lot of consideration. I'm open to reorganizing the code if needed. These are some of the things I considered:

The context of a user-initiated firmware upload is quite different from firmware-fallback. I want to reuse the sysfs support for loading and data, but I don't think firmware upload should share the same config options as firmware-fallback, and incorporating the firmware-upload support into the existing fallback.[ch] files seems pretty ugly. I think the split is the right choice.

The split was largely mechanical, except for the following
(1) Kconfig and Makefile changes - without Makefile changes, the resulting patch wouldn't compile. I suppose I could defer the config change, but it is a small and obvious change.
(2) Data and function scopes: the resulting patch would not compile without these changes.
(3) Whitespace changes: the purpose of these changes was to quiet a handful of errors checkpatch. Moving them to a different patch would defeat the original purpose of make the changes at all. Maybe these changes simply aren't needed?

I could defer the Kconfig change and remove or defer the checkpatch-related white-space changes.

Any other opinions on the code reorganization in this patch?

- Russ

>
> Tom
>