linux-kernel - Re: [PATCH] libosd: Remove ignored _

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: <ac63f6d2-d9f3-c512-892d-2e4450fd4c1e@acm.org>
Date:   Fri, 26 Oct 2018 23:15:11 -0700
From:   Bart Van Assche <bvanassche@....org>
To:     "Theodore Y. Ts'o" <tytso@....edu>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        ooo@...ctrozaur.com, Nathan Chancellor <natechancellor@...il.com>,
        "James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        linux-scsi@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        hch@...radead.org
Subject: Re: [PATCH] libosd: Remove ignored __weak attribute

On 10/26/18 8:35 PM, Theodore Y. Ts'o wrote:
> The second observation I'll make is that if someone is proposing a
> cleanup patch, it's unfair to dump on the person proposing the cleanup
> patch the (non-trivial) effort to drop a driver/file system/subsystem.

Hi Ted,

Maybe I was not clear enough. It never was my intention to suggest that 
Nick or Nathan should remove the OSD code. This is something I'm willing 
to do myself. BTW, I'm still waiting for someone to explain me why the 
patch at the start of this thread was submitted by people who never have 
used the libosd driver and who do not have any plans to use it ever.

> If the maintainer wants to drop a driver/file system, that should be
> the maintainer's responsibiltiy; not someone proposing a
> cleanup/maintenance patch.

I think anyone who makes tree-wide changes has the freedom to suggest to 
remove a driver. Having to modify drivers that are no longer maintained 
when doing tree-wide changes can be a real pain.

Additionally, you may have missed earlier discussions on the linux-scsi 
mailing list about this driver. The first time it was suggested to 
remove this driver was several years ago. The outcome of a discussion of 
a few weeks ago is that there is agreement about the removal of this 
driver. See also the following messages:
* https://www.spinics.net/lists/linux-scsi/msg123738.html
* https://www.spinics.net/lists/linux-scsi/msg123742.html

Bart.