linux-kernel - Re: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

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, 27 Apr 2007 10:50:26 +0300
From:	Sergey Yanovich <ynvich@...il.com>
To:	Alex Dubov <oakad@...oo.com>
CC:	Pierre Ossman <drzeus-mmc@...eus.cx>, linux-kernel@...r.kernel.org
Subject: Re: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

Alex Dubov wrote:
>> Before you get your hopes up, this development model is not one that will get
>> your code merged upstream. You should really try to work with Alex, not side
>> step him. Drivers are rarely complex enough to warrant, or even have room for, a
>> rewrite. And judging from your code it looks more like reorganising the code
>> that's already there.
>
> It is a sad truth. Instead of raising real issues that may remain in the driver, I was presented
> with "non-proof" that bus-adapter-device architecture I'm using is somehow bad and the driver
> should be turned into a monolithic blob, using config variables to disable unneeded functionality.
> Considering, that udev handles automatic loading of the drivers just fine (so it's not an end user
> issue at any rate), I don't see any justification for the change.

I may be doing something the wrong way. I absolutely don't intend to
start flames in this list.

Alex, your driver is great. You have done enormous amount of work,
reverse engineering proprietary drivers. Since the territory you work on
is unchartered, you can choose any design model, you see appropriate.

However, since we are working in an open community, everyone can give
his opinion on this issue. The commenter must definitely back his words
with real arguments. The patch at the top of this thread is such an
argument. You may or may not care about it, at will.

I have submitted my version only after I have failed to find a stable
version of your driver for the current kernel. If there is one, just
post link to the patch. If not, let's make one.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/