Messages in this thread | | | Date | Fri, 15 Jul 2005 14:26:57 +0200 | From | Pierre Ossman <> | Subject | Re: [PATCH] MMC host class |
| |
Russell King wrote:
>No no no no no. Repeat after me ten times. Empty or non-existant release >functions are bad and cause oopsen. I will not create code which does >this. > >
Sorry. I thought it was a generic cleanup function and since nothing was allocated in the register function I didn't think it needed to do anything. I tried to find some documentation about how classes were handled but eventually had to resort to looking at other code. Perhaps I should look at the documentation about kernel objects instead?
>What this means is that mmc_host itself becomes a refcounted sysfs >object which needs to follow the lifetime rules associated therewith. > >Luckily, I thought about this earlier on, so there's a core mmc function >to allocate the beast, register it, unregister it, and finally free it. > >The allocation function should initialise class_dev as much as possible. > >
The name field cannot be initialised since it isn't generated until registration. And I avoided filling in the other stuff at allocation so that I could keep knowledge of mmc_host_class in mmc_sysfs.c.
>The registration function should add the class device with the class >model. The unregistration should remove the class device from the class >model, but _not_ free it. The free function should drop the last >reference to the class device, which results in the remove function >(eventually) being called. Finally, the remove function can free the >mmc_host. > >
With the remove function you mean the .release in the class struct?
>Also note that since we have a class_dev, the mmc_host 'dev' field can >be removed. However, we'll probably have to update the host drivers >to do this, so it should be a separate patch. > > >
I'll read up on kernel objects and sysfs and put together a new patch then.
Rgds Pierre
- 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/
| |