mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: 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 15:58:19 +0100	[thread overview]
Message-ID: <1134745099.5495.31.camel@localhost.localdomain> (raw)
In-Reply-To: <20051216143348.GB19541@lst.de>

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).

> 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.

> eckd is actually broken right now because we allow calling the eckd
> ioctls on other dasd disciplines aswell, but they assume eckd-specific
> private data.
> 
> 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.

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.

-- 
blue skies,
   Martin

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH



  reply	other threads:[~2005-12-16 14:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-16 14:33 Christoph Hellwig
2005-12-16 14:58 ` Martin Schwidefsky [this message]
2005-12-16 15:00   ` Christoph Hellwig
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=1134745099.5495.31.camel@localhost.localdomain \
    --to=schwidefsky@de.ibm.com \
    --cc=akpm@osdl.org \
    --cc=arnd@arndb.de \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    /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

Powered by JetHome