[Ksummit-discuss] [CORE TOPIC] More useful types in the linux kernel
David Woodhouse
dwmw2 at infradead.org
Wed Jul 27 13:33:43 UTC 2016
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20160727/55dabdb9/attachment.bin>
More information about the Ksummit-discuss
mailing list