Re: [libgpiod] Rethinking struct gpiod_line_bulk

[Andy Shevchenko <andy.shevchenko@xxxxxxxxx>]

+Cc: Geert as he might give some input to the last paragraphs.
To me, on the shallow glance, it looks fine.

On Mon, Oct 12, 2020 at 6:17 PM Bartosz Golaszewski
<bgolaszewski@xxxxxxxxxxxx> wrote:
>
> 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



-- 
With Best Regards,
Andy Shevchenko