[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bluetooth-dev] it's so big
Mattias Ågren wrote:
> Here is some things that I can think of in order to decrease the footprint of
> the kernel code :
> 1. Use dynamic hci inbuffers in hci.c, today we use 7 x 800 bytes
> (struct hci_controller), one per active hci handle. Each buffer
> 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
btmem. One possible downside is that you'd have to have networking turned on in
the kernel, and this might be a bigger cost than it's worth if you otherwise
don't want networking.
> 2. All vendor specific code should be moved up to a usermode lib which
> uses the 'raw' hci interface. Thus we also can control different HW
> from one place only (no need to recompile kernel).
> 3. Most of the hci commands that are not needed in order to run the
> basic functionalities of the stack e.g connect, send data, disconnect
> etc could probably also could be moved to a usermode library.
Ok, this is interesting. What did you have in mind? Would each lib call need a
corresponding ioctl (in which case where's the benefit?), or were you thinking
of something else?
> 4. There are a lot of code that are repetetive and could be
> more efficient by adding some subroutines (e.g when setting
> headers in each layers message/command).
I reckon we could get 3-5K out of each of hci, l2cap and rfcomm by doing this,
and by cleaning up the state machines with an eye for size reduction.
> 5. Btmem outbuffer could probably be decreased some (some empirical
> test would probably show how much).
> Is there anyone that has the time to look more deeply into these kind
> of issues ?
I will try to spend some time looking at issue #4. I don't have a lot of time
right now but I can run it in the background.
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org