UWB Addon

[Marcel Holtmann]

Hi Claudio,

> > > Here is the initial proposal for UWB Addon support. It is just the
> > > skeleton, the D-Bus methods are not implemented yet.
> > >
> > > This patch requires the Addon singleton patchset.
> > >
> > > Comments/Suggestions?
> >
> > first of all, I think we need to separate it into two patches. One that
> > populates the device paths with information from the kernel. Another one
> > that contains the addon. Actually I think we should start developing the
> > addon as a separate module. The UWB addon (as also a future addon for
> > Bluetooth) might get quite big and can be developed faster in an outside
> > tree.
> >
> > Besides that, we have to find some better naming. the name "Beacon"
> > should not be used in a public API. The term beaconing is part of low
> > level radio specification. Terms like visible or something similar are
> > much better. We have to design the API methods with the application
> > tasks in mind.
>
> I agree. My intention was send the skeleton to provide a high level
> view. Anyway, the addon can be not be integrated yet because the Addon
> sigleton patchset is required.

I know, but we are getting there. David, hint :)

> I don't have experience on HAL, I expect validate the design first and
> after that define the UWB API. Use the same/similar names used by
> BlueZ sounds good. The path is another problem, path based on UDI is a
> little unclear for the end users/developers. Instead of use UDI(eg:
> /org/freedesktop/Hal/devices/usb_device_8086_c3b_UWB_if0_uwb_hci_14a5cd96c9)
> we can try use a friendly path, but currently I don't how do that.

Actually you put capabilities on a UDI path and then enumerate based on
that capabilities. UDIs are like paths. There should have no implied
meaning whatsovever.

Regards

Marcel