From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3E025279 for ; Fri, 12 Aug 2016 05:50:31 +0000 (UTC) Received: from mail-ua0-f193.google.com (mail-ua0-f193.google.com [209.85.217.193]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 95B0511D for ; Fri, 12 Aug 2016 05:50:30 +0000 (UTC) Received: by mail-ua0-f193.google.com with SMTP id u13so1329960uau.0 for ; Thu, 11 Aug 2016 22:50:30 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160812052919.GB2289@p183.telecom.by> References: <87inw1skws.fsf@x220.int.ebiederm.org> <25598.1469113525@warthog.procyon.org.uk> <18158a39-1297-7368-3c0e-3e9b3ce2c3ab@suse.com> <20160811154429.GB4134@mwanda> <20160812040155.kvw5322jqshtmljb@x> <20160812052919.GB2289@p183.telecom.by> From: Matthew Wilcox Date: Fri, 12 Aug 2016 01:50:28 -0400 Message-ID: To: Alexey Dobriyan Content-Type: multipart/alternative; boundary=001a11439cbcbf45df0539d975db Cc: "ksummit-discuss@lists.linuxfoundation.org" , Dan Carpenter Subject: Re: [Ksummit-discuss] [CORE TOPIC] More useful types in the linux kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --001a11439cbcbf45df0539d975db Content-Type: text/plain; charset=UTF-8 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). --001a11439cbcbf45df0539d975db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 12, 2016 at 1:29 AM, Alexey Dobriyan <adobr= iyan@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 wro= te:
> > > Can we introduce types for this? We have a number of differe= nt 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 pointe= rs
> and all occurrences.

Names are easy part (errno_t is perfect actually).
=

I agree that errno_t is perfect, but it's not reall= y part of a nice family -- count_t, long_count_t and ulong_count_t are all = pretty crappy.=C2=A0 They don't scream out I MIGHT CONTAIN AN ERRNO, BE= TTER CHECK ME! the way I would like. =C2=A0count_might_be_errno_t is not ex= actly euphonious. =C2=A0err_count_t, perhaps?

Of c= ourse, it might not be a count ... at least at one point the NVMe driver ha= d variables which either contained [-4095 to -1] (Linux errno, usually -ENO= MEM), 0 (success) or 1-65535 (NVMe status code indicating some device failu= re).=C2=A0 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.=C2=A0 I suspect for that kind of thing, the driver should create i= ts own type (or if we did something similar in SCSI, the subsystem would cr= eate a scsi_status_t that was pretty much private to the SCSI subsystem).
--001a11439cbcbf45df0539d975db--