In preparation for renaming struct device to something that doesn't
collide with the LinuxKPI's struct device.
Details
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 38458 Build 35347: arc lint + arc unit
Event Timeline
Usage of "struct device *" was just wrong. Thanks spotting the issue.
Commit 70275a6735df8a514f48be77418491f2f8dba817 should have the same effect.
Thanks, but the commit looks a bit strange: we are treating the pdev as a bus_dma_tag_t when it's really a pointer to a netmap adapter. It is not used at all on FreeBSD so it doesn't really matter, but maybe I'm missing something.
BTW, the problem here isn't that netmap is using a Linux struct device, it's just that we generally have problems caused by the LinuxKPI struct device and FreeBSD struct device colliding with each other. Almost all of the kernel uses device_t to refer to a FreeBSD device structure, so I was just changing netmap to follow this convention.
Thanks, but the commit looks a bit strange: we are treating the pdev as a bus_dma_tag_t when it's really a pointer to a netmap adapter. It is not used at all on FreeBSD so it doesn't really matter, but maybe I'm missing something.
And it is strange, indeed. But at least it is fixing an inconsistency, where "struct device" (meaning the Linux) type is used in code that is supposed to be common to both FreeBSD and the Linux netmap module. The argument is actually a pointer to the device object associated to the netmap adapter, which is always NULL in FreeBSD (because it's not used).
In any case, the situation can be improved and I'll do it asap.
BTW, the problem here isn't that netmap is using a Linux struct device, it's just that we generally have problems caused by the LinuxKPI struct device and FreeBSD struct device colliding with each other. Almost all of the kernel uses device_t to refer to a FreeBSD device structure, so I was just changing netmap to follow this convention.
Sure, but in this case na->pdev is not pointing to a device_t, so that would have been more confusing IMHO.
Thanks for the help!