[Ksummit-discuss] [CORE TOPIC] More useful types in the linux kernel

[Bird, Timothy]

> -----Original Message-----
> From: ksummit-discuss-bounces at lists.linuxfoundation.org [mailto:ksummit-
> discuss-bounces at lists.linuxfoundation.org] On Behalf Of David Woodhouse
> Sent: Wednesday, July 27, 2016 5:34 AM
> To: James Bottomley <James.Bottomley at HansenPartnership.com>; Julia Lawall
> <julia.lawall at lip6.fr>
> Cc: ksummit-discuss at lists.linuxfoundation.org
> Subject: Re: [Ksummit-discuss] [CORE TOPIC] More useful types in the linux
> kernel
> 
> On Wed, 2016-07-27 at 09:25 -0400, James Bottomley wrote:
> > On Wed, 2016-07-27 at 14:40 +0200, Julia Lawall wrote:
> > >
> > > On Tue, 26 Jul 2016, David Woodhouse wrote:
> > >
> > > > On Fri, 2016-07-22 at 15:57 +0200, Hannes Reinecke wrote:
> > > > >
> > > > > > I guess that almost all functions return only a few possible
> > > > > > error codes?
> > > > >
> > > > > Precisely. If we had a way of specifying "the return value is an
> > > > > errno with the possible values '0', '-EIO', and '-EINVAL'" that
> > > > > would be _so_ cool.
> > > >
> > > > And perpetually out of date. Because functions call through to
> > > > *other* functions which might return an errno outside the 'known'
> > > > set.
> > >
> > > If you have a script to calculate it, it doesn't have to be
> > > perpetually out of date.  The problem is just the time to collect the
> > > information for the whole kernel.  It could be a good intern project.
> >
> > It's a lot of pain, for what gain?  What, practically would we get as a
> > benefit if we did this?  Every time I see proposals about scripting
> > checks in the kernel, I'm reminded of our section mismatch debacle.
> >  Life is so much easier without every kernel release generating 100s of
> > patches trying to correct section mismatches which didn't matter in the
> > first place ...
> 
> To find functions where the -errno returns might be ambiguous with real
> valid return values, might be beneficial. If it doesn't have too many
> false positives.

It might be useful to have a list of possible errno generation points, for a particular routine,
to make it easier to find the origin of a problem.  Sometimes when you're unfamiliar with
some bit of code, manually walking back through the call chain in the source is a hassle.
I'm reminded of that trick where someone (I don't recall who) embedded the line number
in the errno.