Provide a simple way to obtain the native GPIO driver used by the controller

[raffaeler]

This is related to this issue: #1467

@joperezr suggested to use reflection to obtain the driver type name

I am proposing to add a new member that returns the driver name so that it is easier to make diagnostic.
Over the time we have seen many issues that could be solved simply by changing the driver. Adding a property with the driver System.Type is simple and could greatly help diagnostics.

I am wondering whether we could also expose the native driver name as well (libgpiod / sysfs).

There is an additional thing to consider. Certain peripherals can be created without specifying the controller (null as parameter). The controller is then created under the hood but it is not accessible from the code. In this case there would not be the possibility to obtain the driver name.

I would add the detected board model as well.

[raffaeler]

We discussed this during the triage and agreed we have two distinct problems here.

1. Provide a new GpioController method returning a new object that contains at least the information the drivers in used for this instance. This proposal is in line with the initial proposal of this thread.
   More specificatlly for 'drivers' I mean at least:
   • managed driver
   • board model
   • native OS driver

The alternative proposal I made during the triage was to provide the information above with a separate API so that we could know the result of the detection even before new-ing the GpioController. Anyway, getting the info from the GpioController is also needed because users can manually pick a different driver and we may want to know from the GpioController what is the driver in use. This alternate proposal is dropped.

2. @pgrawehr raised this second problem which is the current inability to customize the board detection logic and its extensibility.
   Anyway, making changes to the current API would cause a huge breaking change to all the bindings. Most of the time the binding is called with a null in place of the GpioController which is then created internally (and thus, without the chance to customize the driver).

In order to solve this problem and avoid breaking changes, I proposed to adopt a solution similar to how the assembly loading hook works today in the runtime.
We could add a static delegate inside the GpioController class that, if defined from the user, would hook the driver creation process. This would permit to customize the driver without changing the bindings.

Also, the static delegate should received some information about the hardware the GpioController is intended for. In fact, it is possible to have more than one "boards" on the same physical machine. Different boards could require different drivers therefore the handler must know which hw is the driver intended for. Patrick proposed to pass the hw tree.

@joperezr asked to create a prototype in order to evaluate the possible implications for the aforementioned APIs.

@pgrawehr said he will work on prototyping the point 1.

I invite the others to add/refine/correct the content in this comment, in case I forgot or misunderstood something.

/cc @Ellerbach @krwq

[krwq]

What we really need here is way to figure out the default driver. Possibly we should just expose something like: GpioDriver.GetBestDriver or equivalent. This way we don't really need anything on the GpioController directly and if we need to figure out the driver we just call that and call GetType().Name on that

[pgrawehr]

@krwq The logic for determining the best driver is currently in GpioController, and I think it should stay there (or, if at all, move up, to the Board class). GpioDriver is an abstract class that is hidden for most users. It would seem strange to me to give the base class knowledge about its descendants.

[krwq]

@pgrawehr it's actually common technique and it's already done in many places. Some common places: XmlReader.Create, I2cDevice.Create

[pgrawehr]

True, but I still think it's ugly, mostly because it's not really extensible. And we would have this logic (it can be this driver or that or...) in several places.