[libgpiod] Rethinking struct gpiod_line_bulk

[Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx>]

Hi!

One of the things I'd like to address in libgpiod v2.0 is excessive
stack usage with struct gpiod_line_bulk. This structure is pretty big
right now: it's an array 64 pointers + 4 bytes size. That amounts to
260 bytes on 32-bit and 516 bytes on 64-bit architectures
respectively. It's also used everywhere as all functions dealing with
single lines eventually end up calling bulk counterparts.

I have some ideas for making this structure smaller and I thought I'd
run them by you.

The most obvious approach would be to make struct gpiod_line_bulk
opaque and dynamically allocated. I don't like this idea due to the
amount of error checking this would involve and also calling malloc()
on virtually every value read, event poll etc.

Another idea is to use embedded list node structs (see include/list.h
in the kernel) in struct gpiod_line and chain the lines together with
struct gpiod_line_bulk containing the list head. That would mean only
being able to store each line in a single bulk object. This is
obviously too limiting.

An idea I think it relatively straightforward without completely
changing the current interface is making struct gpiod_line_bulk look
something like this:

struct gpiod_line_bulk {
    unsigned int num_lines;
    uint64_t lines;
};

Where lines would be a bitmap with set bits corresponding to offsets
of lines that are part of this bulk. We'd then provide a function that
would allow the user to get the line without it being updated (so
there's no ioctl() call that could fail). The only limit that we'd
need to introduce here is making it impossible to store lines from
different chips in a single line bulk object. This doesn't make sense
anyway so I'm fine with this.

What do you think? Do you have any other ideas?

Best regards,
Bartosz Golaszewski