[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [bluetooth-dev] it's so big
> > 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
No, I'm not that familiar with them but I agree that they seem to fit
pretty nicely !
> 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.
Maybe it's possible to use the buffer handling code without
the actual networking running ?! I'll look into it once I get some time...
> > 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?
Look how the function ericsson_test_control() works in btd.c
Here we use one ioctl (HCISENDRAWDATA) to send a raw data chunk
containing a hci command directly down to hci.
Right now the parsing of the return params are still handled
in the kernel but that could probably be easily fixed so that
each raw hci command blocks until a response is received and
then returns the raw response up to usermode.
Depending on how you link your usermode apps with this lib I guess
here could be benefits in code size aswell.
> > 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