Re: [igt-dev] [PATCH i-g-t] tests/kms_frontbuffer_tracking: Accept missing FBC debugfs files

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Nov 25, 2021 at 11:59:30AM +0200, Petri Latvala wrote:
> On Thu, Nov 25, 2021 at 11:50:06AM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 24, 2021 at 05:25:06PM +0200, Petri Latvala wrote:
> > > On Wed, Nov 24, 2021 at 05:12:45PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > With multiple FBC instances becoming a thing at some point
> > > > the current plan is to go with separate debugfs files for
> > > > each FBC instance. Which also means that if there is no
> > > > FBC there will be no debugfs files either. Adapt the test
> > > > to tolerate such conditions.
> > > > 
> > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > ---
> > > >  tests/i915/kms_frontbuffer_tracking.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/tests/i915/kms_frontbuffer_tracking.c b/tests/i915/kms_frontbuffer_tracking.c
> > > > index d6a884926c48..532bfbb9b481 100644
> > > > --- a/tests/i915/kms_frontbuffer_tracking.c
> > > > +++ b/tests/i915/kms_frontbuffer_tracking.c
> > > > @@ -724,7 +724,7 @@ static void __debugfs_read(const char *param, char *buf, int len)
> > > >  {
> > > >  	len = igt_debugfs_simple_read(drm.debugfs, param, buf, len);
> > > >  	if (len < 0)
> > > > -		igt_assert_eq(len, -ENODEV);
> > > > +		igt_assert(len == -ENOENT || len == -ENODEV);
> > > 
> > > If this fires, we now lose the information on what the error
> > > was. Although we automatically print errno in that case, is the error
> > > in there?
> > 
> > Not quite sure what you're asking here. But at least igt_assert() will
> > still print the errno here, if that's what you're asking.
> 
> igt_assert_eq prints the value of "len" if it's not -ENODEV,
> igt_assert doesn't. What I'm asking is whether igt_debugfs_simple_read
> leaves the error it returns in errno. I could check but ECOFFEE.

Yes, errno seems to be preserved.

Quick check of the code agrees. Well, except for the case of close()
failing after read() failed, which would clobber the errno from read().
But close() failing would be pretty nuts.

-- 
Ville Syrjälä
Intel