From owner-freebsd-arch@freebsd.org Fri Oct 4 02:44:07 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EE402F84F9 for ; Fri, 4 Oct 2019 02:44:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46kvMq048Tz3MRc for ; Fri, 4 Oct 2019 02:44:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72f.google.com with SMTP id f16so4459257qkl.9 for ; Thu, 03 Oct 2019 19:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MGgQlz0zUoHXFrrA4Mg+GSC256tg3x23Zz0W6bb/Rps=; b=ISYGWEqAmCVJhU+0ohBIseuoH/N3Z2m2G9V3AwmBApXIZ8Ir1n5gsMk7WZTXytmzuM 89XkyE9oh1tHJWfBoLT84i9ifvd+xUQlOqtxM1ZvdjTyIb9ZxGUnA9PC5r+i6TctWtBZ Z6pnDQWtVMvaEYG3oRPxcV8EnrBzo1Rr42KsC8o0778XDA0IlZw4uQkUuKtPB7Vx3Uve ceOkbGf88vY468VPEhECP9yluls42WAO4bh6IsTDl5+2sHZxS1GpQ15aKzAo7ERly7T2 NxxGGXQ164BNK8H+T2bQ18+sMMtmMrx254eaAnrjrDC+dfQGqVJwkdnvYAk4rWV/YHrQ PlCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MGgQlz0zUoHXFrrA4Mg+GSC256tg3x23Zz0W6bb/Rps=; b=GbyhICyunirPj3wkkCbWbnztR/KIuwukJ3XBEnln9nWIouoLKP9WuBC4KZWoRvZvAA mtQEZf4Ouzg82vqWBuTqrlBCqqq4JfPwTXl1s2p9xDv9uA4G+b/xzWN5n+s5JBTdm4Ot bz+Y/C1JgzUUEztps25Z8gvHAG45ZSiJQOjYu8mq07hx7xoOtW5gHRuet/pFgWNGtCaB 7WrDZnNRUi6daDRXRNz9qYAiG9TLJOLSmKPSoPZVkAXt7OJ/6fffdIXCMZT1fR2gRsan 2Nysoqtk+YV7MQg4AjQU9xbViUZpijwsJyl5qs/aXZXGyfR76Z1NUUc0O93M/IADjgKD yl3w== X-Gm-Message-State: APjAAAU+QLgBpx5nVfSMM4Hi3hEhhzRAHddVoCjK8GB/ehImXKWAh0QT MoajB2uBaz6ZL0K7BUn5I5tUWLvj1of3/+w5aR4SrZ6r X-Google-Smtp-Source: APXvYqz4GtzPyaHpdrHCjvN9WgJ+fBszVYGkGlwqf7dvsUMVz4XtERK2h7HfuWEXuVcgCqe0THeY8z/eESHxozmrRsU= X-Received: by 2002:a05:620a:6af:: with SMTP id i15mr7795239qkh.380.1570157045443; Thu, 03 Oct 2019 19:44:05 -0700 (PDT) MIME-Version: 1.0 References: <201910040210.x942A1pu029152@mail.karels.net> In-Reply-To: <201910040210.x942A1pu029152@mail.karels.net> From: Warner Losh Date: Thu, 3 Oct 2019 20:43:53 -0600 Message-ID: Subject: Re: Dropping the type argument from the mtod macro To: Mike Karels Cc: "Conrad E. Meyer" , freebsd-arch@freebsd.org X-Rspamd-Queue-Id: 46kvMq048Tz3MRc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=ISYGWEqA; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::72f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-4.84 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[f.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.84)[ip: (-9.44), ipnet: 2607:f8b0::/32(-2.57), asn: 15169(-2.16), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 02:44:08 -0000 On Thu, Oct 3, 2019, 8:10 PM Mike Karels wrote: > > Hi all, > > > (net@ is BCC'd to keep discussion on arch@.) > > > In the past we've moved away from macros with explicit types as > > parameters, in favor of casting void* results as needed (e.g., > > MALLOC()). > > > I'd like to do the same with mtod. The refactoring is easy enough to > > do safely with a Coccinelle semantic patch. The semantic patch > > converts instances of "mtod(m, t)" to "(t)mtod(m)". > > > markj@ and rrs@ both point out that the network stack uses the type > > argument as a visual tool in large functions where the declaration of > > the lvariable isn't necessarily nearby its use. I think the > > "(t)mtod(m)" preserves that utility as a visual tool; I may be > > mistaken. > > > Currently, the semantic patch drops the explicit "(t)" in two limited > > cases: "t" is "void *", or the "mtod()" invocation is used during > > initial variable declaration and assignment. The reasoning is that in > > both cases, the "t" isn't giving you any additional information. > > Neither of these exceptions is core to the idea, and either could be > > removed. > > > What do you think? A rough draft of the proposal is sketched out > > here: https://reviews.freebsd.org/D21669 > > > Best, > > Conrad > > > P.S., On an earlier version of this revision, markj@ and emaste@ both > > expressed concern for downstream consumers. There are two aspects of > > the current differential that should smooth that experience. First, a > > backwards-compatible two-argument mtod(m, t) is retained using an ugly > > macro hack. (Existing code compiles without modification.) Second, > > the coccinelle semantic patch will be checked in to the tree somewhere > > for use by downstream consumers that want to convert their code. > > I was surprised not to see responses on the list, but I see that there > was already a fair amount of discussion on the phabricator review up > to the time of this message. I'll reply on the list in hopes of getting > more feedback. > > I like the proposed usage better than the original mtod(); I never liked > the use of a type as a parameter. However, I think it is questionable > whether the cleanup is worth the cost, both for upstream and downstream. > I think the biggest issue is that it makes FreeBSD code harder to use > in other contexts; for example, Michael Tuexen pointed out the issue > of sharing SCTP sources with other BSD-like platforms. We'll end up > with two or more different styles. He asks, given the price to be paid, > what do we gain? On the other hand, mtod() in its old form is ubiquitous > and easy to understand. > Clearly we need m2d() instead. A more modern name for a more modern API. In all seriousness, though, I'm more drawn to the too little gain, too much pain arguments more than the purity arguments. Warner Mike > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >