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, 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ