[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [bluetooth-dev] it's so big
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.
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.
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).
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 ?
> -----Original Message-----
> From: Gordon McNutt [mailto:email@example.com]
> Sent: den 13 mars 2001 16:37
> To: Peter Kjellerstedt
> Cc: firstname.lastname@example.org
> Subject: Re: [bluetooth-dev] it's so big
> Peter Kjellerstedt wrote:
> > > -----Original Message-----
> > > From: Gordon McNutt [mailto:email@example.com]
> > > Sent: 13 March 2001 14:22
> > > To: firstname.lastname@example.org
> > > Subject: [bluetooth-dev] it's so big
> > >
> > > I recently cross-compiled the stack for ARM and it churned out a
> > > whopping 100K. Granted, this is better than the 250K that it used
> > > to be before someone kindly tuned down the HCI buffers, but it
> > > still comprises about 20% of my total kernel size.
> > I assume this is with all Bluetooth debug off?
> Good point. With all debug off I drop 10K to end up with 90K
> (~18% of the
> total kernel). I also have proc config'd off. Still kinda hefty.
> Hm... I just checked BlueDrekar and it sits at 143K (compiled
> for x86 &
> not counting their lib & user space stuff) so at least we're
> Still, for embedded devices I'd prefer the option of
> something smaller.
> Probably other people would, too.
> > The problem is do define which features belong to the different
> > sets of features in the stack. And which should be possible to
> > turn on/off.
> Sure. One thing that stands out in my mind is the metric ton of
> HCI commands which we could implement if we want them all.
> hci.c is the
> biggest at 32K, and I don't think we have all the commands in
> there yet.
> At one point I fantasized about having a config for each. But that's
> probably insane.
> I'll poke around a bit in the next two biggest, rfcomm (20K) and l2cap
> (18752). After these bluetooth.o is 12K and the rest are piddly.
> One thing I did do in my local copy is make TCS (and hence
> SCO support)
> removable. This might be amenable to other folks, maybe?
> To unsubscribe from this list: send the line "unsubscribe
> bluetooth-dev" in
> the body of a message to email@example.com
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org