Date: Mon, 15 Apr 2002 16:24:09 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Maksim Yevmenkin <myevmenk@digisle.net> Cc: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Bluetooth stack for FreeBSD Message-ID: <Pine.BSF.4.21.0204151548160.88655-100000@InterJet.elischer.org> In-Reply-To: <3CBB36DB.850B4BEE@digisle.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi...
I have been reading the (well actually, "looking at"
may be more acurate..
some minor comments..
ng_btsocket.c: unmodified: line 674
sbappendrecord(&pcb->so->so_snd, m);
m = m_dup(m, M_TRYWAIT);
if (m == NULL) {
error = ENOBUFS;
goto drop1;
}
you are m_dup'ing an mbuf you have given away to the socket layer.
on an SMP system this may already be destroyed by the time
you do the m_dup() in fact if the sbappendrecord() fails
due to a full queue, it may already be invalid...
(I think)
also all functions should be 'prototype format'
e.g.
static int
ng_btsocket_peeraddr(so, nam)
struct socket *so;
struct sockaddr **nam;
{
should be:
static int
ng_btsocket_peeraddr(struct socket *so, struct sockaddr **nam)
{
also:
__P() is now "deprecated" and should not be used in new code.
Your idea of making a special bluetooth socket type, implemented by
a Netgraph node is interesting. Maybe we should it easier to do this
by extending the netgraph socket type with the ability to
make sockets of arbitrary types... i.e. register a node type that acts
as a 'subtype' of the 'socket' type, and inherrits generic
socket behaviour, but allow the 'child type' to specify
other parts to replace normal behaviour.. I guess we would need to see a
few more cases of this done before we could deduce what is
likely to be a good candidate for abstraction.
you ask:
/*
* XXX FIXME/VERIFY i assume here that "hook" is a pointer
* to the local hook we have received message from. For
* L2CAP messages "hook" is required.
*/
This is true for 5.0
in 4.x there is no such thing as an arrival hook for a message.
You should however not assume that it is non-NULL. test it in
normal running code.. not in a KASSERT. There are transitional moments
(during shutdown for example) when a message may arrive without a hook,
in fact a malicious user might force that to happen at any time by
simply send ing that message directly to the ID of the node.
For messages passed by a neighbour via a hokk the hook field will be
filled in but there are other ways that you may get a message.
[out of time for now.. will read more later]
Julian
On Mon, 15 Apr 2002, Maksim Yevmenkin wrote:
> Folks,
>
> [probably should be cc'd to -mobile as well]
>
> An engineering release of Bluetooth stack for -current FreeBSD
> is available for download at
>
> http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020415.tar.gz
>
> i'm interested to hear from people who familiar with FreeBSD
> kernel, Netgraph and/or Bluetooth. all your questions/comments/
> suggestions are accepted and greatly appreciated. this is my
> first Netgraph stack, so please don't me hard :)
>
> thanks,
> max
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" 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.0204151548160.88655-100000>