[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.
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.
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org