Re: btuart and SOCKET Bluetooth CF

[Iain Hibbert <plunky%rya-online.net@localhost>]

On Mon, 25 Jan 2010, KIYOHARA Takashi wrote:

> > However, I'm not sure if it is permitted to use cfdata->cf_flags in this
> > manner?  There seem to be some rare instances of similar use but there is
> > no mention in the API specification..
>
> Oops.  I can't agree your patch.  :-<
> DTL always has the header.  It is a big penalty to check this by all
> packets.  And, btuart(4) is used perhaps on a very slow machine.  So it
> is a slow machine without usb(ubt(4)) perhaps.
> # My main machine is hpcsh 100MHz with PCMCIA.  ;-)
> # It not have Cardbus and USB.

I don't know if some test each packet would be significant for Bluetooth.
At this stage, even with 2.0 + EDR device I managed only 80KiB/s with
L2CAP direct connection (two radios but one computer so could be
interference). but I think the Nokia DTL 1/4 device is older spec also?

but in that case please consider my suggestion as two parts "input" and
"output" path.  On the input at least I think it would be more efficient
to just use the sc_drop flag instead of adding the pad byte into the mbuf
and using m_adj to remove it later - mbuf operations can be quite
expensive in this manner..  for the output you also cannot sleep at this
time, so must deal with failure to prepend/append data to the mbuf.

> In my understanding, the cfdata->cf_flags is a flag that each driver
> can use.  You can find it used in arch/PORT/conf/GENERIC by wdc(4)
> and wd(4).

imo all of cfdata is not for drivers to set

I suggested previously about changing config_attach_pseduo() to accept an
argument (to pass through to driver_attach) but found no positive reaction
at that time (and, I found a better method for the usage I wanted)

iain