Skip site navigation (1)Skip section navigation (2)
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>