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: Thu, 28 Jan 2016 10:17:11 +0800 From: Shawn Lin <shawn.lin@...k-chips.com> To: Ulf Hansson <ulf.hansson@...aro.org>, Russell King - ARM Linux <linux@....linux.org.uk>, Adrian Hunter <adrian.hunter@...el.com> Cc: shawn.lin@...k-chips.com, bcm-kernel-feedback-list@...adcom.com, linux-rpi-kernel@...ts.infradead.org, linux-mmc <linux-mmc@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [RFC PATCH 0/21] Totally remove SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk On 2016/1/27 23:07, Ulf Hansson wrote: > On 27 January 2016 at 14:23, Russell King - ARM Linux > <linux@....linux.org.uk> wrote: >> On Wed, Jan 27, 2016 at 02:59:14PM +0200, Adrian Hunter wrote: >>> In my view Ulf needs to explain how the SDHCI library is going to work, >>> particularly in the absence of new callbacks. >> >> We need to add new callbacks as part of the conversion to a library, >> otherwise we're very much into a total rewrite from scratch (which >> I think is far too much work, and prone to errors) or a big flag day >> to switch everything over (which will require a moritorium on sdhci >> patches while the effort to switch everything is ongoing.) >> Totally agreed. Maybe that is the reason that frighten some volunteers to make the conversion. >> Both of those approaches suffer from one huge drawback: there is no >> way to bisect between them to locate the cause of a regression. >> [...] >> >> I think what needs to happen here is that Ulf needs to leave such >> decisions about what is acceptable or unacceptable to those who are >> trying to convert sdhci to a library, otherwise the conversion will >> probably never happen... unless Ulf wants to get directly involved >> in the conversion effort, producing patches to make it happen. >> > > I don't intend to contribute much with actual patches. I am willing to > help review and also help with expertise around the PM related parts. > > I do realize that some callbacks may still be needed, even in the end > when sdhci has become a pure library. Although, those should be far > less then those we have today. > > Currently I am more or less unable to properly maintain sdhci because > of it's bad code structure. Therefore I have taken a quite simple > approach by rejecting new callbacks and quirks, in a way to prevent it > from being worse. Ulf, I do understand your situation. sdhci makes you exhausted and no one seems able to maintain it properly. But preventing it from being worse doesn't mean making it better, right? I'am not a experienced sdhci expert, so when I read the sdhci code for the first time last summer, it does shock me a lot. So many historical burden it takes with lots kinds of *quirks*, I even cannot undertand why some quirks are need since git-blame just tell me some useless info because somebody do some coding-style fix or moving code here and there, which makes me hard to trace the changes. Another fact, how to test these changes for diff hardwares?? Without the help of variant drivers folks, it cannot go a step. If we split our "library direction" movement, do you think all the variant drivers are willing to test all the patchsets for it? I don't think so. Here, I come up with a bold and tentative proposal: If someone is willing to be the maintainer of sdhci, he/she can create a separate files and rewrite it to be a library. Then we reject to accept any new variant drivers to use the old sdhci struct and encourage it to fit the library one. Then ask the variant drivers who use the old struct to migrate its code to fit the library. Until all done, remove the old sdhci. Does that make sense? To me, the best way forward would be if some of you > experienced sdhci developers stepped in as a maintainer for it. In > that way, I can trust the development moving in the "library > direction" so I can pull back from nacking potential interim sdhci > callbacks/quirks. > > Does it make sense? > > Kind regards > Uffe > > > -- Best Regards Shawn Lin
Powered by blists - more mailing lists