From: Christoph Hellwig <hch@lst.de>
To: Horst Hummel <horst.hummel@de.ibm.com>
Cc: kernel <linux-kernel@vger.kernel.org>,
heiko <heicars2@de.ibm.com>, Stefan Weinhuber <wein@de.ibm.com>,
Martin <mschwid2@de.ibm.com>, Andrew Morton <akpm@osdl.org>,
ihno@suse.de
Subject: Re: [PATCH 0/5] new dasd ioctl patchkit
Date: Tue, 14 Feb 2006 20:09:09 +0100 [thread overview]
Message-ID: <20060214190909.GA20527@lst.de> (raw)
In-Reply-To: <1139935988.6183.5.camel@localhost.localdomain>
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.
next prev parent reply other threads:[~2006-02-14 19:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-14 16:53 [PATCH 0/5] new dasd ioctl patchkit Horst Hummel
2006-02-14 19:09 ` Christoph Hellwig [this message]
2006-02-15 14:23 ` Carsten Otte
2006-02-15 20:03 ` Andrew Morton
2006-02-16 5:46 ` Heiko Carstens
2006-02-15 21:14 ` Stefan Weinhuber
-- strict thread matches above, loose matches on Subject: below --
2006-02-12 17:38 Christoph Hellwig
2006-02-13 7:04 ` Heiko Carstens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060214190909.GA20527@lst.de \
--to=hch@lst.de \
--cc=akpm@osdl.org \
--cc=heicars2@de.ibm.com \
--cc=horst.hummel@de.ibm.com \
--cc=ihno@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mschwid2@de.ibm.com \
--cc=wein@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox