Messages in this thread | | | Date | Mon, 06 Sep 2004 07:32:39 +0000 | From | John Lenz <> | Subject | Re: Backlight and LCD module patches [2] |
| |
On 09/05/04 10:00:32, Greg KH wrote: > On Sat, Aug 21, 2004 at 02:51:33AM +0000, John Lenz wrote: > > > > Here. A few notes on the implementation. I have a global lock > protecting > > all match operations because otherwise we get a dining philosophers > problem. > > (Say the same class is in two class_match structures, class1 in the > first > > one and class2 in the second...) > > You also have some duplicated code in one function, which implies that > you didn't test this patch (it's in the updated patch you sent me too) :)
I didn't test it. It was only to show what I was thinking of with class_match.
> > > The bigger question of how should we be linking these together in the > first > > place? > > I thought you only wanted the ability to actually find the different > class devices. Then the code would take it from there. Not this > complex driver core linking logic that you implemented. > > > Instead of using this class_match stuff, we could use class_interface. > > Exactly. Why don't you all use that instead?
The only benifit from class_match is the "object oriented approach". I assume that the struct list_head children in struct class can be used from driver code? It is the correct policy to use that directly than to call a function in class.c? As well, the struct kobject in class_device (which we would use to create a symbolic link)? And of course our driver code would have to acquire class->subsys.rwsem...
If we do it in lcdbase.c we can even solve the locking problem... that is, we can always acquire class->subsys.rwsem in the lcd class before the class->subsys.rwsem in fb_class.
John
- 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/
| |