Re: [RFC 7/7] Update Management API documentation

[Marcel Holtmann <marcel@holtmann.org>]

Hi Claudio,

> >> >>> if TX power is only read once than the kernel should just do it once
> >> >>> and
> >> >>> be done with it.
> >> >>>
> >> >>> And for RSSI, it would be better if the kernel read this periodically
> >> >>> based on current sniff mode etc. Userspace can not trigger this with
> >> >>> proper timing anyway. And it will potentially at some point start
> >> >>> blocking the controller. Only the kernel really knows when it is
> >> >>> acceptable to read the RSSI value.
> >> >>
> >> >> Reading the RSSI by the kernel, will force a certain limitation on the
> >> >> current and future Profiles. I believe setting the timing should be done
> >> >> by the profile itself, not the bluez user space code or the kernel. It
> >> >> is the responsibility of the profile to periodically poll the RSSI Level.
> >> >> For some cases, polling it every 5 seconds would be ok, and for some
> >> >> Others, it may be better to read it every second. I believe we must not
> >> >> impose any limitation here.
> >> >
> >> > You probably forgot that besides bluetoothd there should be no other
> >> > application holding the mgmt socket, so not you can't really do it in
> >> > poll in the application side and doing it over D-Bus is overkill. Also
> >> > I notice that from some parties, you include, there is some tendency
> >> > to have the profiles split from the bluetoothd, IMO this will only add
> >> > fragmentation with each and every platform using BlueZ having their
> >> > own implementation of each profile and not sharing much, making the
> >> > IOP a complete mess.
> >> >
> >>
> >> Some additional comments...
> >>
> >> Health plugin will need a similar approach to read the clock. It will
> >> be good to implement the same approach.
> >> In our suggested implementation the adapter controls when to send the
> >> command to read the RSSI, keeping the same logic for both: hciops and
> >> mgmtops. If the adapter is managing when to send the commands,
> >> repeated commands can be avoided, multiple callbacks can be registered
> >> by the profiles, but only one command to read the RSSI will be sent.
> >> The cover letter of the userspace patches contains more details how we
> >> implemented it.
> >>
> >> Reading the RSSI directly by the kernel will break hciops. These are
> >> the arguments that I have to support our decision.
> >
> > what I am hearing is that we want the kernel to poll for certain
> > information if userspace needs them. And either it is a one-shot poll or
> > it is on a regular interval.
> 
> If everybody agree we can do it. Our objective is to have the patches upstream.
> To keep the Proximity Monitor functional on both adapter_ops plugins
> we can move part of the logic from the adapter.c to the hciops. The
> polling to read the RSSI can be moved to hciops, in the management the
> polling will be in the kernel. The remaining code to register the
> callbacks doesn't need to be changed.
> Do you agree?

I am really open for suggestion, but just duplicating HCI is not going
to cut it. We have to be a lot smarter with the kernel mgmt interface.

So lets give this approach and go and see how it works out. And btw. I
do not care about the hciops that much anymore. If you wanna do the hard
work to make it work, fine with me.

> > The management interface will be primarily used by bluetoothd, but it is
> > open for other users as well. Mainly some low-level system tools or more
> > important qualification tools.
> >
> > So triggering certain actions from userspace is always tricky and then
> > we need to have bluetoothd sync with itself, its plugins etc. So I
> > rather prefer that we tell the kernel which pollable information to read
> > at which interval and then just get a notification if they have changed.
> > Let the kernel do its job without having to wakeup half of userspace to
> > make a simple decision to poll a value.
> >
> > And don't get me wrong, the stupid Bluetooth chip should be able to poll
> > this value with an interval natively. The best we can do is emulate that
> > in the kernel.
> 
> No problem. We will change the code and send another RFC.
> Do you want another channel in the BTPROTO_HCI socket or keep
> everything inside HCI_CHANNEL_CONTROL?

It is an async event on HCI_CHANNEL_CONTROL. That is good enough for me.

Regards

Marcel