linux-kernel - Re: [GIT PULL] firewire updates for 6.6

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] [day] [month] [year] [list]

Message-ID: <20230910022003.GA67045@workstation.local>
Date:   Sun, 10 Sep 2023 11:20:03 +0900
From:   Takashi Sakamoto <o-takashi@...amocchi.jp>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Jan Engelhardt <jengelh@...i.de>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] firewire updates for 6.6

Hi Linus,

On Sat, Sep 09, 2023 at 11:28:14AM -0700, Linus Torvalds wrote:
> On Fri, 8 Sept 2023 at 20:35, Takashi Sakamoto <o-takashi@...amocchi.jp> wrote:
> >
> > In the second half of 6.6 merge window, Jan Engelhardt sent the change. It
> > allows any front ends of Kconfig to deactivate FireWire subsystem at a
> > clip.
> 
> I pulled this, but after looking at it, I unpulled it again.
> 
> We *already* had this. Saying 'N' to the existing FIREWIRE option
> would disable all of the firewire stack, since the rest then just has
> 
>         depends on FIREWIRE
> 
> on it.
> 
> The only exception is the firewire sniffing side (FIREWIRE_NOSY),
> which technically doesn't need the firewire stack to exist or to work.
>
> The other thing this adds is a
> 
>         depends on PCI || COMPILE_TEST
> 
> for the firewire subsystem, which makes sense since the controllers
> all depend on PCI even if the code itself doesn't care (thus the
> COMPILE_TEST) part.
> 
> Anyway, both of those changes are fine by me - but adding a new config
> option, and bothering users that want firewire support with TWO
> questions about "do you want firewire" is just annoying and frankly
> just stupid.
> 
> I have said this five hundred times before, but I guess I'll say it
> five hundred times again (the Proclaimers even wrote a song about it):
> we don't make the config options worse, and we don't ask people stupid
> things.
> 
> So no.
> 
> The actual core limitations I'd be ok with: just add that
> 
>         depends on PCI || COMPILE_TEST
> 
> to the *existing* FIREWIRE config, and add a
> 
>         depends on FIREWIRE
> 
> to FIREWIRE_NOSY for all I care. That potentiall y*removes* annoying
> questions, not adds them.
> 
> And if people want to change the existing menu to a menuconfig
> (*keeping* the existing FIREWIRE config option, not adding a new one),
> that's fine too.
> 
> But this "let's add yet another mindless option to ask users" is _not_
> acceptable.
> 
>               Linus

Indeed, the additional option would be annoying to users. I figure out
that It is reasonable to avoid the change and stop 'history repeats'.

Ideally, core functions of FireWire subsystem in firewire-core can be
built without dependency on PCI subsystem, but actually it depends, as
we can see in comment of the menu option. The nosy driver is for Texus
Instruments PCILynx device and should depends on PCI subsystem. We can
see apparent difference between these two cases of dependency on PCI
subsystem. I doubt the loss of direct dependency on PCI subsystem in nosy,
at present.

Anyway, the requester has already sent another patch[1]. I postpone it
and continue discussion with him for next merge window.

[1] https://lore.kernel.org/lkml/20230909221248.2598-1-jengelh@inai.de/


Thanks

Takashi Sakamoto