public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>, Stefan Weinhuber <wein@de.ibm.com>,
	Horst Hummel <horst.hummel@de.ibm.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] s390: dasd extended error reporting module.
Date: Sat, 4 Feb 2006 14:14:19 +0100	[thread overview]
Message-ID: <20060204131418.GA24721@lst.de> (raw)
In-Reply-To: <20060201115649.GA9361@osiris.boeblingen.de.ibm.com>

On Wed, Feb 01, 2006 at 12:56:49PM +0100, Heiko Carstens wrote:
> From: Stefan Weinhuber <wein@de.ibm.com>
> 
> The DASD extended error reporting is a facility that allows to
> get detailed information about certain problems in the DASD I/O.
> This information can be used to implement fail-over applications
> that can recover these problems.
> This is a resubmit of this patch because at first submission it
> didn't get included due to Christoph's ioctl changes.
> Since these aren't in the -mm tree anymore this one should be
> merged now.

NACK again.  (although andrew unfortunately pushed this to Linus
already, it would be good if this went out again before 2.6.16).

If you really want this functionality in a separate module you need
to call try_module_get on the module structure of the eer module
everytime before calling into it.  You need to register a structure
ala

struct dasd_eer_ops {
	struct module *owner;
	void (*disable_on_device)(struct dasd_device *);
	void (*write_trigger)(struct dasd_eer_trigger *);
};

and then have wrappers in the core dasd code ala

eer_disable_on_device(struct dasd_device *dev)
{
	if (try_module_get(eer_ops->owner)) {
		eer_ops->write_trigger(dev);
		module_put(eer_ops->owner);
	}
}

the module_get/put on THIS_MODULE in the patch are completely broken.

the ioctl registration is also totally not acceptable.  firtly this
interface is absolutely suitable for sysfs, although that might only work
if it's in the main module.  But even if you go for ioctls it should be
on your separate char device and not use the broken dynamic ioctl
registration which _must_ not be used in any new code.

Besides that there's tons of the usual style issues on the code, please
use mutexes, please make lots of variables that could be static, etc.


  reply	other threads:[~2006-02-04 13:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-01 11:56 [PATCH 1/3] s390: dasd extended error reporting module Heiko Carstens
2006-02-04 13:14 ` Christoph Hellwig [this message]
     [not found] ` <4de7f8a60602060237o5c19d796hb08c237a9b5f3c64@mail.gmail.com>
2006-02-06 11:30   ` Jan Blunck
  -- strict thread matches above, loose matches on Subject: below --
2006-02-06 18:15 Stefan Weinhuber
2006-02-06 18:23 Stefan Weinhuber

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=20060204131418.GA24721@lst.de \
    --to=hch@lst.de \
    --cc=akpm@osdl.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=horst.hummel@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --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