From owner-freebsd-arch@freebsd.org Sun Nov 29 12:51:18 2020 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 8E2794A12FC; Sun, 29 Nov 2020 12:51:18 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CkSsf3VgZz4ZGW; Sun, 29 Nov 2020 12:51:18 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 429D0231C6; Sun, 29 Nov 2020 12:51:18 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id CB2F58D4A166; Sun, 29 Nov 2020 12:51:16 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 22AE9E707C7; Sun, 29 Nov 2020 12:51:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id zA18_IwF1If9; Sun, 29 Nov 2020 12:51:13 +0000 (UTC) Received: from [127.0.0.1] (unknown [IPv6:fde9:577b:c1a9:4902:20d4:cd87:918b:4dde]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 841D2E707C2; Sun, 29 Nov 2020 12:51:13 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Kyle Evans" , "James Gritton" Cc: freebsd-jail , freebsd-arch@freebsd.org, trustedbsd-discuss@freebsd.org Subject: Re: RFC: Jail privsets Date: Sun, 29 Nov 2020 12:51:12 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: In-Reply-To: References: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> <6BA03DAD-BDCD-4A53-A80A-4B7B476B803C@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2020 12:51:18 -0000 On 28 Nov 2020, at 14:39, Kyle Evans wrote: Hi, Cc: jamie explicitly as he might have thoughts as well. > Yeah, so jail sets are a little tricky, and to be honest I haven't > really thought about how to cope with common jail sets. The > complication arises because you have various allow flags that > typically default to off and turn privileges on, but your common sets > would have to include them. So, you'd probably end up with: > > privset 0: All privs available to the superuser (not considering > superuser policy just yet) > privset 1: All privs available to jails (assuming most permissive, all > allow flags on and assuming a new vnet on VIMAGE systems) > > So jails would typically inherit privset 1, but they'd have to mask > out based on vnet/allow flags out of necessity. Now, that's not > terrible, but I think we'd have to do a couple more things to reduce > maintenance burden on folks introducing privs: > > 1.) Clearly define a central table that maps pr_flags <-> privs where > there's a 1:1 mapping (most common, though PRIV_VFS_*MOUNT* are a > little more complicated) > 2.) Walk said table when we're defining privs in privset 1 > 3.) Walk said table when we're determining what to mask out > > I suspect the vnet set is large enough that we'd just have a separate > kernel-internal mask for "vnet privs". In any event, for most people, > there will be one of three places that you might touch when adding a > new priv flag or pr_flag mapping to a priv, but it should still be > obvious what you want: either you want a conditionally added flag, you > want to influence the default jail policy, or you want to change the > vnet policy. The latter two scenarios might even be a little easier, > because you don't need to wade through these gigantic switch > statements with a lot of cases to determine where you really want it > to go. I think this is all terribly too complicated. If we’ll have manageable fine-grained priv system, them retire allow and vnet checks for PRIV_* checks and be done with it. If we need new PRIV_* checks to accomplish that adding PRIV_* is semi-cheap to add. The big switch statements in kern_jail.c will go as the applied priv set will do the right thing already, which means at this point we’d have a base-system-privset, a classic-jail-privset, a vnet-jail-privset by default probably. If we want to keep allow* in jails we can probably make them compat code to adjust PRIV_* but I am not sure I’d want jail to still do that or a separate priv command (a la cpuset). Means jails become simple again and a lot of the complicate logic can drop out. >> And yes, that would indeed simplify our jail and network stack (and some >> other) >> code quite a bit. >> >> I’d love this (step-by-step or in whole right away) :-) >> > > :-) > > I'm looking to see if I can define a useful abstraction from > cpuset/domainset that would limit the amount of duplication needed for > this, then I'll post a v2 to Phabricator. There’s probably edge cases in which managing privsets will be a priv as well and we’ll probably need multiple cases: one that can still “widen” priv and one that can only copy-and-further-restrict-only. The latter probably being the default. /bz From owner-freebsd-arch@freebsd.org Sun Nov 29 15:34:00 2020 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 3AEEF4A5693; Sun, 29 Nov 2020 15:34:00 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CkXTN15Zbz4m7r; Sun, 29 Nov 2020 15:34:00 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 137BD24563; Sun, 29 Nov 2020 15:34:00 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f181.google.com with SMTP id k4so1821686qtj.10; Sun, 29 Nov 2020 07:34:00 -0800 (PST) X-Gm-Message-State: AOAM5332+zxGyKIYu64w8dxgq8bW6bN+ggzbZb+00g6HGEND69Gwxzqk dqw0FTdFCN4kWGFM0dv31OMZ3HFf3yZKpysi3Gs= X-Google-Smtp-Source: ABdhPJwt4wWA6TB+MdFxhKXGba9zwtDkH4LTSlpJZrGx6P8qjaDA4J65koWLHyQ1WBjROcwNHz3IwSCtkfDXUFAjezw= X-Received: by 2002:ac8:5345:: with SMTP id d5mr17864902qto.60.1606664039506; Sun, 29 Nov 2020 07:33:59 -0800 (PST) MIME-Version: 1.0 References: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> <6BA03DAD-BDCD-4A53-A80A-4B7B476B803C@FreeBSD.org> In-Reply-To: From: Kyle Evans Date: Sun, 29 Nov 2020 09:33:48 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: Jail privsets To: "Bjoern A. Zeeb" Cc: James Gritton , freebsd-jail , "freebsd-arch@freebsd.org" , trustedbsd-discuss@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2020 15:34:00 -0000 On Sun, Nov 29, 2020 at 6:51 AM Bjoern A. Zeeb wrote: > > On 28 Nov 2020, at 14:39, Kyle Evans wrote: > > Hi, > > Cc: jamie explicitly as he might have thoughts as well. > > > Yeah, so jail sets are a little tricky, and to be honest I haven't > > really thought about how to cope with common jail sets. The > > complication arises because you have various allow flags that > > typically default to off and turn privileges on, but your common sets > > would have to include them. So, you'd probably end up with: > > > > privset 0: All privs available to the superuser (not considering > > superuser policy just yet) > > privset 1: All privs available to jails (assuming most permissive, all > > allow flags on and assuming a new vnet on VIMAGE systems) > > > > So jails would typically inherit privset 1, but they'd have to mask > > out based on vnet/allow flags out of necessity. Now, that's not > > terrible, but I think we'd have to do a couple more things to reduce > > maintenance burden on folks introducing privs: > > > > 1.) Clearly define a central table that maps pr_flags <-> privs where > > there's a 1:1 mapping (most common, though PRIV_VFS_*MOUNT* are a > > little more complicated) > > 2.) Walk said table when we're defining privs in privset 1 > > 3.) Walk said table when we're determining what to mask out > > > > I suspect the vnet set is large enough that we'd just have a separate > > kernel-internal mask for "vnet privs". In any event, for most people, > > there will be one of three places that you might touch when adding a > > new priv flag or pr_flag mapping to a priv, but it should still be > > obvious what you want: either you want a conditionally added flag, you > > want to influence the default jail policy, or you want to change the > > vnet policy. The latter two scenarios might even be a little easier, > > because you don't need to wade through these gigantic switch > > statements with a lot of cases to determine where you really want it > > to go. > > I think this is all terribly too complicated. > > If we=E2=80=99ll have manageable fine-grained priv system, them retire al= low and > vnet checks for PRIV_* checks and be done with it. If we need new PRIV_* > checks to accomplish that adding PRIV_* is semi-cheap to add. > > The big switch statements in kern_jail.c will go as the applied priv set > will do the right thing already, which means at this point we=E2=80=99d h= ave > a base-system-privset, a classic-jail-privset, a vnet-jail-privset by > default probably. > > If we want to keep allow* in jails we can probably make them compat code > to adjust PRIV_* but I am not sure I=E2=80=99d want jail to still do that= or a > separate priv command (a la cpuset). > > Means jails become simple again and a lot of the complicate logic can > drop out. > Sure- I'm not so sure about vnet, but all of the allow flags could get deprecated in favor of describing the privs available somewhere and letting admin make decisions. I think the vnet set still makes a lot of sense unless you're also proposing that we could just create new vnets if one of those privileges is turned on -- in which case, we'd still have to manage the set, but it wouldn't be used much beyond a hint mask that we need to create a vnet. > >> And yes, that would indeed simplify our jail and network stack (and so= me > >> other) > >> code quite a bit. > >> > >> I=E2=80=99d love this (step-by-step or in whole right away) :-) > >> > > > > :-) > > > > I'm looking to see if I can define a useful abstraction from > > cpuset/domainset that would limit the amount of duplication needed for > > this, then I'll post a v2 to Phabricator. > > There=E2=80=99s probably edge cases in which managing privsets will be a = priv as > well and we=E2=80=99ll probably need multiple cases: one that can still = =E2=80=9Cwiden=E2=80=9D > priv and one that can only copy-and-further-restrict-only. The latter > probably being the default. > True enough. From owner-freebsd-arch@freebsd.org Sun Nov 29 15:41:39 2020 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 ECDC24A5CB1; Sun, 29 Nov 2020 15:41:39 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CkXfC6Dt5z4mf6; Sun, 29 Nov 2020 15:41:39 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id AEF7124177; Sun, 29 Nov 2020 15:41:39 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id A61058D4A166; Sun, 29 Nov 2020 15:41:38 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 273DEE707C7; Sun, 29 Nov 2020 15:41:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id mvFUICsQe4UG; Sun, 29 Nov 2020 15:41:37 +0000 (UTC) Received: from [127.0.0.1] (unknown [IPv6:fde9:577b:c1a9:4902:20d4:cd87:918b:4dde]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id B69CCE707C2; Sun, 29 Nov 2020 15:41:36 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Kyle Evans" Cc: "James Gritton" , freebsd-jail , freebsd-arch@freebsd.org, trustedbsd-discuss@freebsd.org Subject: Re: RFC: Jail privsets Date: Sun, 29 Nov 2020 15:41:36 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: In-Reply-To: References: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> <6BA03DAD-BDCD-4A53-A80A-4B7B476B803C@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2020 15:41:40 -0000 On 29 Nov 2020, at 15:33, Kyle Evans wrote: > Sure- I'm not so sure about vnet, but all of the allow flags could get > deprecated in favor of describing the privs available somewhere and > letting admin make decisions. I think the vnet set still makes a lot > of sense unless you're also proposing that we could just create new > vnets if one of those privileges is turned on -- in which case, we'd > still have to manage the set, but it wouldn't be used much beyond a > hint mask that we need to create a vnet. What I am thinking of is a /etc/defaults/devfs.rules a-like set of privs describing base, jail, jailvnet and then pick appropriately if the jail gets created with vnet (though I can imagine some people extending a default jail set — e.g. for raw sockets — or removing some privs from a vnet jail set). The tricky bit would be to manage the header file and the text description, but having a default wildcard of “*” or “all” for base would probably catch the most cases. /bz From owner-freebsd-arch@freebsd.org Sun Nov 29 20:09:23 2020 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 C6AF54ABCBA; Sun, 29 Nov 2020 20:09:23 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [199.192.165.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ckfb74nkjz3MJs; Sun, 29 Nov 2020 20:09:23 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org ([127.0.0.131]) (authenticated bits=0) by gritton.org (8.15.2/8.15.2) with ESMTPA id 0ATK9Ggf019835; Sun, 29 Nov 2020 12:09:16 -0800 (PST) (envelope-from jamie@freebsd.org) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sun, 29 Nov 2020 12:09:16 -0800 From: James Gritton To: "Bjoern A. Zeeb" Cc: Kyle Evans , freebsd-jail , freebsd-arch@freebsd.org, trustedbsd-discuss@freebsd.org Subject: Re: RFC: Jail privsets In-Reply-To: References: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> <6BA03DAD-BDCD-4A53-A80A-4B7B476B803C@FreeBSD.org> User-Agent: Roundcube Webmail/1.4.1 Message-ID: <782331951af5589aac5d6225a274cc60@freebsd.org> X-Sender: jamie@freebsd.org X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (gritton.org [127.0.0.131]); Sun, 29 Nov 2020 13:09:16 -0700 (MST) X-Rspamd-Queue-Id: 4Ckfb74nkjz3MJs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2020 20:09:23 -0000 On 2020-11-29 04:51, Bjoern A. Zeeb wrote: > On 28 Nov 2020, at 14:39, Kyle Evans wrote: > > Hi, > > Cc: jamie explicitly as he might have thoughts as well. Heh - I've been following along, and my thought have mostly consisted of "well this is interesting and complicated." :-) >> Yeah, so jail sets are a little tricky, and to be honest I haven't >> really thought about how to cope with common jail sets. The >> complication arises because you have various allow flags that >> typically default to off and turn privileges on, but your common sets >> would have to include them. So, you'd probably end up with: >> >> privset 0: All privs available to the superuser (not considering >> superuser policy just yet) >> privset 1: All privs available to jails (assuming most permissive, all >> allow flags on and assuming a new vnet on VIMAGE systems) >> >> So jails would typically inherit privset 1, but they'd have to mask >> out based on vnet/allow flags out of necessity. Now, that's not >> terrible, but I think we'd have to do a couple more things to reduce >> maintenance burden on folks introducing privs: >> >> 1.) Clearly define a central table that maps pr_flags <-> privs where >> there's a 1:1 mapping (most common, though PRIV_VFS_*MOUNT* are a >> little more complicated) >> 2.) Walk said table when we're defining privs in privset 1 >> 3.) Walk said table when we're determining what to mask out >> >> I suspect the vnet set is large enough that we'd just have a separate >> kernel-internal mask for "vnet privs". In any event, for most people, >> there will be one of three places that you might touch when adding a >> new priv flag or pr_flag mapping to a priv, but it should still be >> obvious what you want: either you want a conditionally added flag, you >> want to influence the default jail policy, or you want to change the >> vnet policy. The latter two scenarios might even be a little easier, >> because you don't need to wade through these gigantic switch >> statements with a lot of cases to determine where you really want it >> to go. > > I think this is all terribly too complicated. > > If we’ll have manageable fine-grained priv system, them retire allow > and > vnet checks for PRIV_* checks and be done with it. If we need new > PRIV_* > checks to accomplish that adding PRIV_* is semi-cheap to add. > > The big switch statements in kern_jail.c will go as the applied priv > set > will do the right thing already, which means at this point we’d have > a base-system-privset, a classic-jail-privset, a vnet-jail-privset by > default probably. > > If we want to keep allow* in jails we can probably make them compat > code > to adjust PRIV_* but I am not sure I’d want jail to still do that or a > separate priv command (a la cpuset). > > Means jails become simple again and a lot of the complicate logic can > drop out. I'm not against deprecating the allow.* hooks, but I suspect they'll end up sticking around a long time (forever) in deprecated form. I've considered removing the old global security.jail.whatever_allowed sysctls that cause more confusion than anything else, and kind of had to give it up against a wall of concern that somebody out there still used it. I'll admit that the proliferation of allow.mount.foofs is kind of abomination, but that's kind of how things grew up, and there isn't a good fit with the current priv system. It could well be that all of those are unnecessary and we either trust jails to mount all of the filesystems of none of the filesystems. However it works out, I agree that a single view of privilege management makes more sense than multiple ways of saying the same thing. So I (without having studied it much) tend to agree with the idea of reducing the jail/priv shim layer as much as possible. I'm just not sure how possible it will be. - Jamie From owner-freebsd-arch@freebsd.org Thu Dec 3 00:12:49 2020 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 AF332472A26; Thu, 3 Dec 2020 00:12:49 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cmbrc693Tz4VBq; Thu, 3 Dec 2020 00:12:48 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id D84103C0199; Thu, 3 Dec 2020 00:12:47 +0000 (UTC) Date: Thu, 3 Dec 2020 00:12:47 +0000 From: Brooks Davis To: freebsd-arch@freebsd.org Cc: freebsd-net@freebsd.org Subject: RFC: removing ndis(4) Message-ID: <20201203001247.GF18452@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ryJZkp9/svQ58syV" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4Cmbrc693Tz4VBq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[199.48.129.229:from]; FREEFALL_USER(0.00)[brooks]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[199.48.129.229:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; MAILMAN_DEST(0.00)[freebsd-arch,freebsd-net] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 00:12:49 -0000 --ryJZkp9/svQ58syV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'd like to propose that we remove the ndis(4) driver prior to FreeBSD 13. It was a clever idea in the early 2000's when the market was flooded with 10/100 NICs with Windows-only drivers, but that hasn't been the case for ages and the driver has had no meaningful maintenance in ages[0]. I'd be a bit surprised if it worked at all today (it surely won't work with modern Windows drivers). To try to examine the popularity of ndis, I checked dmesgd.nycbug.org and there are 5 total entries with the most recent being 2007. The PC Card attachments are currently marked for deletion prior to FreeBSD 13. Unless there is surprising outcry I plan to add (and MFC) deprecation notices in about a week's time and remove the driver shortly thereafter. -- Brooks [0] I noticed today that part of the ndis 802.11 ioctl handler has been broken since 2005. --ryJZkp9/svQ58syV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJfyC1/AAoJEKzQXbSebgfA8xIIAJcvSo+YmK7qOgEr0gUWsdh1 tTf650lYb6EPgtTK/vcfYdsMfk2f/qRZh6EDN/Ydx2g9tLws1BCMoJa6Ak7riPmt 8Ycb4h8+0LUZFy8LX1OiAoevY1R0OJOnDZS699X2VKSVrlylwkoSCXeXdNHfnqew za7fq7lhI+B8I5EEpP+jRIDheH/DBoeieMy7/mff/LdGxoK4kiMMF1F9ia1KeQ3j 4d/mcVi7IzJcq0kl2qHA8+ac0vS0iDFOmVmj7gaJpjUzkyPa6gvGNUC4cQqwfMaW W7vgkL6blDOVk49BycfbEuA75IIEumCh/jirWqdf26XWEdkCIA4TDaNvFgv84IQ= =K8jL -----END PGP SIGNATURE----- --ryJZkp9/svQ58syV-- From owner-freebsd-arch@freebsd.org Thu Dec 3 00:37:50 2020 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 EC6AD4731CD for ; Thu, 3 Dec 2020 00:37:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4CmcPV0Xqsz4WfJ for ; Thu, 3 Dec 2020 00:37:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x735.google.com with SMTP id u4so612698qkk.10 for ; Wed, 02 Dec 2020 16:37:49 -0800 (PST) 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=5cUbxfjOaVDRnnheU82JgHn4cfwIczcwvwQwruT9Ch8=; b=bfA1v6Rc0CiEUHBeYRNLaJbb+EDgdY7UkFiQtrap4oBgfk/4X6TczjmbwbdRHizLmh 7BVmZBYStOOFIRYaO1Rvkd+LZtdxgGxtE4eSPRfRjoh8w1EE2pExEcRXAK+V1zar29vI YG3yR9ILjVq7CsJDoZoyRcWqFAum8F8l85qr2/waLx0x7X22uDvnHh5c43En2voiw8SO T6A9+ksV3xdN0liXECizNJVOsuDryxgI8ChxT0Jo/DzL6sSSNk2l5zGQGhqbT9DYPBLa xqOtQGIyY4uthNoQM7YnfecvCCaz6A8hIVbAbDa6ZoonsOgxWP0EmXqvZ1xHhUMBjlV6 zWAA== 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=5cUbxfjOaVDRnnheU82JgHn4cfwIczcwvwQwruT9Ch8=; b=qoImfRYUmv0e3QS8l91SJKURlvalSdc1Lej1sJvlaGRDdvpU3zo9RMalKQ6FSiPYrj nJwuSCHYG4ccIcY+eFqPZry4F2e0tbHOudnIIPzYErdbJMHslQUyO4+LskUJ9MDw7KPo OCk/xBRi9Cb9/ori5VMLS7uqxjj9Ow3D5o84TqsSriu40VhPGaM4X09VA2sS5AJ7Pfzt oMCKRz9Fa6WhWFcrZmlCoQuGZeLJCJzVZttPEdMjr1JyUs33/rdlwJonMtgRDNYcbYYP vtOnkh4HSm42xYV9vjhKi+l3CM42Y6e1LaJ7kwOte1TMluUmjn8+jauhaJ/2q/c29XUr RaPQ== X-Gm-Message-State: AOAM531SAWIDGZ6VJIAu6cFIgRlhC6RSNHdswkXX7fzqTstZBgi7H+wq AbsoyOiMX6qNu4PH2RR4LnDa8r7M4KdPdZSZVOAPOA== X-Google-Smtp-Source: ABdhPJyMQfv5TWktWVPZegYYOkBsJIjUWmkCrhLFCio+KPpBGhERuvpp2aFOjylFegXSnSycOlw4Nm1NspdUtxOTCds= X-Received: by 2002:a37:9b01:: with SMTP id d1mr500747qke.89.1606955869014; Wed, 02 Dec 2020 16:37:49 -0800 (PST) MIME-Version: 1.0 References: <20201203001247.GF18452@spindle.one-eyed-alien.net> In-Reply-To: <20201203001247.GF18452@spindle.one-eyed-alien.net> From: Warner Losh Date: Wed, 2 Dec 2020 17:37:38 -0700 Message-ID: Subject: Re: RFC: removing ndis(4) To: Brooks Davis Cc: "freebsd-arch@freebsd.org" , FreeBSD Net X-Rspamd-Queue-Id: 4CmcPV0Xqsz4WfJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=bfA1v6Rc; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::735) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.99 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::735:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.99)[-0.985]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::735:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::735:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 00:37:51 -0000 On Wed, Dec 2, 2020 at 5:13 PM Brooks Davis wrote: > I'd like to propose that we remove the ndis(4) driver prior to FreeBSD > 13. It was a clever idea in the early 2000's when the market was > flooded with 10/100 NICs with Windows-only drivers, but that hasn't been > the case for ages and the driver has had no meaningful maintenance in > ages[0]. I'd be a bit surprised if it worked at all today (it surely > won't work with modern Windows drivers). > > To try to examine the popularity of ndis, I checked dmesgd.nycbug.org > and there are 5 total entries with the most recent being 2007. > > The PC Card attachments are currently marked for deletion prior to > FreeBSD 13. > > Unless there is surprising outcry I plan to add (and MFC) deprecation > notices in about a week's time and remove the driver shortly thereafter. > > -- Brooks > > [0] I noticed today that part of the ndis 802.11 ioctl handler has been > broken since 2005. > Like PC Card, it's time to bid this old friend farewell... Warner From owner-freebsd-arch@freebsd.org Thu Dec 3 03:28:54 2020 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 F1E4B477CED for ; Thu, 3 Dec 2020 03:28:54 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp.infotel.ru (corp.infotel.ru [195.170.219.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4CmhBs6MzLz4jGZ for ; Thu, 3 Dec 2020 03:28:53 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp (corp.infotel.ru [195.170.219.3]) by corp.infotel.ru (Postfix) with ESMTP id 4178316472A for ; Thu, 3 Dec 2020 06:28:45 +0300 (MSK) X-Virus-Scanned: amavisd-new at corp.infotel.ru Received: from corp.infotel.ru ([195.170.219.3]) by corp (corp.infotel.ru [195.170.219.3]) (amavisd-new, port 10024) with ESMTP id UeGiQ-VMXkZz for ; Thu, 3 Dec 2020 06:28:35 +0300 (MSK) Received: from mail.cicgroup.ru (unknown [195.170.219.74]) by corp.infotel.ru (Postfix) with ESMTP id 1972816471D for ; Thu, 3 Dec 2020 06:28:35 +0300 (MSK) Received: from mail.cicgroup.ru (localhost [127.0.0.1]) by mail.cicgroup.ru (Postfix) with ESMTP id 125CA42211F for ; Thu, 3 Dec 2020 06:24:47 +0300 (MSK) X-Virus-Scanned: amavisd-new at cicgroup.ru Received: from mail.cicgroup.ru ([127.0.0.1]) by mail.cicgroup.ru (mail.cicgroup.ru [127.0.0.1]) (amavisd-new, port 10024) with SMTP id olW9NzpKalpM for ; Thu, 3 Dec 2020 06:24:39 +0300 (MSK) Received: from [192.168.0.30] (gateway [10.0.2.2]) by mail.cicgroup.ru (Postfix) with ESMTPA id E35F142211C for ; Thu, 3 Dec 2020 06:24:39 +0300 (MSK) Subject: Re: RFC: removing ndis(4) To: freebsd-arch@freebsd.org References: <20201203001247.GF18452@spindle.one-eyed-alien.net> From: Vladimir Kondratyev Message-ID: <178622db-7dcd-fcae-743c-883711121733@kondratyev.su> Date: Thu, 3 Dec 2020 06:28:00 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201203001247.GF18452@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4CmhBs6MzLz4jGZ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of vladimir@kondratyev.su has no SPF policy when checking 195.170.219.3) smtp.mailfrom=vladimir@kondratyev.su X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[195.170.219.3:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[195.170.219.3:from:127.0.2.255]; DMARC_NA(0.00)[kondratyev.su]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8299, ipnet:195.170.192.0/19, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 03:28:55 -0000 On 03.12.2020 03:12, Brooks Davis wrote: > I'd like to propose that we remove the ndis(4) driver prior to FreeBSD > 13. It was a clever idea in the early 2000's when the market was > flooded with 10/100 NICs with Windows-only drivers, but that hasn't been > the case for ages and the driver has had no meaningful maintenance in > ages[0]. I'd be a bit surprised if it worked at all today (it surely > won't work with modern Windows drivers). > > To try to examine the popularity of ndis, I checked dmesgd.nycbug.org > and there are 5 total entries with the most recent being 2007. > > The PC Card attachments are currently marked for deletion prior to > FreeBSD 13. > > Unless there is surprising outcry I plan to add (and MFC) deprecation > notices in about a week's time and remove the driver shortly thereafter. > > -- Brooks > > [0] I noticed today that part of the ndis 802.11 ioctl handler has been > broken since 2005. ndis(4) was functional at least in 2015 and at that time it was the only way to utilize BCM's wi-fi built in my "Asus EEEPC" From owner-freebsd-arch@freebsd.org Thu Dec 3 03:44:23 2020 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 A640D477FCA for ; Thu, 3 Dec 2020 03:44:23 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp.infotel.ru (corp.infotel.ru [195.170.219.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4CmhXk5dKMz4jgs for ; Thu, 3 Dec 2020 03:44:22 +0000 (UTC) (envelope-from vladimir@kondratyev.su) Received: from corp (corp.infotel.ru [195.170.219.3]) by corp.infotel.ru (Postfix) with ESMTP id 928B8164832; Thu, 3 Dec 2020 06:44:21 +0300 (MSK) X-Virus-Scanned: amavisd-new at corp.infotel.ru Received: from corp.infotel.ru ([195.170.219.3]) by corp (corp.infotel.ru [195.170.219.3]) (amavisd-new, port 10024) with ESMTP id ieQaGVcaoBwA; Thu, 3 Dec 2020 06:44:12 +0300 (MSK) Received: from mail.cicgroup.ru (unknown [195.170.219.74]) by corp.infotel.ru (Postfix) with ESMTP id 0C71D164825; Thu, 3 Dec 2020 06:44:12 +0300 (MSK) Received: from mail.cicgroup.ru (localhost [127.0.0.1]) by mail.cicgroup.ru (Postfix) with ESMTP id 052BD42211F; Thu, 3 Dec 2020 06:40:24 +0300 (MSK) X-Virus-Scanned: amavisd-new at cicgroup.ru Received: from mail.cicgroup.ru ([127.0.0.1]) by mail.cicgroup.ru (mail.cicgroup.ru [127.0.0.1]) (amavisd-new, port 10024) with SMTP id UxUfm_4mfr-k; Thu, 3 Dec 2020 06:40:17 +0300 (MSK) Received: from [192.168.0.30] (gateway [10.0.2.2]) by mail.cicgroup.ru (Postfix) with ESMTPA id 1B53942211C; Thu, 3 Dec 2020 06:40:17 +0300 (MSK) Subject: Re: RFC: removing ndis(4) To: Adrian Chadd Cc: "freebsd-arch@freebsd.org" References: <20201203001247.GF18452@spindle.one-eyed-alien.net> <178622db-7dcd-fcae-743c-883711121733@kondratyev.su> From: Vladimir Kondratyev Message-ID: <8c1d4dbd-5265-78d4-7d79-9d64f08f7aa4@kondratyev.su> Date: Thu, 3 Dec 2020 06:43:37 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4CmhXk5dKMz4jgs X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of vladimir@kondratyev.su has no SPF policy when checking 195.170.219.3) smtp.mailfrom=vladimir@kondratyev.su X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[195.170.219.3:from]; ASN(0.00)[asn:8299, ipnet:195.170.192.0/19, country:RU]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_FIVE(0.00)[6]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; AUTH_NA(1.00)[]; DMARC_NA(0.00)[kondratyev.su]; SPAMHAUS_ZRD(0.00)[195.170.219.3:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 03:44:23 -0000 On 03.12.2020 06:32, Adrian Chadd wrote: > On Wed, 2 Dec 2020 at 19:28, Vladimir Kondratyev wrote: >> >> On 03.12.2020 03:12, Brooks Davis wrote: >>> I'd like to propose that we remove the ndis(4) driver prior to FreeBSD >>> 13. It was a clever idea in the early 2000's when the market was >>> flooded with 10/100 NICs with Windows-only drivers, but that hasn't been >>> the case for ages and the driver has had no meaningful maintenance in >>> ages[0]. I'd be a bit surprised if it worked at all today (it surely >>> won't work with modern Windows drivers). >>> >>> To try to examine the popularity of ndis, I checked dmesgd.nycbug.org >>> and there are 5 total entries with the most recent being 2007. >>> >>> The PC Card attachments are currently marked for deletion prior to >>> FreeBSD 13. >>> >>> Unless there is surprising outcry I plan to add (and MFC) deprecation >>> notices in about a week's time and remove the driver shortly thereafter. >>> >>> -- Brooks >>> >>> [0] I noticed today that part of the ndis 802.11 ioctl handler has been >>> broken since 2005. >> >> ndis(4) was functional at least in 2015 and at that time it was the only >> way to utilize BCM's wi-fi built in my "Asus EEEPC" > > Everything has moved onto new NDIS APIs that we don't support. > BCM4313 devices still have a Win-XP driver. No one tried to delete it all-over-the-internet. From owner-freebsd-arch@freebsd.org Thu Dec 3 05:24:00 2020 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 0A73947A8CD for ; Thu, 3 Dec 2020 05:24:00 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cmklg1Ypsz4ns0 for ; Thu, 3 Dec 2020 05:23:58 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.229.168]) by shaw.ca with ESMTPA id kh5wkWa45tdldkh5xkgf84; Wed, 02 Dec 2020 22:23:57 -0700 X-Authority-Analysis: v=2.4 cv=INe8tijG c=1 sm=1 tr=0 ts=5fc8766d a=7AlCcx2GqMg+lh9P3BclKA==:117 a=7AlCcx2GqMg+lh9P3BclKA==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=zTNgK-yGK50A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=neO_dujWEq-zw7rLH8MA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 10EF8580 for ; Wed, 2 Dec 2020 21:23:55 -0800 (PST) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 0B35NsG7003810 for ; Wed, 2 Dec 2020 21:23:54 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202012030523.0B35NsG7003810@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: freebsd-arch@freebsd.org Subject: struct timex and Linux adjtimex() Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Dec 2020 21:23:54 -0800 X-CMAE-Envelope: MS4xfAen6ZgCc73rd7Wabak7R6A1Kl/1KwkQ5bJXkMjKFBnedcFvAr4zhPcgqI0rXuXoFwvtvF3Su7J29QKsyauRTmZpTsUr8dYndANQttEsqYjoU3zkp3H0 HdofT3fmaoZ//7P4GS2DuME7e4gVqxy877e0Va6qGo65GNzCkKjPWq1Weo/wcOcNvy4b9IhLqt1f1qXps+bCWz4RMP+cXCyV4fw= X-Rspamd-Queue-Id: 4Cmklg1Ypsz4ns0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.134.9) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [0.30 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.59.134.9:from]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RECEIVED_SPAMHAUS_PBL(0.00)[70.67.229.168:received]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[64.59.134.9:from]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[64.59.134.9:from:127.0.2.255]; RCVD_IN_DNSWL_LOW(-0.10)[64.59.134.9:from]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; R_SPF_NA(0.00)[no SPF record]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 05:24:00 -0000 An NTP developer at approached me about the prospect of a system call to add or subtract time from the system clock, returning the current time after the update. The two options were: 1. A new syscall, similar to clock_settime() and clock_gettime() that adds/subtracts the delta, in a struct timespec, via a call to kern_clock_settime(). Then atomically returns the current time as if clock_gettime() was immediately called. 2. His colleague didn't think this was appropriate for their needs. He wants a FreeBSD implementation of the Linux adjtimex() syscall. Though non-standard option 1 is least intrusive on existing applications. Option 2, implement the Linux adjtimex(): 1. The Linux adjtimex() appears to be a re-implementation of ntp_adjtime() with the addition of ADJ_SETOFFSET. 2. ADJ_SETOFFSET adds or subtracts the time specified in a struct timeval within the timex struct. Unfortunately the FreeBSD timex struct contains no timeval. To implement this would require versioned symbols to maintain backward compatiblity. Up for discussion is: 1. Are we, FreeBSD, interested in implementing the Linux adjtimex() syscall? (I would take on the task to author it should we feel this is a worthwhile project. OTOH I prefer not to spend the time working on this if the community feels otherwise.) 2. From a cursory scan through the tree it appears that ntp is the only internal consumer of struct timex. There are probably others in ports and other third party software such as openntpd and chrony. A versioned symbol should satisfy old applications which might use the previous timex struct. Are we interested in the Linux adjtimex(2) for FreeBSD? -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Thu Dec 3 07:59:05 2020 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 44CBB47DBB5 for ; Thu, 3 Dec 2020 07:59:05 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CmpBb6jv7z3Cfg for ; Thu, 3 Dec 2020 07:59:03 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id E9C538A577; Thu, 3 Dec 2020 07:58:55 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 0B37wtSE004088 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Dec 2020 07:58:55 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 0B37wte7004087; Thu, 3 Dec 2020 07:58:55 GMT (envelope-from phk) To: Cy Schubert cc: freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() In-reply-to: <202012030523.0B35NsG7003810@slippy.cwsent.com> From: "Poul-Henning Kamp" References: <202012030523.0B35NsG7003810@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4085.1606982335.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Thu, 03 Dec 2020 07:58:55 +0000 Message-ID: <4086.1606982335@critter.freebsd.dk> X-Rspamd-Queue-Id: 4CmpBb6jv7z3Cfg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[130.225.244.222:from]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[130.225.244.222:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 07:59:05 -0000 -------- Cy Schubert writes: > 1. A new syscall, similar to clock_settime() and clock_gettime() that = > adds/subtracts the delta, in a struct timespec, via a call to = > kern_clock_settime(). Then atomically returns the current time as if = > clock_gettime() was immediately called. Did they say why they need this and why simply setting the clock is not good enough ? What program uses this ? > Option 2, implement the Linux adjtimex(): > > 1. The Linux adjtimex() appears to be a re-implementation of ntp_adjtime= () = > with the addition of ADJ_SETOFFSET. ntp_adjtime(2), modulus argument transformations, does what linux adjtimex= (2) does. adjtimex() is actually Dave Mills temporarry name, pending Suns integratio= n into their kernel. Sun messed up and used that name, instead of the name he had proposed. I renamed it in FreeBSD many years ago to his preferred name. > 2. ADJ_SETOFFSET adds or subtracts the time specified in a struct timeva= l = > within the timex struct. Unfortunately the FreeBSD timex struct contains= no = > timeval. To implement this would require versioned symbols to maintain = > backward compatiblity. If we do this, it should respect the MOD_NANO protocol ot use either timeval or timespec. > 1. Are we, FreeBSD, interested in implementing the Linux adjtimex() = > syscall? (I would take on the task to author it should we feel this is a= = > worthwhile project. OTOH I prefer not to spend the time working on this = if = > the community feels otherwise.) Unless given very compelling reasons: No. Adding ADJ_SETOFFSET to ntp_adjtime(2): possibly. > 2. From a cursory scan through the tree it appears that ntp is the only = > internal consumer of struct timex. There are probably others in ports an= d = > other third party software such as openntpd and chrony. A versioned symb= ol = > should satisfy old applications which might use the previous timex struc= t. ntp_adjtime()/adjtimex() is the only way to wrangle the clock gently, and there are site-specific software which uses it for that, it is a published and used API/ABI. > Are we interested in the Linux adjtimex(2) for FreeBSD? -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Thu Dec 3 10:05:31 2020 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 909884A19C9 for ; Thu, 3 Dec 2020 10:05:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cms0V531rz3LQL for ; Thu, 3 Dec 2020 10:05:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0B3A546P032054 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Dec 2020 12:05:07 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0B3A546P032054 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0B3A54SZ032053; Thu, 3 Dec 2020 12:05:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Dec 2020 12:05:04 +0200 From: Konstantin Belousov To: Cy Schubert Cc: freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() Message-ID: References: <202012030523.0B35NsG7003810@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202012030523.0B35NsG7003810@slippy.cwsent.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4Cms0V531rz3LQL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; R_SPF_SOFTFAIL(0.00)[~all]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arch]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 10:05:31 -0000 On Wed, Dec 02, 2020 at 09:23:54PM -0800, Cy Schubert wrote: > An NTP developer at approached me about the prospect of a system call to > add or subtract time from the system clock, returning the current time > after the update. The two options were: > > 1. A new syscall, similar to clock_settime() and clock_gettime() that > adds/subtracts the delta, in a struct timespec, via a call to > kern_clock_settime(). Then atomically returns the current time as if > clock_gettime() was immediately called. > > 2. His colleague didn't think this was appropriate for their needs. He > wants a FreeBSD implementation of the Linux adjtimex() syscall. > > Though non-standard option 1 is least intrusive on existing applications. > > Option 2, implement the Linux adjtimex(): > > 1. The Linux adjtimex() appears to be a re-implementation of ntp_adjtime() > with the addition of ADJ_SETOFFSET. > > 2. ADJ_SETOFFSET adds or subtracts the time specified in a struct timeval > within the timex struct. Unfortunately the FreeBSD timex struct contains no > timeval. To implement this would require versioned symbols to maintain > backward compatiblity. There are two options, as far as I see: 1. Implement new syscall, which would take extended struct timex. ntp_adjtimex() perhaps should be kept for backward compatibility. [It does not matter where struct timeval is placed in the updated struct timex, see below]. 2. Extend existing struct timex with struct timeval at the end of the structure, but do not require it for any mode except when ADJ_SETOFFSET is specified in modes. In other words, syscall should copyin legacy struct timex, and if ADJ_SETOFFSET is set, copying struct timeval from the address right after timex. IMO option 1 is relatively simple and low overhead. Option 2 is just more work for a little gain. If you go the route 1, please add some padding at the end of extended struct timex so potential future modifications do not require a new syscall. Add me to the review anyway. NB. compat32 for ntp_adjtime(2) seems to be completely broken. It is probably a good moment to fix old syscall, since you would need to implement compat32 shims for the new one anyway. > > Up for discussion is: > > 1. Are we, FreeBSD, interested in implementing the Linux adjtimex() > syscall? (I would take on the task to author it should we feel this is a > worthwhile project. OTOH I prefer not to spend the time working on this if > the community feels otherwise.) > > 2. From a cursory scan through the tree it appears that ntp is the only > internal consumer of struct timex. There are probably others in ports and > other third party software such as openntpd and chrony. A versioned symbol > should satisfy old applications which might use the previous timex struct. > > Are we interested in the Linux adjtimex(2) for FreeBSD? > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > The need of the many outweighs the greed of the few. > > > _______________________________________________ > 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" From owner-freebsd-arch@freebsd.org Thu Dec 3 10:17:55 2020 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 A6A804A1DCC for ; Thu, 3 Dec 2020 10:17:55 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CmsGp4S69z3LrB for ; Thu, 3 Dec 2020 10:17:54 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 59DCB8A577; Thu, 3 Dec 2020 10:17:52 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 0B3AHqBc060534 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Dec 2020 10:17:52 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 0B3AHpbT060533; Thu, 3 Dec 2020 10:17:51 GMT (envelope-from phk) To: Konstantin Belousov cc: Cy Schubert , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() In-reply-to: From: "Poul-Henning Kamp" References: <202012030523.0B35NsG7003810@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <60531.1606990671.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Thu, 03 Dec 2020 10:17:51 +0000 Message-ID: <60532.1606990671@critter.freebsd.dk> X-Rspamd-Queue-Id: 4CmsGp4S69z3LrB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[130.225.244.222:from]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[130.225.244.222:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 10:17:55 -0000 -------- Konstantin Belousov writes: > 1. Implement new syscall, which would take extended struct timex. > ntp_adjtimex() perhaps should be kept for backward compatibility. > [It does not matter where struct timeval is placed in the updated > struct timex, see below]. That would break all ports with timekeeping software. Given the role of keeping the system-clock wrangled is single-user and not something you would normally run with old-version software, the simplest solution *if* we want to do this, is to simply extend struct timex for 13-R. BTW: Does anybody know what (is supposed to) happens of ADJ_SETOFFSET is active with other modes in struct timex, in particular MODE_OFFSET ? Is there a document describing how that is supposed to work ? > Add me to the review anyway. Me to. > NB. compat32 for ntp_adjtime(2) seems to be completely broken. It is pr= obabl > y > a good moment to fix old syscall, since you would need to implement comp= at32 > shims for the new one anyway. As per above: Compat'ing this syscall makes very little sense in practice= . -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Thu Dec 3 10:20:18 2020 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 EE2544A1A75 for ; Thu, 3 Dec 2020 10:20:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CmsKZ2Cwzz3MBL for ; Thu, 3 Dec 2020 10:20:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0B3AK7ED036525 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Dec 2020 12:20:11 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0B3AK7ED036525 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0B3AK77P036522; Thu, 3 Dec 2020 12:20:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Dec 2020 12:20:07 +0200 From: Konstantin Belousov To: Poul-Henning Kamp Cc: Cy Schubert , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() Message-ID: References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <60532.1606990671@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60532.1606990671@critter.freebsd.dk> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4CmsKZ2Cwzz3MBL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; TO_DN_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arch]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 10:20:19 -0000 On Thu, Dec 03, 2020 at 10:17:51AM +0000, Poul-Henning Kamp wrote: > -------- > Konstantin Belousov writes: > > > 1. Implement new syscall, which would take extended struct timex. > > ntp_adjtimex() perhaps should be kept for backward compatibility. > > [It does not matter where struct timeval is placed in the updated > > struct timex, see below]. > > That would break all ports with timekeeping software. Why ? From owner-freebsd-arch@freebsd.org Thu Dec 3 10:26:29 2020 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 D654C4A241B for ; Thu, 3 Dec 2020 10:26:29 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CmsSj1tPjz3Mjb for ; Thu, 3 Dec 2020 10:26:28 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 4B1FC8A577; Thu, 3 Dec 2020 10:26:27 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 0B3AQQ2u060614 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Dec 2020 10:26:27 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 0B3AQQeQ060613; Thu, 3 Dec 2020 10:26:26 GMT (envelope-from phk) To: Konstantin Belousov cc: Cy Schubert , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() In-reply-to: From: "Poul-Henning Kamp" References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <60532.1606990671@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <60611.1606991186.1@critter.freebsd.dk> Date: Thu, 03 Dec 2020 10:26:26 +0000 Message-ID: <60612.1606991186@critter.freebsd.dk> X-Rspamd-Queue-Id: 4CmsSj1tPjz3Mjb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RBL_DBL_DONT_QUERY_IPS(0.00)[130.225.244.222:from]; SPAMHAUS_ZRD(0.00)[130.225.244.222:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 10:26:29 -0000 -------- Konstantin Belousov writes: > On Thu, Dec 03, 2020 at 10:17:51AM +0000, Poul-Henning Kamp wrote: > > -------- > > Konstantin Belousov writes: > > > > > 1. Implement new syscall, which would take extended struct timex. > > > ntp_adjtimex() perhaps should be kept for backward compatibility. > > > [It does not matter where struct timeval is placed in the updated > > > struct timex, see below]. > > > > That would break all ports with timekeeping software. > Why ? Last I looked they all had "#ifdef FreeBSD use ntp_adjtim()", so if you rename it to ntp_adjtimex() you break them. I see no problem having a #define to alias timex() to ntp_adjtime(), but I doubt it would make life easier for anybody. (I think we used to have that and it got GC'ed.) *If* we want to do this, the right way is to extend struct timex and let ntpadjtime(2) handle the new modes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Thu Dec 3 10:37:39 2020 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 271744A2368 for ; Thu, 3 Dec 2020 10:37:39 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cmsjb0fy0z3N2b for ; Thu, 3 Dec 2020 10:37:39 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1606991859; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rTYp39xtdeBw/S3cYqbF5nyIZixaeLDdEvyNPoB1pJA=; b=ybnHdIBjvY6IOqZVl4ajjujFLgpr1v/BX7tSXPWdVz1r8OOmpbDlxJnJWGi4VysmwE1Ecv imnZ2Q1Mcdhyq6DW8JljsPLZ/2cV9QLha7HjamIAd5aqRU8dWsAizJEIwyM2vGZx5joofd LrSkBQAuGySuVC08iQpkZrMvII3q0HLrEcLpsVnVdn5LMVE/ECvM2ELSy1lW2NLdCnJDw9 E6ZfIlLSRGFCtaSqBPz+fgRGi53cnou6AHykDyVOCd0hEuPbwIElDqpaGKE2mrfVCxwfnq eQFOKHqQoW1kltRXMLXXgmksuhVg50uBf7VxbUXLkna0fELetgxT0U2S3OpD4g== Received: by freefall.freebsd.org (Postfix, from userid 1471) id F343212450; Thu, 3 Dec 2020 10:37:38 +0000 (UTC) Date: Thu, 3 Dec 2020 11:37:37 +0100 From: Daniel Ebdrup Jensen To: freebsd-arch@freebsd.org Subject: Re: RFC: removing ndis(4) Message-ID: <20201203103737.6jiwbpolehqmkpaf@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-arch@freebsd.org References: <20201203001247.GF18452@spindle.one-eyed-alien.net> <178622db-7dcd-fcae-743c-883711121733@kondratyev.su> <8c1d4dbd-5265-78d4-7d79-9d64f08f7aa4@kondratyev.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <8c1d4dbd-5265-78d4-7d79-9d64f08f7aa4@kondratyev.su> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1606991859; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rTYp39xtdeBw/S3cYqbF5nyIZixaeLDdEvyNPoB1pJA=; b=Md8CwHr6Y/avX+1IXPkPPYjGARy2M1pUm51rS6xqU6Q04lGLauRUtjHa9eA9KF8QZRWhTD Ui7LiJRC2GPBZWFeAvkorFlmkcJH2deJR87BDd14PPrycF9YqToHwhXvQDTzIMv1BKivwe bEN3dVj+66X8rleQQqEMT5t5uTFJnYcnP+tytmjV0/ugXkvgU8BkNB/lpXiD+xjbeGiDu8 n8x/Yf5Adrd0obHFpQ7uKp3p6X4kiFIp2Birvdc1r5mkc6+HEFkVu7wUZuroIYSKs7qm3j QdJqnYVr87PSVEyGCcrkn31LqJpx8QY+0Ablq7VAA2cSGO7WfhmSQdjoigkerw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1606991859; a=rsa-sha256; cv=none; b=nlkCHltV7kwu06zOPbXbgZA7YGF0syXSxYlo44NtCxpMZx+wLkfRaZrry9AJcIl8tUyra0 Lz9iUyBge29VYttbu0pk1HooDRGTaVejOJ010B4llP8SAODiscpRpHw4EYsQwtFb/UrUNS kTlh8r/dXMlZMt0AXKGgv6vdTO4pdSMzfCLseAWC7OBDsLhSc2I7uW5UXFD6WWM54es/Qw 5GhGL+l/0aePDgksCqbglzNFwcRLGLhsQ74yJRW70wny+smy6Gkosbo4HdKCbMefTf3dUH NucG606P/ZJZp+jwdkgCvmcbxWEimDbAF3eSJdVrik7XziYjDbp77fXZGJ4bmA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 10:37:39 -0000 On Thu, Dec 03, 2020 at 06:43:37AM +0300, Vladimir Kondratyev wrote: >On 03.12.2020 06:32, Adrian Chadd wrote: >> On Wed, 2 Dec 2020 at 19:28, Vladimir Kondratyev wrote: >>> >>> On 03.12.2020 03:12, Brooks Davis wrote: >>>> I'd like to propose that we remove the ndis(4) driver prior to FreeBSD >>>> 13. It was a clever idea in the early 2000's when the market was >>>> flooded with 10/100 NICs with Windows-only drivers, but that hasn't been >>>> the case for ages and the driver has had no meaningful maintenance in >>>> ages[0]. I'd be a bit surprised if it worked at all today (it surely >>>> won't work with modern Windows drivers). >>>> >>>> To try to examine the popularity of ndis, I checked dmesgd.nycbug.org >>>> and there are 5 total entries with the most recent being 2007. >>>> >>>> The PC Card attachments are currently marked for deletion prior to >>>> FreeBSD 13. >>>> >>>> Unless there is surprising outcry I plan to add (and MFC) deprecation >>>> notices in about a week's time and remove the driver shortly thereafter. >>>> >>>> -- Brooks >>>> >>>> [0] I noticed today that part of the ndis 802.11 ioctl handler has been >>>> broken since 2005. >>> >>> ndis(4) was functional at least in 2015 and at that time it was the only >>> way to utilize BCM's wi-fi built in my "Asus EEEPC" >> >> Everything has moved onto new NDIS APIs that we don't support. >> > >BCM4313 devices still have a Win-XP driver. No one tried to delete it >all-over-the-internet. > > >_______________________________________________ >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" Yes, you can absolutely find old drivers - but Windows XP was using NDIS 5.1, and the specification has since moved on from 6.0 (with Vista) all the way to 6.8x, with at least one major change that makes them incompatible. Even the Extended Support for Point-of-Sale systems has expired, so unless you're proposing that FreeBSD support something for longer than the vendor that made it, and find someone who wants to step up to maintain it, I don't see how the project can realistically keep the code if nobody has been known to run it for at least half a decade? Yours respectfully, Daniel Ebdrup Jensen From owner-freebsd-arch@freebsd.org Thu Dec 3 10:46:22 2020 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 00C814A2C1A for ; Thu, 3 Dec 2020 10:46:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CmsvX3XZLz3Nk3 for ; Thu, 3 Dec 2020 10:46:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0B3Ak4UK043254 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Dec 2020 12:46:07 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0B3Ak4UK043254 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0B3Ak4d6043245; Thu, 3 Dec 2020 12:46:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Dec 2020 12:46:04 +0200 From: Konstantin Belousov To: Poul-Henning Kamp Cc: Cy Schubert , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() Message-ID: References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <60532.1606990671@critter.freebsd.dk> <60612.1606991186@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60612.1606991186@critter.freebsd.dk> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4CmsvX3XZLz3Nk3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_SOFTFAIL(0.00)[~all:c]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2001:470:d5e7:1::1:query timed out]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 10:46:22 -0000 On Thu, Dec 03, 2020 at 10:26:26AM +0000, Poul-Henning Kamp wrote: > -------- > Konstantin Belousov writes: > > On Thu, Dec 03, 2020 at 10:17:51AM +0000, Poul-Henning Kamp wrote: > > > -------- > > > Konstantin Belousov writes: > > > > > > > 1. Implement new syscall, which would take extended struct timex. > > > > ntp_adjtimex() perhaps should be kept for backward compatibility. > > > > [It does not matter where struct timeval is placed in the updated > > > > struct timex, see below]. > > > > > > That would break all ports with timekeeping software. > > Why ? > > Last I looked they all had "#ifdef FreeBSD use ntp_adjtim()", so if > you rename it to ntp_adjtimex() you break them. > > I see no problem having a #define to alias timex() to ntp_adjtime(), > but I doubt it would make life easier for anybody. (I think we used > to have that and it got GC'ed.) > > *If* we want to do this, the right way is to extend struct timex and > let ntpadjtime(2) handle the new modes. I do not propose to rename anything, the new syscall should be called ntp_adjtime, as it is now. Current (old) syscall, that takes current (non-extended) struct timex, would be kept versioned at FBSD_1.0. New syscall should come at FBSD_1.6 version and take new structure, still called struct timex. All existing sources should start using new syscall by recompile. If we provide ntp_adjtime@FBSD_1.0 AKA syscall slot 176, old binaries would continue working, and doing this is very easy, so I do not see why not. From owner-freebsd-arch@freebsd.org Thu Dec 3 10:49:42 2020 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 CB39E4A31A4 for ; Thu, 3 Dec 2020 10:49:42 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CmszS6NTZz3PGg for ; Thu, 3 Dec 2020 10:49:39 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id C024A8A577; Thu, 3 Dec 2020 10:49:36 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 0B3Anaqe060912 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Dec 2020 10:49:36 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 0B3AnaJt060911; Thu, 3 Dec 2020 10:49:36 GMT (envelope-from phk) To: Konstantin Belousov cc: Cy Schubert , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() In-reply-to: From: "Poul-Henning Kamp" References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <60532.1606990671@critter.freebsd.dk> <60612.1606991186@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <60909.1606992576.1@critter.freebsd.dk> Date: Thu, 03 Dec 2020 10:49:36 +0000 Message-ID: <60910.1606992576@critter.freebsd.dk> X-Rspamd-Queue-Id: 4CmszS6NTZz3PGg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[130.225.244.222:from]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[130.225.244.222:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 10:49:42 -0000 -------- Konstantin Belousov writes: > On Thu, Dec 03, 2020 at 10:26:26AM +0000, Poul-Henning Kamp wrote: > > -------- > > Konstantin Belousov writes: > > > On Thu, Dec 03, 2020 at 10:17:51AM +0000, Poul-Henning Kamp wrote: > > > > -------- > > > > Konstantin Belousov writes: > > > > > > > > > 1. Implement new syscall, which would take extended struct timex. > > > > > ntp_adjtimex() perhaps should be kept for backward compatibility. > > > > > [It does not matter where struct timeval is placed in the updated > > > > > struct timex, see below]. > > > > > > > > That would break all ports with timekeeping software. > > > Why ? > > > > Last I looked they all had "#ifdef FreeBSD use ntp_adjtim()", so if > > you rename it to ntp_adjtimex() you break them. > > > > I see no problem having a #define to alias timex() to ntp_adjtime(), > > but I doubt it would make life easier for anybody. (I think we used > > to have that and it got GC'ed.) > > > > *If* we want to do this, the right way is to extend struct timex and > > let ntpadjtime(2) handle the new modes. > > I do not propose to rename anything, the new syscall should be called > ntp_adjtime, as it is now. Ahh, sorry. In the first email (quoted above) you wrote "ntp_adjtimex" and I thought that was deliberate. In that case, yeah, then your #1 is probably the way to go *IF* we want to do this. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Thu Dec 3 16:31:17 2020 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 1BF9C4A9F5E for ; Thu, 3 Dec 2020 16:31:17 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cn1Yc4h8yz4RpG for ; Thu, 3 Dec 2020 16:31:16 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1607013075; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=LiyX1bMLEigZ5W7wg3QhmQL8f4bpPIf5TayNlbdiATG1SRRsbhLQYRc+kb5r9ROHGVPgtv+3akKI8 dBoJkUMHBTsRPqdy99aCfO8L/fhoXZeUjT+pvrP07ENXsvbblKtIWXjw9fCr6Cb0zN04vuqBCbN+0Q re3HfvZk1pETYNFVjVq4y9h4H6SpH+XUZAIF7CAoC0tfLOQsqP+Q25xiVf4yufv19ef2sF6rTURNT/ acXwJa5olsdbDCnktZ8tNIU/DjBBQ8qhPOcMd5HuUNnD4TtJg0/szh34CBQSkW80OghwMbRYmGbPTg GWTYBl5TMRZAkJTrGWiooWLYDz8kFlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=omhZxo2ciNFTTIUtSx0hw4woUf0dNKfVRg4FdyCSdLc=; b=N7LQtgzrhznIXAjB3olJTeBfGLVzuxmGNKn0fdlIbZNtqhnyTFaWhCb3mM7gs2d7nFJkKgd1YePWY 25TWJOdBgn0YfQ3gY6/LyGUT+zNS92zxD6bVX19AzWeh5f2X5ESDQs518+8YfTFdYibsp5dQo0AKVn xl0+VAWDlVjXvF3nlU45+M+1LyHc9V5Czo2TNsd2MV6LhthxX6Vxf6S2xEmfSP1TEiGiqr7+BjbYwI dK9xqp2UjaUbjbqnLtIGNWGE1KWJcPciIMGQKS/G/JCffXsCbsYlkmaWYhRCf4eZ1GtdrXAMvWKZ+D u9F0JNa8grr2wpfZWGqpU7lyz+WErlw== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=omhZxo2ciNFTTIUtSx0hw4woUf0dNKfVRg4FdyCSdLc=; b=tiIIwaZmKw+U11uDCthRbxKjbM0La2pFjkcKdSNgpwc8cKfSGshnr7iNlT/0qk24TzPZLZgWirco7 y9itcx2kdYQZm7cL1B3j3jCaoPetxuO4HW/pW0Hdd8FVNqnXWPezJaDkYtQJHVBGGGY13ET33UXA3V i2M49ghmCp74wMumkYz4pXN3252GomUuYlDNIQZQT0u267Q1z8pZqgGKkSwx3tuRUdVVnM6CO5df2s SnoWBQaU0eHBOhpyRygnmlSgyJY+CSMxOva1KTmLotZaPnx60zhKRgr0Yof1JC/zQ3Cc7kK5UAdx2q s7KUjHIYuzoxfYcz6y1kyMfh+/Z2EeA== X-MHO-RoutePath: aGlwcGll X-MHO-User: f414f1e4-3584-11eb-9e14-df46ed8f892f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id f414f1e4-3584-11eb-9e14-df46ed8f892f; Thu, 03 Dec 2020 16:31:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 0B3GVAUK003421; Thu, 3 Dec 2020 09:31:11 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> Subject: Re: struct timex and Linux adjtimex() From: Ian Lepore To: Poul-Henning Kamp , Cy Schubert Cc: freebsd-arch@freebsd.org Date: Thu, 03 Dec 2020 09:31:10 -0700 In-Reply-To: <4086.1606982335@critter.freebsd.dk> References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <4086.1606982335@critter.freebsd.dk> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Cn1Yc4h8yz4RpG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 16:31:17 -0000 On Thu, 2020-12-03 at 07:58 +0000, Poul-Henning Kamp wrote: > -------- > Cy Schubert writes: > > > 1. A new syscall, similar to clock_settime() and clock_gettime() > > that > > adds/subtracts the delta, in a struct timespec, via a call to > > kern_clock_settime(). Then atomically returns the current time as > > if > > clock_gettime() was immediately called. > > Did they say why they need this and why simply setting the clock is > not > good enough ? > > What program uses this ? > I have been very much wanting this feature for years, so much so that I've come close to hacking it in myself and just carrying it as local patches to the kernel at $work. We run freebsd on hardware whose timecounter clock is fed from a gps- disciplined oscillator and the hardware in the SOC implementing that clock can capture the counter on an edge of an incoming PPS (which is generated from the same disciplined oscillator), so we can get fairly accurate phase measurements. But I can't set the time with anything like the same accuracy. After a clock_settime() call I'm still off by anything from hundreds of microseconds to milliseconds and have to wait for that error to be tediously steered out over the course of many minutes. Once kernel time is phase-aligned, it never needs to be steered again. It has always bugged me that any steering is needed at all, it should be possible to set the phase once and be perfectly on-time from that point forward. (Perfect meaning within the measurement capabilities of the hardware, typically within about 150ns, which is certainly good enough for ntp and most PTP applications.) I'm relatively agnostic about how the ability to offset the clock is implemented, a new syscall works fine for me. I notice a struct timeval was mentioned, but hopefully that's in a context where MOD_NANO/STA_NANO apply and tv_usec will actually convey nanos? -- Ian From owner-freebsd-arch@freebsd.org Thu Dec 3 16:36:01 2020 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 B67A24AA464 for ; Thu, 3 Dec 2020 16:36:01 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cn1g45cp7z4ScX for ; Thu, 3 Dec 2020 16:36:00 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 8E2053C0199; Thu, 3 Dec 2020 16:35:54 +0000 (UTC) Date: Thu, 3 Dec 2020 16:35:54 +0000 From: Brooks Davis To: Konstantin Belousov Cc: Cy Schubert , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() Message-ID: <20201203163554.GG18452@spindle.one-eyed-alien.net> References: <202012030523.0B35NsG7003810@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pql/uPZNXIm1JCle" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4Cn1g45cp7z4ScX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; FREEFALL_USER(0.00)[brooks]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[199.48.129.229:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[199.48.129.229:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 16:36:01 -0000 --Pql/uPZNXIm1JCle Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Dec 03, 2020 at 12:05:04PM +0200, Konstantin Belousov wrote: > 2. Extend existing struct timex with struct timeval at the end of > the structure, but do not require it for any mode except when > ADJ_SETOFFSET is specified in modes. In other words, syscall > should copyin legacy struct timex, and if ADJ_SETOFFSET is set, > copying struct timeval from the address right after timex. Discussion seems to have selected option 1, but to put a stake in it, this option should be avoided due to the complexity it imposes on system call wrappers and argument validators. In general, paths should be the only arguments with lengths not immediately determinable from the type or a length argument. Anything that complicates determining the memory footprint of a system call is to be avoided. -- Brooks --Pql/uPZNXIm1JCle Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJfyRPpAAoJEKzQXbSebgfAoFYIAJKQo4O8PC/eIydoLkiS2Gwf kk46p43taa81b7brS2CSeNkUjNKKmICvoKYhEduM7U197wDK8aEm2AVg/dAidXVN 5vs8oQxHGyKO2WpIOAyOxHpAugKSJuerg37gG7oVwkYAhpOn+mZqCwdHkfiF/f1M ssNmP6sOZ7+4BXyStsmYlMR3oXETBHmKeFGYeaBSzLFNOz8t9qKjER2+Nc6Rwz9K V9g3J5qgvCCdcBNVp9FybxGq1Q/b1ii5OEGijWvLOGZB9ET9UwkXd6IF52U3Tq+L +/y1Cid2EAjMDgECV4LCjgsFCm4Nwyo2imP2duIAutndPtQPhFVoAql3IOxLcns= =th0k -----END PGP SIGNATURE----- --Pql/uPZNXIm1JCle-- From owner-freebsd-arch@freebsd.org Thu Dec 3 17:17:43 2020 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 E5F1C4AB70B for ; Thu, 3 Dec 2020 17:17:43 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cn2bB6LLRz4WRF for ; Thu, 3 Dec 2020 17:17:41 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.229.168]) by shaw.ca with ESMTPA id ksEbksCzLktFkksEdk4GUf; Thu, 03 Dec 2020 10:17:40 -0700 X-Authority-Analysis: v=2.4 cv=NYRYa0P4 c=1 sm=1 tr=0 ts=5fc91db4 a=7AlCcx2GqMg+lh9P3BclKA==:117 a=7AlCcx2GqMg+lh9P3BclKA==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=zTNgK-yGK50A:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=n4pyo7QS8phUtEAsigkA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 1EBAD623; Thu, 3 Dec 2020 09:17:37 -0800 (PST) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 0B3HHalx003916; Thu, 3 Dec 2020 09:17:37 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202012031717.0B3HHalx003916@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "Poul-Henning Kamp" cc: Konstantin Belousov , Cy Schubert , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() In-reply-to: <60612.1606991186@critter.freebsd.dk> References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <60532.1606990671@critter.freebsd.dk> <60612.1606991186@critter.freebsd.dk> Comments: In-reply-to "Poul-Henning Kamp" message dated "Thu, 03 Dec 2020 10:26:26 +0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Dec 2020 09:17:36 -0800 X-CMAE-Envelope: MS4xfKK4g56e34rcLi1K9ZMLEfQatWco9qE5wHe4kaCIk3Djlu7YS2/yJwCVNtkhQ07WulTNt1i28yvR8ccj7kNpmMnsjf1EVPPmUAh7XN0O9dcMwBN1rGew /EI4uYpLC55bj7ozojuymGPm8b5etvPTLyeOOIgo9QqFddabXaFgU+KU5przynoHIqlZRn64DaEkF43fjtMOa4/qDmALStSQhVp4SbvfKm2/5g9RyBaAFqnK 0bFen41pxsVrlLGAM5okLq76aeCCynShaTOoYqTigXo= X-Rspamd-Queue-Id: 4Cn2bB6LLRz4WRF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.139) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-1.70 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[70.67.229.168:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.59.136.139:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_VERYGOOD(0.00)[64.59.136.139:from]; FREEMAIL_CC(0.00)[gmail.com,cschubert.com,freebsd.org]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 17:17:44 -0000 In message <60612.1606991186@critter.freebsd.dk>, "Poul-Henning Kamp" writes: > -------- > Konstantin Belousov writes: > > On Thu, Dec 03, 2020 at 10:17:51AM +0000, Poul-Henning Kamp wrote: > > > -------- > > > Konstantin Belousov writes: > > > > > > > 1. Implement new syscall, which would take extended struct timex. > > > > ntp_adjtimex() perhaps should be kept for backward compatibility. > > > > [It does not matter where struct timeval is placed in the updated > > > > struct timex, see below]. > > > > > > That would break all ports with timekeeping software. > > Why ? > > Last I looked they all had "#ifdef FreeBSD use ntp_adjtim()", so if > you rename it to ntp_adjtimex() you break them. There was no discussion about renaming ntp_adjtime() to ntp_adjtimex(). ntp_adjtime() would remain. A new adjtimex() would be added. > > I see no problem having a #define to alias timex() to ntp_adjtime(), > but I doubt it would make life easier for anybody. (I think we used > to have that and it got GC'ed.) > > *If* we want to do this, the right way is to extend struct timex and > let ntpadjtime(2) handle the new modes. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Thu Dec 3 20:06:11 2020 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 7B53F4AE7BB for ; Thu, 3 Dec 2020 20:06:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cn6KZ1MW8z4gvL for ; Thu, 3 Dec 2020 20:06:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0B3K5sm9076185 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Dec 2020 22:05:57 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0B3K5sm9076185 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0B3K5rhw076184; Thu, 3 Dec 2020 22:05:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 3 Dec 2020 22:05:53 +0200 From: Konstantin Belousov To: Cy Schubert Cc: Poul-Henning Kamp , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() Message-ID: References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <60532.1606990671@critter.freebsd.dk> <60612.1606991186@critter.freebsd.dk> <202012031717.0B3HHalx003916@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <202012031717.0B3HHalx003916@slippy.cwsent.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4Cn6KZ1MW8z4gvL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.91 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; TO_DN_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.91)[-0.913]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 20:06:11 -0000 On Thu, Dec 03, 2020 at 09:17:36AM -0800, Cy Schubert wrote: > In message <60612.1606991186@critter.freebsd.dk>, "Poul-Henning Kamp" > writes: > > -------- > > Konstantin Belousov writes: > > > On Thu, Dec 03, 2020 at 10:17:51AM +0000, Poul-Henning Kamp wrote: > > > > -------- > > > > Konstantin Belousov writes: > > > > > > > > > 1. Implement new syscall, which would take extended struct timex. > > > > > ntp_adjtimex() perhaps should be kept for backward compatibility. > > > > > [It does not matter where struct timeval is placed in the updated > > > > > struct timex, see below]. > > > > > > > > That would break all ports with timekeeping software. > > > Why ? > > > > Last I looked they all had "#ifdef FreeBSD use ntp_adjtim()", so if > > you rename it to ntp_adjtimex() you break them. > > There was no discussion about renaming ntp_adjtime() to ntp_adjtimex(). > ntp_adjtime() would remain. A new adjtimex() would be added. As discussed, we should stay with ntp_adjtime(), it seems. Libc may provide adjtimex() as an alias if this makes some porting easier. BTW, I can code the syscall and compat layers, if this would make thinks easier for everybody. I can do the addition of the actual flag if you describe the semantic in more details. I see the description of ADJ_SETOFFSET in the Linux adjtimex(2) man page: ADJ_SETOFFSET (since Linux 2.6.39) Add buf.time to the current time. If buf.status includes the ADJ_NANO flag, then buf.time.tv_usec is interpreted as a nanosecond value; otherwise it is interpreted as microseconds. The value of buf.time is the sum of its two fields, but the field buf.time.tv_usec must always be nonnegative. The follow‐ ing example shows how to normalize a timeval with nanosecond resolution. while (buf.time.tv_usec < 0) { buf.time.tv_sec -= 1; buf.time.tv_usec += 1000000000; } I do not quite understand the context and internal meaning of the second paragraph, though. Kernel should not allow negative tv_usec as the input parameter, right ? > > > > > I see no problem having a #define to alias timex() to ntp_adjtime(), > > but I doubt it would make life easier for anybody. (I think we used > > to have that and it got GC'ed.) > > > > *If* we want to do this, the right way is to extend struct timex and > > let ntpadjtime(2) handle the new modes. > > > > -- > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > phk@FreeBSD.ORG | TCP/IP since RFC 956 > > FreeBSD committer | BSD since 4.3-tahoe > > Never attribute to malice what can adequately be explained by incompetence. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > The need of the many outweighs the greed of the few. > From owner-freebsd-arch@freebsd.org Thu Dec 3 20:15:31 2020 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 51AF34AEA95 for ; Thu, 3 Dec 2020 20:15:31 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cn6XL3dSDz4h7N for ; Thu, 3 Dec 2020 20:15:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 784AF8A577; Thu, 3 Dec 2020 20:15:28 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 0B3KFSFn025220 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Dec 2020 20:15:28 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 0B3KFRdu025219; Thu, 3 Dec 2020 20:15:27 GMT (envelope-from phk) To: Konstantin Belousov cc: Cy Schubert , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() In-reply-to: From: "Poul-Henning Kamp" References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <60532.1606990671@critter.freebsd.dk> <60612.1606991186@critter.freebsd.dk> <202012031717.0B3HHalx003916@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <25217.1607026527.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Thu, 03 Dec 2020 20:15:27 +0000 Message-ID: <25218.1607026527@critter.freebsd.dk> X-Rspamd-Queue-Id: 4Cn6XL3dSDz4h7N X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RBL_DBL_DONT_QUERY_IPS(0.00)[130.225.244.222:from]; SPAMHAUS_ZRD(0.00)[130.225.244.222:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 20:15:31 -0000 -------- Konstantin Belousov writes: > > The value of buf.time is the sum of its two fields, b= ut the > field buf.time.tv_usec must always be nonnegative. The f= ollow=E2=80=90 > ing example shows how to normalize a timeval with nano= second > resolution. > > while (buf.time.tv_usec < 0) { > buf.time.tv_sec -=3D 1; > buf.time.tv_usec +=3D 1000000000; > } > > I do not quite understand the context and internal meaning of the second > paragraph, though. Kernel should not allow negative tv_usec as the inpu= t > parameter, right ? Correct. Minus 10 nanoseconds should be expressed as { .tv_sec =3D -1; .tv_nsec =3D= 999999990; } -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Thu Dec 3 21:00:26 2020 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 8EE164AF71B for ; Thu, 3 Dec 2020 21:00:26 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cn7X965s0z4l5q; Thu, 3 Dec 2020 21:00:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id CC6698A577; Thu, 3 Dec 2020 21:00:23 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 0B3L0Nbx025489 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Dec 2020 21:00:23 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 0B3L0NOb025488; Thu, 3 Dec 2020 21:00:23 GMT (envelope-from phk) To: Ian Lepore cc: Cy Schubert , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() In-reply-to: <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> From: "Poul-Henning Kamp" References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <4086.1606982335@critter.freebsd.dk> <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25486.1607029223.1@critter.freebsd.dk> Date: Thu, 03 Dec 2020 21:00:23 +0000 Message-ID: <25487.1607029223@critter.freebsd.dk> X-Rspamd-Queue-Id: 4Cn7X965s0z4l5q X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RBL_DBL_DONT_QUERY_IPS(0.00)[130.225.244.222:from]; SPAMHAUS_ZRD(0.00)[130.225.244.222:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 21:00:26 -0000 -------- Ian Lepore writes: > On Thu, 2020-12-03 at 07:58 +0000, Poul-Henning Kamp wrote: > We run freebsd on hardware whose timecounter clock is fed from a gps- > disciplined oscillator and the hardware in the SOC implementing that > clock can capture the counter on an edge of an incoming PPS (which is > generated from the same disciplined oscillator), so we can get fairly > accurate phase measurements. > > But I can't set the time with anything like the same accuracy. Wrong. You can set time with nanosecond precision, even pretty quickly, but you cannot *step* it with nano-second precision. (This last is an universal truth: The code to do the load+add+store takes instructions on the order of several nanoseconds, and try as you might, you cannot calibrate that offset to sub-nanosecond uncertainty on contemporary hardware. This is why there is no escaping fiddling with minute frequency adjustments and measurements over a period of time, if you want your clock to be precise at the ~sub-20 nanosecond level.) MOD_OFFSET will precisly slew the clock a given offset over a period of time, in an exponential-decay manner, taking pains to ensure time never stops og goes backwards. The "no-step-no-stop" policy was a very deliberate design decision by Dave Mills, and not one he was ever willing to compromise on. His argument was that while forward steps are generally not too troublesome, time should never *ever* go backwards, *and* that postive and negative offsets should be handled identically. On a purely philosophical basis, that argument is unassailable, but we have all tried CMOS RTC's giving us bogus time. Both the "initial step" code in ntpd(8) and the ntpdate(8) program exists as workarounds around Daves veto, to cope with bad CMOS time. Fortunately time-steps are a lot less poisonous these days, because people have discovered CLOCK_MONOTONIC, but "no-step-no-stop" is fundamentally still the right way to go. Anyway, the "ADJ_SETOFFSET" is a hackish bolt-on, starting with the fact that the "ADJ_" prefix is totally out of family for , and any interaction with the rest of the PLL is unspecified. That is why I'm not too entusiastic about adopting it. A more correct integration in the kernel-pll would be to have a modifier flag for MOD_OFFSET which indicates that a step is desired, and document that it zeros the PLL as part of the operation. But as mentioned above, no matter what, the precision is probably limited to around 25 nanoseconds, possibly more depending on locking, and while that may be good enough for your specific case, it is a blemish on the otherwise very stringent about precision PLL code. > I notice a struct timeval was mentioned, but hopefully that's in a > context where MOD_NANO/STA_NANO apply and tv_usec will actually convey > nanos? Yes, when the _NANO flag is set, the timeval is a timespec -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Thu Dec 3 22:01:11 2020 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 46ACD4B07E7 for ; Thu, 3 Dec 2020 22:01:11 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound5a.ore.mailhop.org (outbound5a.ore.mailhop.org [44.233.67.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cn8tH0CCNz4pRl for ; Thu, 3 Dec 2020 22:01:10 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1607032863; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=VRihffQa2t8z/Gu1hnftKxURFEQbbKyHD6wCXntcH0ZBCJsRWhAZJ9siWK5+B3J44lyqKS1E2ciug dHdVVyBfypEevfItXuMfLEGGrfQp7asnHuRTmF61C14sTuZ2G2FCTtK6Co9uhee8yjjqG9vzkdMhIn 2dPddTpad+DfGz04uq5k2rijU92tAkyBCz1czoiwVBI59DoZHoLE9cWoCwt3BtiVpHhOfck2jorpR5 Ij5LqCkavqYENqzK/ez8D08RzgzAKb4JfCuI1OvSvypGFJQWL78zoReKHhFTGu/ceSG4MMet0igkkZ +SAfkkrhUvdnf4Qw7oTzFWa8mrqlKmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=Js/eB1V5ayODFPGoUf7u8DlKNp086GKOJLfM1PLTCPo=; b=g4JkQl2eLpF/mNs8b3XI3fAg8bEdyim0JNxzGnxa4Qc4po9ngxfW4Fa6Ud0pv7GDbQBj/+Nt8CQd6 k9GmXOBbsqIbdUDrDljd/rWJ4nfZ5atwqYGhfT1RWztjkINSiODgzP2mGHTKNv0Tnzp04gdBCoSKRa yUDSpyZdPMSvmrWP+wpIafwsyB91Lab2NJm4nrPViDNz6+OvX6Ja5sWgi5bC0KhwtJfJSlLAxnzk68 WUAJ4GfF7ZgmfuABP3Y7xIeCCr0z1CkH4khI6WQdX0fehKGe9MDuqRqdUwW7iPXHBmQHJ1NVAID7Gg 7nNyZsPRHLD+4bJJEe5PHDM/rBlK//Q== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=Js/eB1V5ayODFPGoUf7u8DlKNp086GKOJLfM1PLTCPo=; b=irEK/Dh3Y2o1oVCOj9g1Mqfp0RdUKTM4IHGtW7dsv7RUJDD0xIy/1r8XvvZ7eq0QdVWyYyWLaD8Id bhunWuGgT+Ykiu0J7sKR8foXPVGeVKKF/brNuL6HHTvFHOEUNXCtLkkOkAr2RUL/g7z2OB1qoqoogH 8jzZuRocnHIRrOLNgd2wH5OS5Z3V9NdS+Mii1T70UU6bhblBlw4AkScCOfLrUK5bpGhnmI5q2MGgBH x+kge4CC/B8+mH+MOObVt0YIFhFph1ZL4UUvI/7MkY1mVCNDbj0R2bJweWr2xmkF+GcwtXxSxjfE05 26y6jixU7hpsd3vVGxfqwi/vsyTiTaw== X-MHO-RoutePath: aGlwcGll X-MHO-User: 06895df3-35b3-11eb-8b39-614106969e8d X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 06895df3-35b3-11eb-8b39-614106969e8d; Thu, 03 Dec 2020 22:01:01 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 0B3M0wMc004322; Thu, 3 Dec 2020 15:00:58 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: struct timex and Linux adjtimex() From: Ian Lepore To: Poul-Henning Kamp Cc: freebsd-arch@freebsd.org Date: Thu, 03 Dec 2020 15:00:58 -0700 In-Reply-To: <25487.1607029223@critter.freebsd.dk> References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <4086.1606982335@critter.freebsd.dk> <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> <25487.1607029223@critter.freebsd.dk> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Cn8tH0CCNz4pRl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 22:01:11 -0000 On Thu, 2020-12-03 at 21:00 +0000, Poul-Henning Kamp wrote: > -------- > Ian Lepore writes: > > On Thu, 2020-12-03 at 07:58 +0000, Poul-Henning Kamp wrote: > > We run freebsd on hardware whose timecounter clock is fed from a > > gps- > > disciplined oscillator and the hardware in the SOC implementing > > that > > clock can capture the counter on an edge of an incoming PPS (which > > is > > generated from the same disciplined oscillator), so we can get > > fairly > > accurate phase measurements. > > > > But I can't set the time with anything like the same accuracy. > > Wrong. > > You can set time with nanosecond precision, even pretty quickly, > but you cannot *step* it with nano-second precision. > > (This last is an universal truth: The code to do the load+add+store > takes instructions on the order of several nanoseconds, and try as > you might, you cannot calibrate that offset to sub-nanosecond > uncertainty on contemporary hardware. This is why there is no > escaping fiddling with minute frequency adjustments and measurements > over a period of time, if you want your clock to be precise at the > ~sub-20 nanosecond level.) > > MOD_OFFSET will precisly slew the clock a given offset over a period > of time, in an exponential-decay manner, taking pains to ensure > time never stops og goes backwards. > > The "no-step-no-stop" policy was a very deliberate design decision > by Dave Mills, and not one he was ever willing to compromise on. > > His argument was that while forward steps are generally not too > troublesome, time should never *ever* go backwards, *and* that > postive and negative offsets should be handled identically. > > On a purely philosophical basis, that argument is unassailable, > but we have all tried CMOS RTC's giving us bogus time. > > Both the "initial step" code in ntpd(8) and the ntpdate(8) program > exists as workarounds around Daves veto, to cope with bad CMOS > time. > > Fortunately time-steps are a lot less poisonous these days, because > people have discovered CLOCK_MONOTONIC, but "no-step-no-stop" is > fundamentally still the right way to go. > > Anyway, the "ADJ_SETOFFSET" is a hackish bolt-on, starting with the > fact that the "ADJ_" prefix is totally out of family for > , > and any interaction with the rest of the PLL is unspecified. > > That is why I'm not too entusiastic about adopting it. > > A more correct integration in the kernel-pll would be to have a > modifier flag for MOD_OFFSET which indicates that a step is desired, > and document that it zeros the PLL as part of the operation. > > But as mentioned above, no matter what, the precision is probably > limited to around 25 nanoseconds, possibly more depending on locking, > and while that may be good enough for your specific case, it is > a blemish on the otherwise very stringent about precision PLL code. > > As usual, all those arguments make good sense in a pristine academic world, and no sense at all in a venue such as an embedded-system timekeeping product that doesn't even run ntpd and doesn't care in the slightest about stepping the time at startup (indeed, has no option but to step the time since there is no cmos or other clock to keep time during power-off, and even you have to admit that carefully slewing the time forward from 1/1/70 to the present in tiny increments is a bit impractical). -- Ian From owner-freebsd-arch@freebsd.org Thu Dec 3 22:03:37 2020 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 09FA74B0D91 for ; Thu, 3 Dec 2020 22:03:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cn8x45Kz5z4ppP; Thu, 3 Dec 2020 22:03:36 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.229.168]) by shaw.ca with ESMTPA id kwhIkuSBFktFkkwhJk5g6y; Thu, 03 Dec 2020 15:03:35 -0700 X-Authority-Analysis: v=2.4 cv=NYRYa0P4 c=1 sm=1 tr=0 ts=5fc960b7 a=7AlCcx2GqMg+lh9P3BclKA==:117 a=7AlCcx2GqMg+lh9P3BclKA==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=zTNgK-yGK50A:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=RwVsqvfjfJKKwxMFqc0A:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 27512232; Thu, 3 Dec 2020 14:03:31 -0800 (PST) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 0B3M3VJx004269; Thu, 3 Dec 2020 14:03:31 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202012032203.0B3M3VJx004269@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "Poul-Henning Kamp" cc: Ian Lepore , Cy Schubert , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() In-reply-to: <25487.1607029223@critter.freebsd.dk> References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <4086.1606982335@critter.freebsd.dk> <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> <25487.1607029223@critter.freebsd.dk> Comments: In-reply-to "Poul-Henning Kamp" message dated "Thu, 03 Dec 2020 21:00:23 +0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Dec 2020 14:03:31 -0800 X-CMAE-Envelope: MS4xfPXuuuGqNJMQ6WZRRaLcokb66RW1elWmlUm1520t7Pw3yp3/rP+TUL3F5DOMzMVIVK90x2/rXpCqDrrEwQUO9AQ1yyhFF+mMzqPSN12DCpxXdbLS0lM3 5WGW68qzyJmUOQpvcfhKuSKYaSGil0hgmDsCIMvbMoJVWIxeks/QPUqA7fNrxdT74LpHY+s71MdWEQnikhAdPiaQX6p+/5JS8TpX5NLUFRGUXcyrrwvZPxgk ARpj3tKkLsnR3pFj7LK1F9beDWcksqgM1YGP2d8Xapc= X-Rspamd-Queue-Id: 4Cn8x45Kz5z4ppP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 22:03:37 -0000 In message <25487.1607029223@critter.freebsd.dk>, "Poul-Henning Kamp" writes: > -------- > Ian Lepore writes: > > On Thu, 2020-12-03 at 07:58 +0000, Poul-Henning Kamp wrote: > > > We run freebsd on hardware whose timecounter clock is fed from a gps- > > disciplined oscillator and the hardware in the SOC implementing that > > clock can capture the counter on an edge of an incoming PPS (which is > > generated from the same disciplined oscillator), so we can get fairly > > accurate phase measurements. > > > > But I can't set the time with anything like the same accuracy. > > Wrong. > > You can set time with nanosecond precision, even pretty quickly, > but you cannot *step* it with nano-second precision. > > (This last is an universal truth: The code to do the load+add+store > takes instructions on the order of several nanoseconds, and try as > you might, you cannot calibrate that offset to sub-nanosecond > uncertainty on contemporary hardware. This is why there is no > escaping fiddling with minute frequency adjustments and measurements > over a period of time, if you want your clock to be precise at the > ~sub-20 nanosecond level.) > > MOD_OFFSET will precisly slew the clock a given offset over a period > of time, in an exponential-decay manner, taking pains to ensure > time never stops og goes backwards. > > The "no-step-no-stop" policy was a very deliberate design decision > by Dave Mills, and not one he was ever willing to compromise on. > > His argument was that while forward steps are generally not too > troublesome, time should never *ever* go backwards, *and* that > postive and negative offsets should be handled identically. > > On a purely philosophical basis, that argument is unassailable, > but we have all tried CMOS RTC's giving us bogus time. > > Both the "initial step" code in ntpd(8) and the ntpdate(8) program > exists as workarounds around Daves veto, to cope with bad CMOS > time. > > Fortunately time-steps are a lot less poisonous these days, because > people have discovered CLOCK_MONOTONIC, but "no-step-no-stop" is > fundamentally still the right way to go. > > Anyway, the "ADJ_SETOFFSET" is a hackish bolt-on, starting with the > fact that the "ADJ_" prefix is totally out of family for , > and any interaction with the rest of the PLL is unspecified. Yes. The initial proposal was for a uniquely new syscall that simply added and subtracted. But that quickly became a discussion about adjtimex(). Looking at the Linux code a few days ago it became apparent that adjtimex() was a hack. ADJ_TICK is another hack similar to MOD_FREQUENCY, which is called ADJ_FREQUENCY in adjtimex. ADJ_TICK is handled by ADJ_FREQUENCY (which is synonymous to MOD_FREQUENCY). ADJ_TICK looks broken. The Linux sys/timex.h equates the ADJ_* to MOD_* except for ADJ_SETOFFSET and ADJ_TICK, which aren't supported by ntp_adjtime(). > > That is why I'm not too entusiastic about adopting it. Neither am I, which is why I raised the issue here. They felt the need for it. Having discussion here gives me more gravitas to speak for the Project. Having said that, I'd roll up my sleeves to implement what we decided here. > > A more correct integration in the kernel-pll would be to have a > modifier flag for MOD_OFFSET which indicates that a step is desired, > and document that it zeros the PLL as part of the operation. > > But as mentioned above, no matter what, the precision is probably > limited to around 25 nanoseconds, possibly more depending on locking, > and while that may be good enough for your specific case, it is > a blemish on the otherwise very stringent about precision PLL code. > > > > I notice a struct timeval was mentioned, but hopefully that's in a > > context where MOD_NANO/STA_NANO apply and tv_usec will actually convey > > nanos? > > Yes, when the _NANO flag is set, the timeval is a timespec > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. The take away from this discussion is that we are not interested in implementing the Linux adjtimex() here. Which I agree with. I will go back with my initial proposal of a timespec add/subtract syscall takes a timespec as input increments or decrements the clock by the timespec and returns a timespec with the time. That enables the ntp developers to add or subtract time and compare it with what ntp thinks it should be. Their idea is to have a loop feeding deltas to the syscall and comparing the output with their expectation. This is certainly less disruptive and IMO more maintainable than their desired solution. I have had code for the other more simpler separate new syscall option in my git repo for about a week. This was rejected because the desire was for FreeBSD to implement adjtimex(). I could submit the simpler separate unrelated to ntp_adjtime() syscall as a phabricator review or post it here if people prefer that instead. The code hasn't been tested. IMO the important consideration isn't Linux compatibility but being atomic (reduction of syscalls from two to one). Once through the review process I can take it back to the nwtime folks. I'm sure they'd be happier with this over nothing. Thoughts? -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Thu Dec 3 22:04:35 2020 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 013564B1083 for ; Thu, 3 Dec 2020 22:04:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cn8y95t0mz4q6R for ; Thu, 3 Dec 2020 22:04:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0B3M4IBa003973 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 4 Dec 2020 00:04:21 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0B3M4IBa003973 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0B3M4HfK003972; Fri, 4 Dec 2020 00:04:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Dec 2020 00:04:17 +0200 From: Konstantin Belousov To: Poul-Henning Kamp Cc: Cy Schubert , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() Message-ID: References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <60532.1606990671@critter.freebsd.dk> <60612.1606991186@critter.freebsd.dk> <202012031717.0B3HHalx003916@slippy.cwsent.com> <25218.1607026527@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25218.1607026527@critter.freebsd.dk> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4Cn8y95t0mz4q6R X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-1.10 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_SHORT(0.90)[0.903]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 22:04:35 -0000 On Thu, Dec 03, 2020 at 08:15:27PM +0000, Poul-Henning Kamp wrote: So regardless of the outcome of the ADJ_SETOFFSET discussion. As I noted earlier, compat32 for ntp_adjtime(2) is provided but is completely broken. Fixing it in usual manner means adding kern_ntp_adjtime(9) KPI, and using it in compat shims. The same restructuring would be needed before new ntp_adjtime() can be implemented, if it ever be. So I went ahead with kern_ntp_adjtime(9) and compat32, I added the participants of this thread as reviewers. https://reviews.freebsd.org/D27471 From owner-freebsd-arch@freebsd.org Thu Dec 3 22:07:42 2020 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 8693A4B0FB2 for ; Thu, 3 Dec 2020 22:07:42 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cn91n6XWQz4qQl; Thu, 3 Dec 2020 22:07:41 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 2B7EA8A57A; Thu, 3 Dec 2020 22:07:40 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 0B3M7doe025924 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Dec 2020 22:07:39 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 0B3M7dAO025923; Thu, 3 Dec 2020 22:07:39 GMT (envelope-from phk) To: Ian Lepore cc: freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() In-reply-to: From: "Poul-Henning Kamp" References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <4086.1606982335@critter.freebsd.dk> <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> <25487.1607029223@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25921.1607033259.1@critter.freebsd.dk> Date: Thu, 03 Dec 2020 22:07:39 +0000 Message-ID: <25922.1607033259@critter.freebsd.dk> X-Rspamd-Queue-Id: 4Cn91n6XWQz4qQl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[130.225.244.222:from]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[130.225.244.222:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 22:07:42 -0000 -------- Ian Lepore writes: > As usual, all those arguments make good sense in a pristine academic > world, and no sense at all in [...] Yeah, right because I have clearly been embedded in a "pristine academic world" for the last 30 years. Did you happen to see my tenure lying around anywhere ? I suggest you actually read what I wrote, rather than what you thought I would write... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Thu Dec 3 22:13:37 2020 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 EA8064B1318 for ; Thu, 3 Dec 2020 22:13:37 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cn98d2Pbxz4qSJ; Thu, 3 Dec 2020 22:13:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 4374F8A577; Thu, 3 Dec 2020 22:13:35 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 0B3MDZ5Y025991 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 3 Dec 2020 22:13:35 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 0B3MDYDE025990; Thu, 3 Dec 2020 22:13:34 GMT (envelope-from phk) To: Cy Schubert cc: Ian Lepore , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() In-reply-to: <202012032203.0B3M3VJx004269@slippy.cwsent.com> From: "Poul-Henning Kamp" References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <4086.1606982335@critter.freebsd.dk> <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> <25487.1607029223@critter.freebsd.dk> <202012032203.0B3M3VJx004269@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25988.1607033614.1@critter.freebsd.dk> Date: Thu, 03 Dec 2020 22:13:34 +0000 Message-ID: <25989.1607033614@critter.freebsd.dk> X-Rspamd-Queue-Id: 4Cn98d2Pbxz4qSJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RBL_DBL_DONT_QUERY_IPS(0.00)[130.225.244.222:from]; SPAMHAUS_ZRD(0.00)[130.225.244.222:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 22:13:38 -0000 -------- Cy Schubert writes: > I will go back > with my initial proposal of a timespec add/subtract syscall takes a > timespec as input increments or decrements the clock by the timespec and > returns a timespec with the time. I would be tempted by the clock_settime(2) "clock_id" argument. The functionality required has a LOT more commonality with clock_settime(2) than with ntp_adjtime(2), and absconding with a couple of the top bits of clock_id for "CLOCK_ADD_ADJUSTMENT" and "CLOCK_SUB_ADJUSTMENT" would be be a pretty clean solution. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Thu Dec 3 22:41:15 2020 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 AC9374B1C0F for ; Thu, 3 Dec 2020 22:41:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cn9mW24Zjz4rx0; Thu, 3 Dec 2020 22:41:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0B3Mf3Yh013432 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 4 Dec 2020 00:41:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0B3Mf3Yh013432 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0B3Mf3FT013431; Fri, 4 Dec 2020 00:41:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Dec 2020 00:41:03 +0200 From: Konstantin Belousov To: Poul-Henning Kamp Cc: Cy Schubert , Ian Lepore , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() Message-ID: References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <4086.1606982335@critter.freebsd.dk> <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> <25487.1607029223@critter.freebsd.dk> <202012032203.0B3M3VJx004269@slippy.cwsent.com> <25989.1607033614@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25989.1607033614@critter.freebsd.dk> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4Cn9mW24Zjz4rx0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 22:41:15 -0000 On Thu, Dec 03, 2020 at 10:13:34PM +0000, Poul-Henning Kamp wrote: > -------- > Cy Schubert writes: > > > I will go back > > with my initial proposal of a timespec add/subtract syscall takes a > > timespec as input increments or decrements the clock by the timespec and > > returns a timespec with the time. > > I would be tempted by the clock_settime(2) "clock_id" argument. > > The functionality required has a LOT more commonality with > clock_settime(2) than with ntp_adjtime(2), and absconding with a > couple of the top bits of clock_id for "CLOCK_ADD_ADJUSTMENT" and > "CLOCK_SUB_ADJUSTMENT" would be be a pretty clean solution. The adjustments are only applicable to CLOCK_REALTIME, am I wrong ? If only CLOCK_REALTIME is affected (or even if things like CLOCK_MONOTONIC get parallel adjustment), it makes more sense to allocate designated clock ids like CLOCK_BSD_ADD_ADJ instead of carving bits in id numbers. I mean, we do not need/want to adjust CLOCK_VIRTUAL, CLOCK_PROF and other non-wall clock related clocks. From owner-freebsd-arch@freebsd.org Thu Dec 3 22:58:57 2020 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 916844B2421 for ; Thu, 3 Dec 2020 22:58:57 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CnB8x2947z4tNf; Thu, 3 Dec 2020 22:58:57 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.229.168]) by shaw.ca with ESMTPA id kxYrkbGSu34axkxYskkj6v; Thu, 03 Dec 2020 15:58:55 -0700 X-Authority-Analysis: v=2.4 cv=LvQsdlRc c=1 sm=1 tr=0 ts=5fc96daf a=7AlCcx2GqMg+lh9P3BclKA==:117 a=7AlCcx2GqMg+lh9P3BclKA==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=zTNgK-yGK50A:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=f2my8MzjlE3kG2gwEJYA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id DE7E3347; Thu, 3 Dec 2020 14:58:52 -0800 (PST) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 0B3MwqVQ004875; Thu, 3 Dec 2020 14:58:52 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202012032258.0B3MwqVQ004875@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "Poul-Henning Kamp" cc: Cy Schubert , Ian Lepore , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() In-reply-to: <25989.1607033614@critter.freebsd.dk> References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <4086.1606982335@critter.freebsd.dk> <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> <25487.1607029223@critter.freebsd.dk> <202012032203.0B3M3VJx004269@slippy.cwsent.com> <25989.1607033614@critter.freebsd.dk> Comments: In-reply-to "Poul-Henning Kamp" message dated "Thu, 03 Dec 2020 22:13:34 +0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Dec 2020 14:58:52 -0800 X-CMAE-Envelope: MS4xfCBhLNXhuoPXbqSLavopQoETYYKXD0oPneb2s2R3DY9Vxc+Wu8hongphBUXsJ5eI/t3+YvKEFbjEB0EzCWib/JkyNmVns5ZbUQzLjKY3cMe+x9N4r1N5 yKngxFEEZK5E2m2bEWeKn53z9HW2mEF5+lfnB0o7eII89RAGDf87CPbhzXack+OiKREY6UKMPbQmOsUobwW+Z3mNr7L43xgRdeuprGV/7MB3MAvLZsPldKWY ZL/YFCL+AADsmQYkx0St9GFA2sUusKEaR+O/Ph3DmpQ= X-Rspamd-Queue-Id: 4CnB8x2947z4tNf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 22:58:57 -0000 In message <25989.1607033614@critter.freebsd.dk>, "Poul-Henning Kamp" writes: > -------- > Cy Schubert writes: > > > I will go back > > with my initial proposal of a timespec add/subtract syscall takes a > > timespec as input increments or decrements the clock by the timespec and > > returns a timespec with the time. > > I would be tempted by the clock_settime(2) "clock_id" argument. > > The functionality required has a LOT more commonality with > clock_settime(2) than with ntp_adjtime(2), and absconding with a > couple of the top bits of clock_id for "CLOCK_ADD_ADJUSTMENT" and > "CLOCK_SUB_ADJUSTMENT" would be be a pretty clean solution. Correct. My initial proposal was: +.Fn clock_updtime "clockid_t clock_id" "const struct timespec *itp" "struct timespec *otp" Briefly it does this: +int +kern_clock_updtime(struct thread *td, clockid_t clock_id, + const struct timespec *its, struct timespec *ots) +{ + struct timespec ats; + int error; + + if ((error = kern_clock_gettime(td, clock_id, &ats)) != 0) + return (error); + + timespecadd(its, &ats, &ats); + + if ((error = kern_clock_settime(td, clock_id, &ats)) != 0) + return (error); + + return(kern_clock_gettime(td, clock_id, ots)); +} I can prepare a review if you want. I haven't touched the man page nor any tests yet. It's affected by kib@'s https://reviews.freebsd.org/D27471, as conflicts will result. I'll wait until that's committed before continuing work on it, assuming this is the direction we want to go. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Thu Dec 3 23:57:47 2020 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 4BA734B3EA0 for ; Thu, 3 Dec 2020 23:57:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CnCSp3bq9z3DW0; Thu, 3 Dec 2020 23:57:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0B3NvZj4031168 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 4 Dec 2020 01:57:38 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0B3NvZj4031168 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0B3NvYUa031167; Fri, 4 Dec 2020 01:57:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Dec 2020 01:57:34 +0200 From: Konstantin Belousov To: Cy Schubert Cc: Poul-Henning Kamp , Ian Lepore , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() Message-ID: References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <4086.1606982335@critter.freebsd.dk> <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> <25487.1607029223@critter.freebsd.dk> <202012032203.0B3M3VJx004269@slippy.cwsent.com> <25989.1607033614@critter.freebsd.dk> <202012032258.0B3MwqVQ004875@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202012032258.0B3MwqVQ004875@slippy.cwsent.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4CnCSp3bq9z3DW0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; TO_DN_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arch]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 23:57:47 -0000 On Thu, Dec 03, 2020 at 02:58:52PM -0800, Cy Schubert wrote: > In message <25989.1607033614@critter.freebsd.dk>, "Poul-Henning Kamp" > writes: > > -------- > > Cy Schubert writes: > > > > > I will go back > > > with my initial proposal of a timespec add/subtract syscall takes a > > > timespec as input increments or decrements the clock by the timespec and > > > returns a timespec with the time. > > > > I would be tempted by the clock_settime(2) "clock_id" argument. > > > > The functionality required has a LOT more commonality with > > clock_settime(2) than with ntp_adjtime(2), and absconding with a > > couple of the top bits of clock_id for "CLOCK_ADD_ADJUSTMENT" and > > "CLOCK_SUB_ADJUSTMENT" would be be a pretty clean solution. > > Correct. My initial proposal was: > > +.Fn clock_updtime "clockid_t clock_id" "const struct timespec *itp" > "struct timespec *otp" > > Briefly it does this: > > +int > +kern_clock_updtime(struct thread *td, clockid_t clock_id, > + const struct timespec *its, struct timespec *ots) Note that phk suggested using specific clock id with clock_settime(), and I believe that you only need one such clock id. > +{ > + struct timespec ats; > + int error; > + > + if ((error = kern_clock_gettime(td, clock_id, &ats)) != 0) > + return (error); > + > + timespecadd(its, &ats, &ats); > + > + if ((error = kern_clock_settime(td, clock_id, &ats)) != 0) > + return (error); > + > + return(kern_clock_gettime(td, clock_id, ots)); > +} This is awful, it must not be done this way. Look how tc_setclock() is implemented. It is careful to adjust time with interrupts and preemption disabled, and does it by adjusting the source of truth, not by fetching through several layers and then hoping that we did not get delayed too much when pushing back. I think you need to refactor tc_setclock() somewhat to allow to specify offset instead of absolute value and use it as a helper. > > I can prepare a review if you want. I haven't touched the man page nor any > tests yet. > > It's affected by kib@'s https://reviews.freebsd.org/D27471, as conflicts > will result. I'll wait until that's committed before continuing work on it, > assuming this is the direction we want to go. This change does not affect *setclock() work above. From owner-freebsd-arch@freebsd.org Fri Dec 4 01:15:03 2020 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 7879F4B64FD for ; Fri, 4 Dec 2020 01:15:03 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CnF9z1SlWz3K7s; Fri, 4 Dec 2020 01:15:02 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.229.168]) by shaw.ca with ESMTPA id kzgYkcD9V34axkzgZklKK6; Thu, 03 Dec 2020 18:15:01 -0700 X-Authority-Analysis: v=2.4 cv=LvQsdlRc c=1 sm=1 tr=0 ts=5fc98d95 a=7AlCcx2GqMg+lh9P3BclKA==:117 a=7AlCcx2GqMg+lh9P3BclKA==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=zTNgK-yGK50A:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=lFeFz6sgvLeF_G4I0u4A:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 5D52B51C; Thu, 3 Dec 2020 17:14:57 -0800 (PST) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 0B41EuFc006408; Thu, 3 Dec 2020 17:14:56 -0800 (PST) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202012040114.0B41EuFc006408@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Konstantin Belousov cc: Cy Schubert , Poul-Henning Kamp , Ian Lepore , freebsd-arch@freebsd.org Subject: Re: struct timex and Linux adjtimex() In-reply-to: References: <202012030523.0B35NsG7003810@slippy.cwsent.com> <4086.1606982335@critter.freebsd.dk> <5e0db735b29f1ece02521871b2cd392c3467101d.camel@freebsd.org> <25487.1607029223@critter.freebsd.dk> <202012032203.0B3M3VJx004269@slippy.cwsent.com> <25989.1607033614@critter.freebsd.dk> <202012032258.0B3MwqVQ004875@slippy.cwsent.com> Comments: In-reply-to Konstantin Belousov message dated "Fri, 04 Dec 2020 01:57:34 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Dec 2020 17:14:56 -0800 X-CMAE-Envelope: MS4xfBkY4PuU928JSyIwgz51EpD+XGTsLre6UtcOwC3HUmtuVCMCqX6g8P1uwhIoI2nepC0nZO6kCZTZ6j8RVewLsHhK3SZqIONPyo5empV2Ms7c6esn90eK T74Gwd4f8jUHUy3IDggPfrDZTEytCqsftZkHCCobBWmc5kEyAsGQukc2oeEWJfhFPBPxVZXsL9oquaDg2pQpNqDXYtafgRBEalqP3Zyw8qi9Dk8mPtXFimD0 SLgwVIOtweOa94jKdYTDptC1XYZEpNizsTkgJCLecvdpllfDSOaDov6zvzWvvFEu X-Rspamd-Queue-Id: 4CnF9z1SlWz3K7s X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 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 Dec 2020 01:15:03 -0000 In message , Konstantin Belousov writes: > On Thu, Dec 03, 2020 at 02:58:52PM -0800, Cy Schubert wrote: > > In message <25989.1607033614@critter.freebsd.dk>, "Poul-Henning Kamp" > > writes: > > > -------- > > > Cy Schubert writes: > > > > > > > I will go back > > > > with my initial proposal of a timespec add/subtract syscall takes a > > > > timespec as input increments or decrements the clock by the timespec an > d > > > > returns a timespec with the time. > > > > > > I would be tempted by the clock_settime(2) "clock_id" argument. > > > > > > The functionality required has a LOT more commonality with > > > clock_settime(2) than with ntp_adjtime(2), and absconding with a > > > couple of the top bits of clock_id for "CLOCK_ADD_ADJUSTMENT" and > > > "CLOCK_SUB_ADJUSTMENT" would be be a pretty clean solution. > > > > Correct. My initial proposal was: > > > > +.Fn clock_updtime "clockid_t clock_id" "const struct timespec *itp" > > "struct timespec *otp" > > > > Briefly it does this: > > > > +int > > +kern_clock_updtime(struct thread *td, clockid_t clock_id, > > + const struct timespec *its, struct timespec *ots) > Note that phk suggested using specific clock id with clock_settime(), > and I believe that you only need one such clock id. Correct. This is from work I stashed in my git repo from Sunday. I haven't updated it yet with phk's suggestions. > > > +{ > > + struct timespec ats; > > + int error; > > + > > + if ((error = kern_clock_gettime(td, clock_id, &ats)) != 0) > > + return (error); > > + > > + timespecadd(its, &ats, &ats); > > + > > + if ((error = kern_clock_settime(td, clock_id, &ats)) != 0) > > + return (error); > > + > > + return(kern_clock_gettime(td, clock_id, ots)); > > +} > This is awful, it must not be done this way. > > Look how tc_setclock() is implemented. It is careful to adjust time > with interrupts and preemption disabled, and does it by adjusting the > source of truth, not by fetching through several layers and then hoping > that we did not get delayed too much when pushing back. Thanks. I'll look there. > > I think you need to refactor tc_setclock() somewhat to allow to specify > offset instead of absolute value and use it as a helper. I'll do that. I'll add phk and you as reviewers. > > > > > I can prepare a review if you want. I haven't touched the man page nor any > > tests yet. > > > > It's affected by kib@'s https://reviews.freebsd.org/D27471, as conflicts > > will result. I'll wait until that's committed before continuing work on it, > > > assuming this is the direction we want to go. > This change does not affect *setclock() work above. Thanks. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few.