Messages in this thread | | | Date | Thu, 19 Jan 2012 01:01:46 +0530 | From | "Srivatsa S. Bhat" <> | Subject | Re: [PATCH] mce: fix warning messages about static struct mce_device |
| |
On 01/19/2012 12:20 AM, Kay Sievers wrote:
> On Wed, Jan 18, 2012 at 19:10, Alan Stern <stern@rowland.harvard.edu> wrote: > >> There's nothing special about the driver model code in this respect. >> The same restriction applies wherever object lifetimes are controlled >> by reference counting. > > Right. But it might not be obvious what 's the background here: > > An allocated device object(memory) usually represents an actual > device(hardware). The object can have N users. Every of the users is > required to take a reference to the object, which pins the object's > memory as long as any of the N users might need to access it. > > In a hotplug world, we deal with device-removal. On disconnect, we > usually just orphan the object, we remove it from visibility, > disconnect the device <-> object relation. > > All of the N users with a reference can still access the memory, they > just do not talk to a real device anymore. The invalidated/orphaned > state is communicated otherwise by locks and flags in the device > object. Only after all of the N users left the object alone, the > memory of the orphan if free'd. > > If in the time-window between disconnecting the object from the device > and freeing the orphaned object's memory, the same device comes back, > we allocate a new object which is associated with the device. It > usually has the same name and same properties as the original one. > > This way, the new object is full functional, does not conflict with > the older one, and also all the users of the old memory are still fine > and can cleanup a lazy as they need without much synchronization. > > Now, all that might not apply to machinecheck, and it might be that > machinecheck is fully able to handle all that just fine with the > statically allocated same memory -- allocating new device memory on > hotplug is still the model that should always be preferred over any > other, if possible. > > It's usually the simplest safest and most flexible for anything that > can come and go at any time, and memory which might be in used by > other running code. >
Thanks for the crystal clear explanations from both you and Alan. Now I am convinced.. :-) And thanks to Tony for bringing this up!
Regards, Srivatsa S. Bhat
| |