Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4254839yba; Wed, 17 Apr 2019 07:48:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqx800UKtnC1JiDjP89XrNd0X5BenPQ2W7roAA9wZxioy2fmx2l22VlPTJZ4g/6TorkXvW+p X-Received: by 2002:a65:6489:: with SMTP id e9mr82527982pgv.364.1555512503752; Wed, 17 Apr 2019 07:48:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555512503; cv=none; d=google.com; s=arc-20160816; b=hOyecPnjAGuQBgAPXYf+W6GkQ/CIDdY0dipvqHHyF8wGwLiLLOj13Bf9HpeyX5RrQH ZROM5iYKlYlwIqNMOrrrd4lhj4Y12kg99vcSUJKhsRqACbC7nYENzuWFyn9qw4Lpnqzd TILFnIGgInxf3aRboADqVa8l/98e5xwRxQcqQCrG5owm00LfR3rcpP9GSibjEEQr7xpI TecaUlZMv996m+snlrvjwNmxaBwEtjMKB80oLUWB0u92uVvfQkpTD8H3+EDt1RsmoRML fGJtica8h7QSp0X//EynIXA/MDNZ/HbZTHHqhzNQoeK0Xx3jNCNvNXCNkB8Pm30Amb9S ZB1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Bf4zNrzh2HkCHcZSsf9zz0Z1oL3V3Ad5eDuXP2p14ic=; b=yagng9+eJgTSNk7gL/jRM8EAfLXrvRZRIf44ErxARwZ7sRqzuv8Q2Y3lGhrf8X4AZV 5gJPJQ1YHjBXT7ytmgwoT+VnsIVgGBM8C/H1+NyocR3awTflZLGS/a2Ir03fvjZ9z+Aj 6A/hCnZfuKOy/qIWaBQ4x5tEqy4d1lPBjBQzVCvfRr/c7jXY0SKHn42EN2iMxrOhPdDX klDzH794H0JPgWD223L6P4rMwgp9HTL1a9uU3CJUoCjcU3OhKrnByg6W1lz4QFFPLysQ CJ1rYDP7aZP46br+SEV/o0IXOTquzQl04koFfo+2eM1j3+Bz2VMLsigeS9ecx0zNPQS8 D6kw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=odKzzrxn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f11si49359945pgf.406.2019.04.17.07.48.08; Wed, 17 Apr 2019 07:48:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=odKzzrxn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732626AbfDQOqq (ORCPT + 99 others); Wed, 17 Apr 2019 10:46:46 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:33007 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732570AbfDQOqo (ORCPT ); Wed, 17 Apr 2019 10:46:44 -0400 Received: by mail-ed1-f68.google.com with SMTP id d55so20438332ede.0; Wed, 17 Apr 2019 07:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bf4zNrzh2HkCHcZSsf9zz0Z1oL3V3Ad5eDuXP2p14ic=; b=odKzzrxnQ9EYWq6uD+DQnFOpPcurA3nck/SXHUSMYUJez3Y0KpPhsx2XNKlAaUEJYL WJwIHMBIq7GmzNs6cIHEfQUR4Zx97jNe9f5NgaGEBD0PoeLF4FeHbWyafZOvU/t5wkEv h0O/UosinViUOzAFrA3zPyaQokySQhmDoy5e8tmAWF3/xa17HddL2nD7x6uXIXnnO+J9 PDtWhmHKD0Yo3Og7BZytiFzMHkwkfs6qzjgrHWUM+K8REQOUOejNa2/4SM0MGbKGqKfO sqorVInZJnSv/IEpkZ+xVPOrB6gm0RJPULyS5eoxNAaQs9A81xBcKlVCH7Vc/K2BK4G5 DzRg== 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=Bf4zNrzh2HkCHcZSsf9zz0Z1oL3V3Ad5eDuXP2p14ic=; b=ktheEa3RdqCHYuaiy4pxLqKY5Pkk17kNOSBecv1BZXuf0Ly+ZcyGgsq3We3ttF4zAp QGj6B9YBVd3VymrU64y4RTPHmDu7Pi7j9/dBlvLyoWHm6hOjLdL8ROkJ55xgAKLL03V1 kp2iNHTpb49cgxrnPT8ELiwetW77YJEvB0lVC9F7Mm2R7xnq22zniQdyOVW4kYZ0MNxZ qLHRX/l2i4k2h6Hl725YAKJ3D/+pVwi0aQIW6hJ14Op2ghMU0Up9MO9STL/a1R09kypE 87vGA+7CjQxnR7HZPiSCRvR/dgV08riRDMH8QmABDNeQWzNtmWJrhPWmp9nsWwwQfB0L zRYw== X-Gm-Message-State: APjAAAVVMS+V2KMggzWQgSUfC0sNuo0LQXhuCgNY68FuzBa3fdvJs+M+ OfUHnPndkZks1SJVJHPZnzCgbL9+E7yttwu/R6g= X-Received: by 2002:aa7:d391:: with SMTP id x17mr71392edq.287.1555512400978; Wed, 17 Apr 2019 07:46:40 -0700 (PDT) MIME-Version: 1.0 References: <20190416203620.539628-1-arnd@arndb.de> In-Reply-To: <20190416203620.539628-1-arnd@arndb.de> From: Willem de Bruijn Date: Wed, 17 Apr 2019 10:46:05 -0400 Message-ID: Subject: Re: [PATCH net-next 1/3] net: rework SIOCGSTAMP ioctl handling To: Arnd Bergmann Cc: "David S. Miller" , Ralf Baechle , Marcel Holtmann , Johan Hedberg , Oliver Hartkopp , Marc Kleine-Budde , Gerrit Renker , Alexander Aring , Stefan Schmidt , Alexey Kuznetsov , Hideaki YOSHIFUJI , Vlad Yasevich , Neil Horman , Marcelo Ricardo Leitner , Andrew Hendry , Eric Dumazet , Willem de Bruijn , Deepa Dinamani , Network Development , LKML , linux-hams@vger.kernel.org, linux-bluetooth@vger.kernel.org, linux-can@vger.kernel.org, dccp@vger.kernel.org, linux-wpan@vger.kernel.org, linux-sctp@vger.kernel.org, linux-x25@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 16, 2019 at 4:38 PM Arnd Bergmann wrote: > > The SIOCGSTAMP/SIOCGSTAMPNS ioctl commands are implemented by many > socket protocol handlers, and all of those end up calling the same > sock_get_timestamp()/sock_get_timestampns() helper functions, which > results in a lot of duplicate code. > > With the introduction of 64-bit time_t on 32-bit architectures, this > gets worse, as we then need four different ioctl commands in each > socket protocol implementation. > > To simplify that, let's add a new .gettstamp() operation in > struct proto_ops, and move ioctl implementation into the common > sock_ioctl()/compat_sock_ioctl_trans() functions that these all go > through. > > We can reuse the sock_get_timestamp() implementation, but generalize > it so it can deal with both native and compat mode, as well as > timeval and timespec structures. > > Acked-by: Stefan Schmidt > Link: https://lore.kernel.org/lkml/CAK8P3a038aDQQotzua_QtKGhq8O9n+rdiz2=WDCp82ys8eUT+A@mail.gmail.com/ > Signed-off-by: Arnd Bergmann > --- > v2: reworked to not break sparc64 support From the discussion of v1 I thought you planned to unconditionally call sock_gettstamp() for all protocols, avoiding the need to plumb in all these new callbacks? That is more concise, though this closer to the existing behavior. So, fine either way.