On 03/31/2017 04:48 AM, Johannes Berg wrote:
I really don't understand what change you are suggesting. Anything
that uses a new API needs to change, and as API is further improved,
then the app will need to change again. Netlink's saving grace is
that it is easy to add new data members and so support new API in a
forward/backward compatible manner.
That's true, but it'd still mean you have to update all the time, and
perhaps then we'll find out it'd be easier to break the API, etc.?
In my experience, the big problem with netlink is that if you write
a patch that cannot make it upstream (or takes forever), then the netlink
IDs conflict as upstream adds more stuff.
Other than that, it is easy to add new members, or completely new commands.
User-space can drop old API and simply not fully work against older kernels
if it wants, especially for something as specialized as a simulated
wifi radio.
>
OTOH, supporting (on both sides) channel contexts doesn't seem so hard
- perhaps something like
* add chanctx
* remove chanctx
* change chanctx config
as hwsim commands, and then we can pretend to add/remove in start/stop
if we have non-chanctx-hwsim?
The project I did this work for is basically done and frozen. I can tweak
some small API changes to sync up with new netlink ID numbers, but I have no
time to completely re-do the API (and more importantly, to test it all).
So, if my patch can go in as is or with small tweaks, then I'm happy to
keep working on it. If it needs a complete re-write, then it will have to
wait for someone else or some later date.
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
