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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
