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

[Matthew Wilcox <willy6545@gmail.com>]

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

On Fri, Aug 12, 2016 at 1:29 AM, Alexey Dobriyan <adobriyan@gmail.com>
wrote:

> On Fri, Aug 12, 2016 at 12:07:11AM -0400, Matthew Wilcox wrote:
> > > On Thu, Aug 11, 2016 at 11:51:52PM -0400, Matthew Wilcox wrote:
> > > > Can we introduce types for this? We have a number of different return
> > type
> > > > conventions in the kernel:
> > > >
> > > > bool
> > > > errno_t (-4095 to 0 are valid)
> > > > count_t (-4095 to INT_MAX)
> > > > long_count_t (-4095 to LONG_MAX)
> > > > ulong_count_t (-4095 to -4096)
> > > > struct foo _err*
> >
> > I think the biggest problem is coming up with good names for the types.
> And
> > the churn of introducing them, particularly converting function pointers
> > and all occurrences.
>
> Names are easy part (errno_t is perfect actually).


I agree that errno_t is perfect, but it's not really part of a nice family
-- count_t, long_count_t and ulong_count_t are all pretty crappy.  They
don't scream out I MIGHT CONTAIN AN ERRNO, BETTER CHECK ME! the way I would
like.  count_might_be_errno_t is not exactly euphonious.  err_count_t,
perhaps?

Of course, it might not be a count ... at least at one point the NVMe
driver had variables which either contained [-4095 to -1] (Linux errno,
usually -ENOMEM), 0 (success) or 1-65535 (NVMe status code indicating some
device failure).  I think those variables are all gone now, but that's not
an unreasonable thing to want and calling that beast a ushort_count_t would
be untrue.  I suspect for that kind of thing, the driver should create its
own type (or if we did something similar in SCSI, the subsystem would
create a scsi_status_t that was pretty much private to the SCSI subsystem).

[-- Attachment #2: Type: text/html, Size: 2216 bytes --]