All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Christoph Hellwig <hch@lst.de>,
	akpm@osdl.org, arnd@arndb.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] dasd: remove dynamic ioctl registration
Date: Fri, 16 Dec 2005 16:00:58 +0100	[thread overview]
Message-ID: <20051216150058.GA20144@lst.de> (raw)
In-Reply-To: <1134745099.5495.31.camel@localhost.localdomain>

On Fri, Dec 16, 2005 at 03:58:19PM +0100, Martin Schwidefsky wrote:
> On Fri, 2005-12-16 at 15:33 +0100, Christoph Hellwig wrote:
> > dasd has some really messy code to allow submodule to register ioctl.
> > Right now there are two cases:  cmd and eckd.
> 
> Wrong, at least four: cmf, eckd, err, and a binary only module from EMC.
> Now don't hit me for that binary module. But it has been there for 2.4
> and we even reserved some ioctl numbers for them (240-255).

NACK, binary modules are not a reason to keep broken things, rather one
to fix it better sooner than later.

> > cmd was merged into the main module in the last patchh, so we don't
> > need the mechanism for it anymore.
> 
> Seems resonable. The same could be done for the err module. Doesn't have
> to be a module, a config option is enough.

yes, it would clean up the err code a lot.

> > Fix this second issue by adding an ioctl method to the dasd_discipline
> > structure.
> 
> That can easily be fixed by adding a check in the ioctls as well. But
> a .ioctl entry in the discipline structure makes sense and would get rid
> of all dynamically added ioctls in our code. So I'm all in favor of it.

Yepp.  I generally prefer to not just fix things but rip out surrounding
mess.  Keeps code maintainable in the long run.

> I would be cautious about ripping out the dynamic ioctls interface
> though. I have no idea if there still is an EMC module for 2.6 or other
> exploiters. It is an exported interface after all. It is not necessary
> to break these exploiters intentionally.

Yes, it is.  Unrelated modules adding ioctls is a big no-way.  Even more
for binary modules.  The EMC code deserves to be broken.

  reply	other threads:[~2005-12-16 15:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-16 14:33 [PATCH 2/2] dasd: remove dynamic ioctl registration Christoph Hellwig
2005-12-16 14:58 ` Martin Schwidefsky
2005-12-16 15:00   ` Christoph Hellwig [this message]
2005-12-16 16:32     ` Martin Schwidefsky
2005-12-16 16:38       ` Christoph Hellwig
2005-12-16 16:13         ` Ric Wheeler
2005-12-16 19:30           ` Martin Schwidefsky
2006-01-06 11:01 ` Christoph Hellwig
2006-01-06 14:18   ` Ric Wheeler
2006-01-06 14:21     ` Christoph Hellwig
2006-01-06 14:29       ` Ric Wheeler
2006-01-11  9:16         ` Martin Schwidefsky
2006-01-17 13:35           ` Christoph Hellwig
2006-01-17 20:50             ` Andrew Morton

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=20051216150058.GA20144@lst.de \
    --to=hch@lst.de \
    --cc=akpm@osdl.org \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.