Date: Fri, 10 Mar 2006 20:23:27 +0000 (GMT) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: whitespace Message-ID: <1142022207.888900.3096.nullmailer@galant.ukfsn.org> In-Reply-To: <4411C626.8030702@savvis.net> References: <1141762244.118700.5588.nullmailer@galant.ukfsn.org> <440DEE78.5020500@savvis.net> <1141767948.252179.12317.nullmailer@galant.ukfsn.org> <440E0233.7080703@savvis.net> <1141775918.215241.15084.nullmailer@galant.ukfsn.org> <440E2D3F.6040800@savvis.net> <1141807931.899207.8150.nullmailer@galant.ukfsn.org> <44107C19.6050302@savvis.net> <1141980206.657073.302.nullmailer@galant.ukfsn.org> <4411C626.8030702@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 10 Mar 2006, Maksim Yevmenkin wrote:
> ok, i think, i understand what you are saying now. it seems like you are
> objecting to the fact that all sockaddr_* in bluetooth domain have family set
> AF_BLUETOOTH.
Well yes and no - I agree that family should be AF_BLUETOOTH throughout of
course :) I just feel that all addresses in the domain should be
compatible. That seems to me to be partly the definition of the domain
though its not strict - from netintro(4)
--8<----
A protocol family may support multiple methods
of addressing, though the current protocol implementations do not.
[...]
Protocols normally accept only one
type of address format, usually determined by the addressing structure
inherent in the design of the protocol family/network architecture.
--8<----
and for me at least, it seemed much simpler and neater to use the same
address type throughout, so I did. Until its published though, nothing is
fixed in stone :)
> this is somewhat similar to AF_INET family where you can have IP, ICMP, TCP,
> UDP, etc. protocols. all within the same AF_INET family/domain.
On NetBSD at least, all these use 'struct sockaddr_in' for addressing :)
> please consider another example: lets say another rfcomm-like protocol is
> defined and added to the bluetooth stack. if you have flat sockaddr_bt you
> might need to add some fields to sockaddr_bt structure to implement new
> protocol. this will likely to break binary compatibility. if you have separate
> sockaddr_bt_x per protocol - you are safe.
Hey thats a good point, it should be padded..
> > Actually, I can see a partial reason to have the HCI_RAW socket address
> > different, in that bluetooth devices have no address available until they
> > are up and running. I handled the device initiation in kernel and didnt
> > notice that until recently.
>
> yes, that was the reason (at least for me) to keep initialization procedure in
> user space. it seems like more flexible solution to me. i thinking about
> manufacturer specific initialization sequences.
Hm, yes but are there any? - actually the only initialisation that I do
currently is Read_BDADDR and Read_Buffer_Size.
> > ((L2CAP, PSM=0x1001), (RFCOMM, CN=1), (Obex), (vCal))
> > ((L2CAP, PSM=0x1002), (RFCOMM, CN=1), (Obex), (Other))
>
> have you tried with, say, with mobile phone. have you tried to advertise
> rfcomm-based service on different psm? did the phone made connection to the
> right psm to open rfcomm session?
No, I didnt try to get any incoming services running as yet, I'm having
trouble setting up connections to my mouse and I'm not exactly sure why
(though, it seems ok when the connection is up)
Incidentally, in bthidd you used select() to wait on fd's and I notice
that if the channel is lost for whatever reason, bthidd does not seem to
close the socket. I guess this is because it is not selecting on
'exceptfds'? I'm not sure what 'an exceptional condition' is in any case,
but I guess that the socket being disconnected could be part of that..
regards,
iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1142022207.888900.3096.nullmailer>