From nobody Mon Nov 03 02:01:08 2025 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4d0FDk0ckpz6G43Y; Mon, 03 Nov 2025 02:01:10 +0000 (UTC) (envelope-from jfree@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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4d0FDj73fcz4N8y; Mon, 03 Nov 2025 02:01:09 +0000 (UTC) (envelope-from jfree@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762135270; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xQNZXf6iP1J6XAaY83swkeIKJ2S64XCmYBLiBUjkCQQ=; b=u3NKLuS2kxh6RmCFeUokNDa2dZ5IZCscwE1eDnDKF14ipf0LAq/f6tTUX7Ezl8nkmVMgQA +mLObaMY3/hJStYpNk5Wh66JgxE6rIeglx56b4YrwLvSeWGQ+2IeiaX52zXPXVLE5xNWBn 0NTBc5YMQi+PzDJgi1+07wKBn9HQM/GNol3cXjCsMIohNgLb2zk2eBmuMsL/resQlhUeRw CF3yqHL4OSmmeEX6haH1SfXQoZ/g7lASEh2rwGv3OjqKib6xz2FjuTK6exgpQw8Rwsaurh AjZYDopSbc0161cJY92Gvf9TFtBbTX/QY5L+rdW4NvDxAG4Zs8QBdZfEOEoNcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1762135270; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xQNZXf6iP1J6XAaY83swkeIKJ2S64XCmYBLiBUjkCQQ=; b=qsIdPU4a3x4YMtO1FH1WhMrd5MDDWPaVek1wL6uRuUqJcLTbEq5fxwwy3khG1gyINFsBgo zFJ5FhJewR4uKtu0Tc9+/gyAVYs7tHkxEYSXoI4ykRxmPWFE1AU3R2oEtDdLdUh4DWS093 vuUTzqTNXRIWl2ouVUieGDenAQBXOBxqe9ALf3wW3EqUG6LX/142PvsvmZL2M3mnw3JLdH EGKtA/mRQtwkieJSZCDYDav88XAGEegpO3HpyCzFrYyVTY51zqfUNtANYcGFm0W3RvdHdj 6SYNnh/nK8hJwKbS19YhgXlooZVqrQQNC2ebFL3wdo/vUyJ7x2PUNbf0Lj/FRw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1762135270; a=rsa-sha256; cv=none; b=Hvfx4QMJ79TXrUAukkRazOs0vgbFtyfnVDJ3AE7XN3VC9FpwQvOaQdhrsvC592E5B37nJl eXL7bAwU3pIkBPCYqWC3+QPYjvIjevJNnnD5nuk/escEDUm/jGPZ/BO2HQCiKPU9oEx3gz gx42YzbG7/PQIehqW7YqT+2t86dVY58tBQHuJ0Pt28mrYNFBGBNfUiHxseKgzOUFD0/5Z3 c/jHIpxLaMXSYjg8XyDMcqBgh1fWa44TBVbMXvG7oEULv65PLq3JzmhJyJ6TrXsyFd0WU4 viiUVwTCefuEIc8tC0xDlj71R/o1ehlteBocydSVxB6Gwlbmp5z4t7+gDr4+8Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from localhost (67-4-144-106.mpls.qwest.net [67.4.144.106]) (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 did not present a certificate) (Authenticated sender: jfree) by smtp.freebsd.org (Postfix) with ESMTPSA id 4d0FDj59Kqzqmc; Mon, 03 Nov 2025 02:01:09 +0000 (UTC) (envelope-from jfree@freebsd.org) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sun, 02 Nov 2025 20:01:08 -0600 Message-Id: From: "Jake Freeland" To: "John Baldwin" , "Warner Losh" , , , Subject: Re: git: 9404c479946c - main - pci_user: Report NUMA domain X-Mailer: aerc 0.20.1 References: <202509040245.5842jXvV085511@gitrepo.freebsd.org> In-Reply-To: > For future reference: you didn't need to bump to a new number for the ioc= tl > since the size of the argument is encoded in the ioctl as well. This > feature of ioctls also means that we generally don't add padding (as you = did > in the followup commit) as you will naturally get a new ioctl cmd value > anytime you add more fields in the future. This avoids the one point War= ner > raised in the review about how do you define the semantics of the padding > as that approach defers reserving space in the structure until the semant= ics > of that space is known. Hey John, I just took another look at this and understand your point about not needing to bump the ioctl number, but am struggling to see why that would remove the need for padding. The point of the padding was to minimize the in-kernel churn needed when adding new members to struct pci_conf. Without it, adding a new member means we need to account for the old ioctl (with the old length) in every switch statement in pci_user.c and there are a lot. The only solution I can think of to get around this is to switch on the IOCGROUP of every command and copy out IOCPARM_LEN number of bytes. Then modifying pci_conf wouldn't require an additional case for every switch statement. There may be a reason, that I'm not aware of, for why we don't already do this. Perhaps this is what you were thinking? Thanks, Jake Freeland