On Tue, Feb 14, 2006 at 05:53:08PM +0100, Horst Hummel wrote:
> Unfortunately neither me nor Stefan W. got an answer on the question
> about being more precise on 'ioctl mess' or any other statements
> like 'adds more junk to already crappy code'.
>
> We can't see - and you did not specify - reasons why the current
> approach does not work. Therefore I don't see any urgency to change
> that NOW instead of discuss the design change (consulting Martin -
> he will be back next week) and do the ioctl change when we have an
> agreed solution including ALL components.
(1) devices have pretty clear ownership. Implementing ioctls in
different modules means we get a very undefined API. Given that
ioctls are generally deprecated adding extensions to that is
a bad idea.
(2) cleaning up that mess reduced code size a lot
(3) the cmb module had more glue code than actual ioctl implementation
which speaks words at length.
(4) adding new ioctls is not okay in general, you should be using
better APIs.
(5) you're not just adding new ioctls but also add them using the
dynamic registration facility that I NACKed before and remove in
earlier sent patches, but you copletly ignored all objections
and just resent the patches anyway
(6) in addition to the dynamic ioctls it's also adding a misc device,
leading to a totally incoherent interface.
> I agree that you proposal is straight forward and looks more pretty,
> but I don't like the approach to just delete code that doesn't fit
> your ideas.
It's not code that doesn't fit mu ideas but code that was rushed in
despite my veto for good reasons.
> As I already said, I would like to wait for final solution and
> don't apply the patches NOW.
that's totally fine with me. As long as we backout the bogus eer
patch before 2.6.16 all the cleanups and even the eckd ioctl fix
can wait. But don't put this crappy interface into 1.6.16 and thus
SLES10 so that applications start to rely on it.
-
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]
