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
| ||
|
Date: Sat, 16 May 2020 10:14:14 -0700 From: Bart Van Assche <bvanassche@....org> To: Avri Altman <Avri.Altman@....com>, "James E . J . Bottomley" <jejb@...ux.vnet.ibm.com>, "Martin K . Petersen" <martin.petersen@...cle.com>, "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Cc: "alim.akhtar@...sung.com" <alim.akhtar@...sung.com>, "asutoshd@...eaurora.org" <asutoshd@...eaurora.org>, Zang Leigang <zangleigang@...ilicon.com>, Avi Shchislowski <Avi.Shchislowski@....com>, Bean Huo <beanhuo@...ron.com>, "cang@...eaurora.org" <cang@...eaurora.org>, "stanley.chu@...iatek.com" <stanley.chu@...iatek.com>, MOHAMMED RAFIQ KAMAL BASHA <md.rafiq@...sung.com>, Sang-yoon Oh <sangyoon.oh@...sung.com>, yongmyung lee <ymhungry.lee@...sung.com>, Jinyoung CHOI <j-young.choi@...sung.com> Subject: Re: [RFC PATCH 00/13] scsi: ufs: Add HPB Support On 2020-05-16 02:14, Avri Altman wrote: >> Thank you for having taken the time to publish your work. The way this >> series has been split into individual patches makes reviewing easy. >> Additionally, the cover letter and patch descriptions are very >> informative, insightful and well written. However, I'm concerned about a >> key aspect of the implementation, namely relying on a device handler to >> alter the meaning of a block layer request. My concern about this >> approach is that at most one device handler can be associated with a >> SCSI LLD. If in the future more functionality would be added to the UFS >> spec and if it would be desirable to implement that functionality as a >> new kernel module, it won't be possible to implement that functionality >> as a new device handler. So I think that not relying on the device >> handler infrastructure is more future proof because that removes the >> restrictions we have to deal with when using the device handler framework. > > So should we keep perusing this direction, or leave it, and concentrate in Bean's RFC? > Or maybe come up with a 3rd way? Hi Avri, I prefer to proceed with reviewing Bean's patch series. If someone prefers a different approach, I think this is a good time to bring that up. Thanks, Bart.
Powered by blists - more mailing lists