Re: [PATCH v1] core: Relax gpiod_chip_open() for symbolic links

[Bartosz Gołaszewski <bartekgola@xxxxxxxxx>]

pt., 7 lut 2020 o 12:28 Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> napisał(a):
>
> On Fri, Feb 07, 2020 at 12:01:46PM +0100, Bartosz Golaszewski wrote:
> > pt., 7 lut 2020 o 11:30 Andy Shevchenko
> > <andriy.shevchenko@xxxxxxxxxxxxxxx> napisał(a):
> > > On Fri, Feb 07, 2020 at 11:13:43AM +0100, Bartosz Golaszewski wrote:
> > > > czw., 6 lut 2020 o 19:14 Andy Shevchenko
> > > > <andriy.shevchenko@xxxxxxxxxxxxxxx> napisał(a):
>
> ...
>
> > > > thanks for this - it makes perfect sense. One nit though: could you
> > > > keep the includes ordered alphabetically?
> > >
> > > Probably not. The user space relies a lot on header ordering. And limits.h
> > > sounds like one needed to be included first in many cases. That's why I moved
> > > it to the top. I can do it if you insist, but I consider it wrong approach for
> > > the record.
> >
> > Nah, if anything headers may rely on some preprocessor defines coming
> > before them, but the ordering should be of no importance.
>
> Okay, in any case, if you think it's better to be sorted, can you change it
> when applying? (I don't think we need another version simple for that)
>

Sure.

> > > > Also: it would be great if
> > > > you could add a test case for this to tests/tests-chip.c.
> > >
> > > I will look at it if I can do quickly something.
>
> > If not, don't worry - I can add it later myself.
>
> I briefly looked at this, but it seems not feasible to me in reasonable time,
> sorry.
>
> The problems I encountered are, but not limited to:
> - creating a symlink in a test case folder
> - understanding how to handle interrupt of the test case (we have to remove
>   link ourselves or framework does it for us?)
> - where to put the symbolic link creation: I think it might be a (boolean)
>   parameter to gpio-mockup testing API when we "make a chip" (when device node
>   should appear) to enable symlink with a predefined name (like
>   $testpath/gpiochipX-link)
> - last time I did something (simple!) with GLib was several years ago
>

Sure, I can do it myself - it will probably take me much less time.

Bart