tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: btuart and SOCKET Bluetooth CF



On Thu, 18 Feb 2010, KIYOHARA Takashi wrote:

> Hi! Iain,
>
> From: Iain Hibbert <plunky%rya-online.net@localhost>
> Date: Thu, 18 Feb 2010 11:53:50 +0000 (GMT)
>
> > On Thu, 18 Feb 2010, KIYOHARA Takashi wrote:
>
> > > > +static int
> > > > +btuart_dtl_probe(dev_t dev)
> > > > +{
> > > > +#if NCOM > 0
> > >    :
> > > > +#endif
> > > > +       return 0;
> > > > +}
> > > >
> > > > I really dislike this function, it depends on internals of com driver 
> > > > [btw
> > > > COMUNIT(x) would be (minor(x) & COMUNIT_MASK)] and pcmcia and using this
> > > > method prevents a soft emulator and/or needs kernel modifications to
> > > > handle any new device.
> > >
> > > We are expecting the minor number to be obtained.  In my opinion, it is
> > > necessary to open() the device node for that.  Therefore, only minor()
> > > is called.  It thinks dependence on the structure of pcmcia(4) for other
> > > way not to exist though it is very regrettable.  ;-<
> >
> > I don't understand why you want to make it complex in this way?
> >
> > in the beginning, the admin must recognise that they have a Nokia DTL
> > device, eg:
> >
> > # btattach dtl /dev/tty03 19200
> >
> > btattach will perform the device specific initialisation, and set the line
> > to use the protocol that is required.  Why do you desire to forget this
> > knowledge of the protocol type and require the btuart.c to depend on
> > possibly unrelated parts of the kernel to re-discover it later?
>
> hmm..
> I do not like to make new line disc for LSI named NOKIA DTL.
>
> > I find it makes no sense to do it that way, and furthermore the method
> > will cause problems for any user who wishes to use the Nokia DTL protocol
> > in a way that is not previously defined by you.
>
> To begin with, what is the NOKIA DTL protocol?
> NOKIA DTL is LSI.

I call it "protocol" because it is a method for communicating data between
devices using a certain encapsulation.

The "line discipline" is a filter that translates between the line
protocol and the protocol that the kernel is expecting.

That this protocol is only used by one device does not mean that it is
only for use by that device. Who is to say that it will not be used again
for another? How if somebody produces a USB->PCMCIA device that does not
expose the PCMCIA part and this device becomes connected as "com at ucom"?
I do not know if this is possible but I think it unwise to limit the
possibilities. Certainly it would be possible to have a software HCI
emulator using /dev/pty (perhaps to tunnel bluetooth connections over the
internet) but your method would refuse it to work with this protocol..

> We might separately make btdtl.c.
> # However, I will not make it...

I already agreed to integrate with btuart.c, but vastly simpler to provide
an .l_name = "btdtl" as was previously suggested..

iain




Home | Main Index | Thread Index | Old Index