Re: Backlight and LCD module patches [2]

[John Lenz]

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