[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] it's so big



 
> On Tue, 13 Mar 2001, Gordon McNutt wrote:
> > >    could instead be allocated dynamically for each new active
> > >    (non parked/hold) hci handle.
> > 
> > Have you ever considered using sk_bufs? I'm not too 
> familiar with Linux
> > networking internals, but I know on some embedded OS's the 
> kernel already keeps
> > a pool of buffers for networks. This idea also applies to 
> your comment about
> 
> The skbuf's are just an interface for passing data in the 
> network-stack,
> there is nothing different really about an allocation of an 
> skbuf than a
> chunk of memory (there is no pool of skbufs and there are 
> reasons why this
> is not desirable). There are some helper abstractions for 
> shrinking and
> growing to remove/fit headers and stuff but I'm not sure that would be
> useful for your hci buffers. If you need dynamic memory, a 
> simple kmalloc
> would do fine for this I'm sure.
> 

The idea was not to use skbufs for the hci inbuffers, here kmalloc 
will do fine, but when when sending data 'down' in the stack rfcomm->l2cap->hci,
skbufs might be a nicer solution instead of using btmem (see btmem.c).

> When the IP over L2CAP system works, you'd certainly want to 
> hook the BT
> driver into the network stack to send up/down IP packets in 
> skbufs though.
> 
> -BW
> 

Wouldn't it be nice if we could use skbufs all the way from IP down to HCI ?

/Mattias 
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com