Date: Thu, 7 Nov 2002 15:06:56 -0800 From: "Sam Leffler" <sam@errno.com> To: "Julian Elischer" <julian@elischer.org> 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: <038501c286b2$5efb1890$52557f42@errno.com> References: <Pine.BSF.4.21.0211071328530.5860-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, 7 Nov 2002, Sam Leffler wrote:
> > 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.
>
> <...netgraph PR deleted...>
>
I don't want to see multiple instances of Bluetooth support in the system.
As you noted there's a netbsd implementation already. Having multiple
incompatible implementations of the same protocol stack is silly. If this
one is better than the netbsd one then great, but I want to see answers to
these questions.
Using netgraph for prototyping is fine. Using it for a final version means
only freebsd users can make use of it. There aren't enough *bsd users
around to not _TRY_ to get everyone sharing code. Perhaps you should port
netgraph to other bsd's?
> > 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.
>
No, this is not a chicken and egg problem. If the bluetooth support is
useful then it must be useful for something. If there's nothing users can
do with the support then it'll languish. You've already noted this stuff is
loadable as modules so there is no barrier to the code coming in later or
being maintained separately.
As Maksim noted however there is an OBEX server coming soon. _THIS_ is
justification for having the support in the kernel.
I like this work. I think it deserves inclusion in the system somewhere.
I'm not keen on it being tied to netgraph but undoing that is obviously
major work. What I'd most like to understand is how it compares to the
netbsd implementation and if it's going to be actively used and maintained.
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?038501c286b2$5efb1890$52557f42>