Auto generating services from SwIPC ?

[roblabla]

So I was wondering how good an idea it'd be to generate bindings automatically from SwIPC (with something like https://github.com/reswitched/SwIPC/pull/9). Basically, replace most of the stuff in the ipc/ folder with auto-generated things.

This would be a good litmus test to ensure that our SwIPC documentation is correct, while also removing a bunch of boilerplate.

@misson20000 how do you feel about this ?

[misson20000]

Hmm, there are a few things that I would be really, really careful with here:

• Namespace pollution, or having overly decorated function names. Related here is also the logical grouping of bindings into files. (should all interfaces reachable from any of vi's registered services go in the same file? what about something with a lot more interfaces?)
• Intelligently handling things like making transfer memories in initialization (this might tie into the third bullet point).
• This seems to me like it would involve splitting many of our modules into the autogenerated IPC portion and a wrapper to change the interface a little bit. I wouldn't mind this too much (we already do it for hid and audio).
• Compile time, if we're autogenerating a lot of bindings
• Special casing for things like sm and bsd

If we can come up with a way to address all of these concerns, I'd say it could be worth moving forward with.

[daeken]

I think there's a middle ground we can achieve here. Rather than generating fully-fledged IPC code, generate one function per IPC method, which sends a given message over a given connection. These get grouped into individually includable C files (one per IPC interface class), to be wrapped into nice friendly interfaces.

Compile times wouldn't go up dramatically, interfaces stay clean on the user side, and the ugly names and IPC details stay encapsulated.