Furi: wrap message queue in container, prepare it for epoll. Accessor: disable expansion service on start.

[skotopes]

What's new

• Furi: wrap message queue in container, prepare it for epoll.
• Accessor: disable expansion service on start.

Verification

• Check everything
• And accessor app too

Checklist (For Reviewer)

• [ ] PR has description of feature/bug or link to Confluence/Jira task
• [ ] Description contains actions to verify feature/bugfix
• [ ] I've built this code, uploaded it to the device and verified feature/bugfix

[github-actions[bot]]

Compiled f7 firmware for commit 08a14dd0:

• 📦 Update package
• 📥 DFU file
• ☁️ Web/App updater
• 📊 Size report

[CookiePLMonster]

If the intention behind using a static message queue is memory savings, you could allocate the buffer directly after the queue struct, coalescing those two allocations into one. Since their lifetime is always identical, it might be a good idea to reduce fragmentation and allocation bookkeeping.

GCC extension uint8_t* buffer[]; as the last structure field makes it easy, as this field doesn't contribute to the size of the structure, but dictates the type of a memory buffer following it and also enforces alignment. This means you can just do a single alloc of size sizeof(FuriMessageQueue) + buffer_size.

[skotopes]

If the intention behind using a static message queue is memory savings, you could allocate the buffer directly after the queue struct, coalescing those two allocations into one. Since their lifetime is always identical, it might be a good idea to reduce fragmentation and allocation bookkeeping.

GCC extension uint8_t* buffer[]; as the last structure field makes it easy, as this field doesn't contribute to the size of the structure, but dictates the type of a memory buffer following it and also enforces alignment. This means you can just do a single alloc of size sizeof(FuriMessageQueue) + buffer_size.

Nope, that was not goal. I need ability to extended message queue with additional fields for epoll implementation. This is a first step for that. Also multiple smaller allocations are preferred: more chance to fit them into fragmented memory.

[CookiePLMonster]

Also multiple smaller allocations are preferred: more chance to fit them into fragmented memory.

In the current case you're not winning much - the struct allocation is 12 bytes, but 4 bytes are wasted for a pointer to the other allocation. This means that if those two allocations get merged together, the bigger allocation grows by just 8 bytes - if the memory is fragmented enough for this to matter when allocating the queue, the Flipper is likely about to crash on OOM anyway.

[skotopes]

Also multiple smaller allocations are preferred: more chance to fit them into fragmented memory.

In the current case you're not winning much - the struct allocation is 12 bytes, but 4 bytes are wasted for a pointer to the other allocation. This means that if those two allocations get merged together, the bigger allocation grows by just 8 bytes - if the memory is fragmented enough for this to matter when allocating the queue, the Flipper is likely about to crash on OOM anyway.

I've pushed couple changes that combines your proposal and gives a place for epoll.

[CookiePLMonster]

Also multiple smaller allocations are preferred: more chance to fit them into fragmented memory.

In the current case you're not winning much - the struct allocation is 12 bytes, but 4 bytes are wasted for a pointer to the other allocation. This means that if those two allocations get merged together, the bigger allocation grows by just 8 bytes - if the memory is fragmented enough for this to matter when allocating the queue, the Flipper is likely about to crash on OOM anyway.

I've pushed couple changes that combines your proposal and gives a place for epoll.

Looks optimal, great stuff!