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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
