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

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]

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.

To tell *which* specific errnos might be returned by a given
function... I can't see any benefit in that ever.

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5760 bytes --]