On Tue, 2005-01-25 at 19:10 +0100, Martin Peschke3 wrote:
> Actually, you will find the adapter structure be an anchor for several
> other objects, or lists of them respectively. We tried to organize
> all the driver private data in a sane way. That means there is a tree
> of objects representing t
|
| cc: Greg KH <[EMAIL PROTECTED]>, SCSI Mailing List
, Matthew Wilcox |
| <[
On Tue, 2005-01-25 at 07:08 +0100, Heiko Carstens wrote:
> > Originally this generic device was part of your adapter structure. Now
> > you're trying to separate it and causing these problems. What it's
>
> Could you please elaborate where this patch does cause a problem?
You're look to be brea
> > > I thought that having release methods that just called kfree() were
> > > also verboten?
> > We do a kmalloc(sizeof(struce device),...) somewhere and this
> > is how we get rid of it again.
> > How are we supposed to free this object otherwise? The release
> > function gets called when there
On Mon, 2005-01-24 at 15:48 +0100, Heiko Carstens wrote:
> > I thought that having release methods that just called kfree() were
> > also verboten?
>
> We do a kmalloc(sizeof(struce device),...) somewhere and this
> is how we get rid of it again.
> How are we supposed to free this object otherwis
> > void
> > -zfcp_dummy_release(struct device *dev)
> > +zfcp_generic_services_release(struct device *dev)
> > {
> > - return;
> > + kfree(dev);
> > }
> >
> > /*
>
> I thought that having release methods that just called kfree() were
> also verboten?
We do a kmalloc(sizeof(struce device
On Mon, Jan 24, 2005 at 10:46:29AM +0100, Heiko Carstens wrote:
> @@ -1099,9 +1099,9 @@
> }
>
> void
> -zfcp_dummy_release(struct device *dev)
> +zfcp_generic_services_release(struct device *dev)
> {
> - return;
> + kfree(dev);
> }
>
> /*
I thought that having release methods that
7 matches
Mail list logo
