[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