On Fri, Aug 12, 2016 at 1:29 AM, Alexey Dobriyan 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).