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).