[openib-general] Proposed device enumeration & async event APIs

Fab Tillier ftillier at infiniconsys.com
Sun Sep 12 11:36:54 PDT 2004


> From: Roland Dreier [mailto:roland at topspin.com]
> Sent: Sunday, September 12, 2004 9:05 AM
> 
>     Fab> Like Sean said, if the common case is going to be a single
>     Fab> device, then the gain is likely not worth the complication in
>     Fab> the code.  I don't feel really strongly about it, it was just
>     Fab> a thought based on how the device related notifications
>     Fab> worked in IBAL, which I found to be useful.  No biggie either
>     Fab> way, and it should be simple enough to change down the road
>     Fab> if we see a need.
> 
> OK, I thought about it some more and I decided that it's better to
> have the API from the beginning so that more efficient implementations
> can be added without changing the client code.  However, I implemented
> the following API:
> 
> 	void *ib_get_client_data(struct ib_device *device, struct ib_client
> *client);
> 	int   ib_set_client_data(struct ib_device *device, struct ib_client
> *client,
> 				 void *data);
> 
> I think this is equivalent to what you proposed but simpler to
> implement and use.  It also mimics the API in <linux/pci.h>:

I think making things behave like other Linux APIs is the right way to go -
the more we do to make it simpler for kernel devs to find their way around
IB the better.

> 
> 	void *pci_get_drvdata (struct pci_dev *pdev);
> 	void pci_set_drvdata (struct pci_dev *pdev, void *data);
> 
> (my set function returns an int because it does an allocation, so it
> can fail)

How do the above pci_xxx_drvdata functions avoid a malloc?  Can we do
something similar?  Either way, I think your proposed API will work fine.

Is it valid for a client to call the get function if it did not call the set
function?  Does that just result in NULL being retuned?

Thanks,

- Fab




More information about the general mailing list