Date: Tue, 16 Mar 2004 09:08:12 -0800
From: Greg KH <greg@kroah.com>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] s390 (8/10): zfcp fixes.
Message-ID: <20040316170812.GA14971@kroah.com>
References: <20040313014156.GB10930@kroah.com> <OF625BA2CA.1376AB85-ONC1256E58.002FCAD7-C1256E58.00331651@de.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <OF625BA2CA.1376AB85-ONC1256E58.002FCAD7-C1256E58.00331651@de.ibm.com>
User-Agent: Mutt/1.5.6i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1248
Lines: 28

On Mon, Mar 15, 2004 at 10:18:00AM +0100, Martin Schwidefsky wrote:
> 
> So we need an external release function, one that isn't part of the zfcp
> module. This external release function is either a generic function for
> all these objects or a dedicated release function for each of the
> additional
> device objects. A dedicated release function would mean to define a release
> function somewhere in the kernel or another module just for the purpose of
> freeing an object defined by the zfcp module. This is even more gross than
> to use a generic release function. And the simplest release function is
> kfree.

This is not ok.  If you have to do something like this, I really suggest
that you not allow the "sub modules" be able to unload before the upper
module can.  In fact, why would you want to do such a thing?

I still really strongly object to this patch.  If it's a scsi problem,
fix it there, but odds are it's your driver's problem as no other scsi
driver needs this.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/