Date: Thu, 7 Nov 2002 13:48:11 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Sam Leffler <sam@errno.com> Cc: arch@FreeBSD.ORG, "Long, Scott" <Scott_Long@adaptec.com>, re@FreeBSD.ORG, Maksim Yevmenkin <myevmenk@exodus.net>, Murray Stokely <murray@freebsdmall.com> Subject: Re: Bluetooth code Message-ID: <Pine.BSF.4.21.0211071328530.5860-100000@InterJet.elischer.org> In-Reply-To: <031401c2869f$db71b720$52557f42@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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). 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. > 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. 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. > 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. > 3. A bluetooth(4) man page would be useful. true. > > 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. > > Sam > > 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?Pine.BSF.4.21.0211071328530.5860-100000>