Hi Antti,

<snip>

> There are clear real world use cases the proposed change.

Nope, these are not 'real world' use cases.  These are constraints for a
synthetic unit test framework you are trying to create.

> Both are usable with on their own and allow flexibility for testers to
> choose the testing strategy based on their needs (private system bus vs.
> actual system bus, multiple .conf files vs. dbus configuration on the
> fly). Unit testing API bindings or testing middleware can use the
> private system bus approach and system or user story testing of a
> complete software stack such as a mobile phone user interface would use
> the actual system bus.
> 
> Having the dbus interface also allows automated test suite to set up
> number of ofono modems based on the environment specification of
> individual tests.

I don't buy any of these arguments.  You have a specific case you want
to test due to the constraints of how your system is designed.  Create a
plugin specific to your system; do not try to over-complicate the
phonesim plugin which is fine the way it is.

> 
> Also not mentioned before, the dbus interface allows to test
> Manager::modemAdded() and Modem::modemRemoved() logic in the unit under
> test.

Then make up a plugin to test that specifically if you really care.

> 
> 
>> UI should be designed to ignore non-powered modems, and only look for
>> interfaces that it handles specifically.  So for a properly designed UI,
>> none of these changes are required.  If you want to handle DualSim
>> cleanly, then feel free to propose a mechanism / hint that makes
>> applications aware of the fact that two modems belong to a group.
> 
> A system with two modems where one modem being powered off is still a
> system with two modems. One modem simply being powered off does not make
> the system a single-modem one.

Again, that is a constraint of your particular system design.  Relying
on one modem == single SIM and two modems == DualSIM is a bad idea.  As
I mentioned before, introduce proper handling of Dual SIM devices and
none of these issues are relevant.  Introducing features that are broken
by design will not fly.

> 
> In my opinion the cleanest way to implement Multi-SIM is to have ofono
> reporting a correct number of modems.
> 

And I disagree.  If I want to plug in 100 Dual-SIM modems, I should have
the ability to do so.  I do not want to rely on some magic conventions.

> UI should ignore non-powered modem only if the UI design for the
> particular component mandates so. The UI design could also mandate that
> if a modem is powered off, or has some other problem which makes it
> unusable, the modem should be shown as disabled. Or something else.
> 

Again, that is your UI design constraint.  We have plenty of situations
where oFono creates multiple modems that are not physically there (e.g.
Bluetooth HFP for example).

> 
> My point being:
>    A) Having to implement testing-only code paths to components makes
>       testing much more complicated and potentially erroneous as the
>       code paths being tested differ between testing and production.

You already have a testing-only code-path since you are using phonesim.
 Phonesim is only barely usable as an approximation of real hardware.
Introducing a plugin specific to your system setup is not going to
change anything here.

>    B) oFono should not impose arbitrary limits to UI/UX design.

This has been discussed many times before.  oFono is (and does) dictate
UI design to some extent.

Regards,
-Denis