On Sun, Aug 20, 2017 at 02:13:03PM +0200, Linus Walleij wrote: > So adding a new (in effect) invasive block driver needs to at least > be CC:ed to the block maintainers so we don't sneak anything like > that in under the radar. Yes. > And this semaphoring and threading is just as confusing as ever and now > we have two of them. (Sorry, I'm grumpy.) But your are grumpy for a good reason. The MMC driver is a pain to understand for even a seasons block layer developer. > What we need is an MMC stack where it is clear where blocks come in > and out and how they are processed by the block layer, but now we > already have a scary Rube Goldberg-machine and it is not getting better. > If people have different feelings they can tell me off right now. Agreed. > > I have my hopes up that we can get the code lesser and more readable > with MQ, as I tried to illustrate in my attempts, which are indeed lame > because they don't work because of misc and SDIO use cases, but > I'm honestly doing my best. Currently with other clean-ups to get a > clean surface to do that. > > As it stands, the MQ migration work size is in some spots doubled or > more than doubled after this commit :( I don't think we should merge this. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
