Control: reopen -1 On Tuesday, 21 March 2023 14:21:05 CEST Debian Bug Tracking System wrote: > > In https://github.com/waydroid/waydroid/issues/811 I asked 'upstream' > > for recommendations on which/how/what kernel modules to enable. > > In https://git.kernel.org/linus/9e18d0c82f0c07f2a41898d4adbb698a953403ee the > default value of BINDER_DEVICES was changed to "binder,hwbinder,vndbinder" > whereas the Debian kernel only has "binder". Also in other places they use > the 3 values, but I haven't been able to find out *why*. > As I wouldn't be able to make the argument to change it to something else > and the most important thing is to enable ANDROID_BINDER_IPC, which is > already the case, there's no need to keep this bug open. > > If someone *can* substantiate why and how things should be changed, they > should file a bug report (themselves) making the case.
Just received an (unexpected) extra response, which DOES answer the Q I had: "BINDER_DEVICES defines which binder device names should appear in /dev. Different android versions required different devices to be available: the latest android version uses "binder,hwbinder,vndbinder" meaning /dev/binder, / dev/hwbinder, /dev/vndbinder. At some point Google realized that it's inconvenient to have this change at compile time, so they introduced BINDERFS: you can mount a filesystem of type binder somewhere and use IOCTLs on it to allocate new device names. So if you use BINDERFS it doesn't matter which value of BINDER_DEVICES you set because you can add (or remove) devices at runtime. In this case BINDER_DEVICES is just the set of initial devices present in the root of a binderfs. For mainline linux, BINDERFS is heavily recomended. Waydroid will use it to create all the binder devices it needs. You can leave BINDER_DEVICES empty or unchanged or whatever you prefer." I don't really understand how or what `ioctl`s are, but I'm pretty sure others do and can now make an informed choice if and how things could be improved. I'm pretty sure that'll be for Trixie, which has the nice benefit that it can be extensively tested.
signature.asc
Description: This is a digitally signed message part.
