tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: btuart and SOCKET Bluetooth CF
On Fri, 22 Jan 2010, KIYOHARA Takashi wrote:
> > These drivers are only a line filter and it makes no sense to me to start
> > a wrong filter then apply a correction when we could just start the
> > correct one in the beginning. There is a little autoconf glue the same it
> > is true, but the thing which is different (the IO routines) are the
> > majority of the driver..
>
> A little more brief description, please. I do not understand your
> explanation. ;-<
Ok, I will (try to be :) clear then - from my viewpoint I like this:
UART device - com - tty - btuart - netbt
Nokia device - com - tty - btdtl - netbt
but you are trying to make this:
UART device - com - tty - btuart - uart - netbt
Nokia device - com - tty - btuart - dtl - netbt
where "btuart" in that case consists only of the autoconf glue, plus a
method to select which protocol (uart/dtl) you require.
But, we already have a method (TIOCSLINED, "btuart") to select the line
protocol and the autoconf glue is small. So, I think adding this layer
becomes complex for no good reason.
Ultimately, for this method I think the attach phase becomes subject to
race conditions. There is a time between (TIOCSLINED, "btuart") and
(BTUART_SELECT_PROTOCOL, DTL) when the driver can not know what to do with
received data, which it must process. If you throw it away you risk
becoming out of sync with no way to resync. You can add more complexity to
handle this.. but I prefer simplicity.
iain
Home |
Main Index |
Thread Index |
Old Index