From owner-svn-src-all@freebsd.org Fri Apr 6 10:04:28 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1E20F980BA; Fri, 6 Apr 2018 10:04:27 +0000 (UTC) (envelope-from royger@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74B36719B9; Fri, 6 Apr 2018 10:04:27 +0000 (UTC) (envelope-from royger@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id x82so2214069wmg.1; Fri, 06 Apr 2018 03:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=24vXZUxjJXNFWRN1uqGdqSgXSgZYv+YZQMRxR9RZFlM=; b=KyGRCkvRMGA4c4haE2mH7+7Z3uaMKSmOJpMVAedyQvFF46C9AnjWORQ0xL9aRS0UiA HWwJdInP+CrHgq0yiJ0NeizVWxzf+uMom91B79HDJIu3gvDNyYCCkQmMn8/ezgAMQhnF v1ktienTN0CB+hmQ8jQrZ8R3992X6KBVZDkyyQ0PRpgIDKBEiKlYkgE5WP8a8a49YwE/ CKHlFbOXgbU+S1K0xT+FNDFZwloExMto7XMKXTD+2jJvux/kFU9J1OedXrVQ7NIkUNQ3 w3Ey6RZXInrf2fRLOhigoPkQCh1XXV0k8F5sqXTfOuiVlVnJ59EtwTY8ePEgsJhKjcV6 nEXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=24vXZUxjJXNFWRN1uqGdqSgXSgZYv+YZQMRxR9RZFlM=; b=QKdrhmQPw6I0zEF9M4q0RwLYbXMPt398SAdbRDwJn3KE+hDoZ7hBHsALyDsyjNar1/ yvX/v+tBtgiaWL2In11z5ZVq2ZKj99WwvVAi7fQ7vsLp/Cns5r5ld9wt7BnNrPKfW++t zSrbkQzHbPM6e2DqoQy929x6oiKxdRMMty6RTje5PFoVi7uoPnk0U8A+9yn2zoxMclL2 8nUEXPvZ3kE7N5+c75Py/JGs4uV8InxohroY53md2lxqNp2H3qeRuqYN1HLH7kR4lMwJ LsEWJm8r5hVrQdV5z9nMe0aZWwVc1WgtAItTEhkyN73X8U01McQ88/bLReqxXg6DUIgi atZA== X-Gm-Message-State: ALQs6tAQtf4H6PQu2b1inR/4qxLzfBJhQpMn9MuHPUTOIvMw1IuPDAIA iORU07flWCyctHpxtY1y7wE= X-Google-Smtp-Source: AIpwx493igUMeWgIwHlAJ74/BjuB33ANKWdoHhFAUojDeSC0YMswG95/MB2/1khm6z55MrTOnofiHw== X-Received: by 10.80.137.149 with SMTP id g21mr6234846edg.25.1523009065774; Fri, 06 Apr 2018 03:04:25 -0700 (PDT) Received: from localhost (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id r16sm6157859edb.22.2018.04.06.03.04.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Apr 2018 03:04:24 -0700 (PDT) Sender: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Date: Fri, 6 Apr 2018 11:04:21 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Bruce Evans Cc: Warner Losh , Ian Lepore , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r332072 - head/sys/sys Message-ID: <20180406100421.kumj77n6sfgagozx@MacBook-Pro-de-Roger.local> References: <201804051431.w35EVtg4047897@repo.freebsd.org> <1522942377.49673.245.camel@freebsd.org> <20180405154619.q3blip266qa3z5ut@MacBook-Pro-de-Roger.local> <20180406022720.I3453@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180406022720.I3453@besplex.bde.org> User-Agent: NeoMutt/20180323 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 10:04:28 -0000 On Fri, Apr 06, 2018 at 03:12:08AM +1000, Bruce Evans wrote: > On Thu, 5 Apr 2018, Warner Losh wrote: > > > On Thu, Apr 5, 2018 at 9:46 AM, Roger Pau Monné wrote: > > > > > On Thu, Apr 05, 2018 at 09:32:57AM -0600, Ian Lepore wrote: > > > > On Thu, 2018-04-05 at 14:31 +0000, Roger Pau Monné wrote: > > > > > Log: > > > > > introduce GiB and MiB macros > > > > > ... > > > > > +/* Unit conversion macros. */ > > > > > +#define GiB(v) (v ## ULL << 30) > > > > > +#define MiB(v) (v ## ULL << 20) > > > > > + > > > > > #endif /* _SYS_PARAM_H_ */ > > > > > > > > These names don't make it clear whether the conversion is bytes->GiB or > > > > GiB->bytes. The names seem way too generic for a public namespace in a > > > > file as heavily included behind your back as param.h is. > > > > > > > > Also, this completely reasonable usage won't work, likely with > > > > confusing compile error messages: > > > > > > > > int bytes, gibytes; > > > > ... > > > > bytes = GiB(gibytes); > > > > > > I find those helpful for their specific usage. I could introduce > > > static inline functions like: > > > > > > size_t gb_to_bytes(size_t)... > > > > > > But I assume this is also going to cause further discussion. > > Yes, it gives even more namespace pollution and type errors. Macros > at least don't expose their internals if they are not used. > > size_t is actually already part of the undocumented namespace pollution > in . > > The type errors are restriction to just one type in another way. Type- > generic APIs that avoid such restrictions are much harder to implement > using inline functions than macros. > > > Yea, traditional macro names would be "gibtob" and "btogib" but I didn't > > just reply to bikeshed a name: > > > > But you don't need to specify a type, consider the current btodb macro: > > #define btodb(bytes) /* calculates (bytes / DEV_BSIZE) > > */ \ > > (sizeof (bytes) > sizeof(long) \ > > ? (daddr_t)((unsigned long long)(bytes) >> DEV_BSHIFT) \ > > : (daddr_t)((unsigned long)(bytes) >> DEV_BSHIFT)) > > > > which shows how to do this in a macro, which is orthogonal to any name you > > may choose. I can also bikeshed function vs macro :) > > This macro is mostly my mistake in 1995-1996. The long long abominations > in it were supposed to be temporary (until C99 standardized something > better). It was originally MD for i386 only and then the sizes of almost > all types are known and fixed so it is easier to hard-code minimal sizes > that work. The optimization of avoiding using 64-bit types was more needed > in 1995-1996 since CPUs were slower and compilers did less strength reduction. > > btodb() is much easier than dbtob() since it shifts right, so it can't > overflow unless the cast of 'bytes' is wrong so that it truncations. > dbtob() doesn't try hard to be optimal. It just always upcasts to > off_t. > > jake later convinced me (in connection with his PAE and sparc64 work) that > it should be the caller's responsibility to avoid overflow. Any casts in > the macro limits it to the types in it. This is why the page to byte > conversion macros don't have any casts in them. PAE usually needs 64-bit > results, but this would just be a pessimization for normal i386, and > deciding the casts in the macro as above is complicated. > > So correct GB() macros would look like ((v) << 30), where the caller must > cast v to a large enough type. E.g., for variable v which might be larger > than 4, on 32-bit systems, the caller must write something like > GB((uintmax_t)v). But it is easier for writing to just multiply v by 1G. > This is also easier for reading since it is unclear that GB() is even a > conversion or which direction it goes in. A longer descriptive name would > be about as clear and long as an explicit multiplication. > > I usually write 1G as ((type)1024 * 1024 * 1024) since the decimal and > even hex values of 1G have too many digits to be clear, and > multiplication is clearer than shifting and allows the type to be in > the factor. > > Disk block size conversions need to use macros since the DEV_BSIZE = 512 > was variable in theory (in practice this is now a fixed virtual size). > Conversions to G don't need macros since the magic number in them is no > more magic than the G in their name. I personally find the following chunk: if (addr < GiB(4)) ... Much more easier to read and parse than: if (addr < (4 * 1024 * 1024 * 1024)) ... But I won't insist anymore. I will revert this and introduce the macros locally where I need them. Roger.