Date: Thu, 07 Nov 2002 14:42:28 -0800 From: Maksim Yevmenkin <myevmenk@exodus.net> To: Julian Elischer <julian@elischer.org> Cc: Sam Leffler <sam@errno.com>, arch@FreeBSD.ORG, "Long, Scott" <Scott_Long@adaptec.com>, re@FreeBSD.ORG, Murray Stokely <murray@freebsdmall.com> Subject: Re: Bluetooth code Message-ID: <3DCAEC54.8DA9179A@exodus.net> References: <Pine.BSF.4.21.0211071328530.5860-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Julian Elischer wrote: > > On Thu, 7 Nov 2002, Sam Leffler wrote: > > > I made a quick pass over this code. It's not clear to me why this stuff is > > or should be dependent on netgraph. The code looks to support a new > > protocol domain and sockets within that domain so it would seem possible for > > it to stand apart from netgraph. > > Yes, though bluetooth includes other dimensions that don't fit into that > mold so easily. right. new protocol domain and sockets is just the one part of the code (optional). the code also includes support for low level Bluetooth procotols such as 1) HCI (Host Controller Interface) transport layers: H4 and UBT 2) HCI (Host Controller Interface) - not a network protocol, but a generic framework to talk to any Bluetooth device 3) L2CAP (Link Layer Control and Apaptation Protocol) - connection oriented procotol that runs over Bluetooth ACL (asynhronuous) data link. > The author decided that he'd develop it under netgraph as it made his > job easier. (as it was designed to do). When the code is fully > functional, it would be a relatively simple matter > to 'un-netgraph it should that be required. (personally I see no > reason to do so). It's designed to allow that (should that be seen as a > good idea (I don't think it matters). right. this code is a proof of concept that Netgraph can be used to do more then just a link layer protocol. it gives you advantage to use all flexiblity of Netgraph. it gives you a choice which modules you want to use. in fact one can throw away L2CAP and sockets and work directly on HCI layer (if so required). > Netgraph is designed for rapid prototyping and development, but it still > uses the standard mbufs etc. so that code developed under netgraph > conforms to standard networking rules. With the new TAG > code this is more true than ever. The bluetooth code however is not > at that stage yet. hmm... not sure what is "new TAG code", but i will look into it. > > A bluetooth implementation that was not > > tied to netgraph would be preferrable as freebsd users would get the > > benefits of additional (non-freebsd users) working with the code. > > > > NetBSD have their own bluetooth code that goes in /sys/dev/bluetooth. > You are free to port that when (if) it's ready, in fact > we are using netgraph/bluetooth specifically to not collide with that. right. i'm not sure what is the status of Bluetooth code in NetBSD, but CVSweb does not have much. i always wanted to keep my code under netgraph/ for two reasons 1) to indicate the fact that this is a Netgraph code 2) to make sure this code will not collide with any future Bluetooth stack in FreeBSD > It is much easier to develop under netgraph than not, > as you have all the tools to independently test modules, unload them, > change them, reload tehm, and pass captured packets through them. > Netgraph supplies all the framework that allows protocol code to be > developed easily It is designed for link-level packet manipulation and > the socket code is particularly lousy at that, having been developed for > network and transport level protocols. The two are actually a good fit. > (for example whiel one COULD make a TCP stack in Netgraph (and in fact > someone is trying to do that just for fun), it doesn;t gain you > anything, but it DOES gain you a lot to do lower level manipulations > through netgraph, as you can do various link-level tricks using common > components at that level and the multiplexing requirements are > different. > > > > Specific stuff: > > > > 1. Why isn't btsockstat integrated into netstat? > > So that no standard programs need be altered.. > when the dust settles it can be done. the project was advertised as separate from FreeBSD. i do not want to alter existing FreeBSD code in any way (well, perhast just a little bit to add new TTY line discipline and socket family). another reason is that btsockstat tied to btsocket module. i'm not sure that btsocket will be one and only Bluetooth socket implementation. this code is an optional. > > 2. l2test, hcdump, and hcinfo are missing (cited in man pages). > > their functionality has been absorbed into other programs.. > the man page should be updated. right. i should fix the man pages. > > 3. A bluetooth(4) man page would be useful. > > true. agree. i will write it. > > It's unclear to me how this support is used. There are no user-level > > applications that make use of it and I don't recognize existing applications > > that could use it. I suggest that w/o a "real user" adding this stuff to > > the system is premature. > > There is no point in user apps until there is kernel support. > it's a chicken and egg thing and I'd like to break the cycle > by adding this code now. i'm not sure what do you mean by user-level application. if you are talking about setup/control utility (a-la ifconfig) then hccontrol is everything you need. also Bluetooth has something called RFCOMM with is serial port over Bluetooth. user-space application localy works with /dev/tty just like it always did, but internally all communication is done via Bluetooth wireless link. Note: RFCOMM currentlly done in user-space, but it will be moved to kernel. another thing is a BNEP (Bluetooth Network Encapsulation Protocol) (not implemented yet). it is sort of Ethernet over Bluetooth. for each Bluetooth device there is a virtual Ethernet interface + Ethernet bridge. nodes can talk as soon as they in RF proximity. right now you can 1) run PPP over Bluetooth (LAN profile). 2) use Bluetooth to talk to your cell phone and use cell phone as wireless modem. DUN (Dial-UP networking) profile. 3) the OBEX server support is coming soon, so one can sync cell phone (or PDA) over Bluetooth. get pictures from digital camera, etc. most of these stuff was ported from Linux BlueZ stack and will be incuded (hopefully) into FreeBSD ports/ tree. thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DCAEC54.8DA9179A>