Hi Marcel,
> >
> > Agree that it should be done "in background" and that a size
> threshold would be useful. But who evaluates that threshold? The
> bluez kernel components, which essentially implement a transport
> driver, should not be examining objects (files, phonebooks, etc) size
> to see if this threshold is met. Therefore, it would seem Tim's
> suggestion of having the profile send a 'prefer_amp' bit would be
> useful, right?
>
> I would do something like "prefer_amp when over 100kb" or something.
> And
> then the kernel needs to count. Meaning the L2CAP layer could easily
> count this by itself.
What? Let's say the effect we want is that if the object is greater than, say, 10 megabytes, then we want to use AMP for the transfer. With your scheme, you want the kernel to count up to 10 megabytes, THEN switch over to AMP?
No, you don't, he says rhetorically. :)
>
> Also just starting with setsockopt(bredr_only) and then later on just
> doing setsockopt(prefer_amp) the userspace application would have
> control over switching manually.
How is this really different from your ioctl(switch_now_to_amp) below, which looks very wrong?
>
> Since the polices are on a per socket basis, I don't see a big problem
> with doing it like this.
>
> The only thing that I don't want is a ioctl(switch_now_to_amp) since
> that looks very wrong to me.
Agreed.
>
> > > The other problem here is also that besides whatever the profiles
> > > wants,
> > > it might happen that the WiFi policy is stronger and only allows
> using
> > > the WiFi device as WiFi or as AMP. And if WiFi wins, then we have
> to
> > > rip
> > > the AMP out of the system. At that point whatever the Bluetooth
> > > profiles
> > > wanted is pointless since the AMP controller is gone anyway.
> >
> > Well, I think this is best managed by having the PAL announce its
> availability (and unavailability) to A2MP, using the spec's HCI events
> for this purpose. A2MP can then be the agent to move the channel to
> AMP or not, accordingly. For example, it might be that the 802.11
> device is being used for an infrastructure link, and then that link
> goes away. The PAL would then announce its availability to the BT
> stack (A2MP), and A2MP would then move the channel to AMP.
>
> Agreed. My point was just that application can only set a policy. They
> can't switch manually. If application would switch manually then they
> need to check PAL availability etc. I don't want that complexity inside
> the applications.
>
> > > That said, nothing stops us from allowing to make our AMP polices
> > > dynamic and allow the application to change it threshold during
> > > lifetime. For example it starts out as BR/EDR only and then during
> the
> > > usage of the link it decides that now AMP preferred would make
> sense.
> > > In
> > > that sense you would have manual switching to some level.
> >
> > The only use case I see for manual switching is debugging.
>
> That is fine. We can do that via debugfs.
>
> Regards
>
> Marcel
>
��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
