From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E1E5B416D06 for ; Mon, 29 Jun 2026 15:23:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782746632; cv=none; b=hbEJ5dAcIcdQ1CISIECb3FcsBBz57f5biR72+yEjnqtVgGOt/T1UeCBMQP7EzeFehT22n64/WYxHbMh9EGtFtAXbBafY2ZeziRnrUtOytMkUqSB/NACBkUjMbVG44xktS41TBdv9K2rV6OLBPChdXnmUdDWjMUVkn43bJd5AfTc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782746632; c=relaxed/simple; bh=vyLVdEMCvlWCx4NZj6dizp21HiTAPuh9a8BPbFmS0ao=; h=Date:From:To:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=ghE2AQdV4emnW6zwmtgOTryEM3X9ZYD+gyohj8zBaJ/gc9CeSmRnQX/ACsYxJDInxOuoYHk8HjQK/s/nuwGw6e3IdMXI1iY2BOpzLb3GQy/kD7ak8uLw7rB2vAXRpkMMrl1GnJiWwxyamwaGJmsiLm4ioJ8C5W6VGTRwkeYd7Vc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=m0+Amy1y; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="m0+Amy1y" Received: from ehlo.thunderbird.net (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 65TFNR0I516225 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 29 Jun 2026 08:23:28 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 65TFNR0I516225 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026062701; t=1782746608; bh=inKJ7vPsCtODT/n4J+R1YneMABVow/4Fxs88Ryz/3T4=; h=Date:From:To:Subject:In-Reply-To:References:From; b=m0+Amy1yWiozvSw7erKhP8b92F6Lxp42bM4Yjb2/D7NNpDwYA+/IMmCu7sqvY+ZOS PlEb/nMMzjDm5gpMbvuD4ZGcmafWM3VJYbkgHTQTKKIHy+YYyPfE3vjCu7+drvOnEG xCdKKF7R1gwoL2RMqq4PNomAYgDvxuAt82gNC7Wdrhlp++B5Ye0n0YbR5fIApkICGH XzRIYkMqzwo+bt1pHj63VWbQgaFDyYUDmdjDbndfhnJdc97LCpMGbyR3xZzD38mX1T vEzwVtcfFUKtyYgx8KvJ6piaxo7qI8AYZt+yAp53eHYWmyxDX+JX1wgR+vnlqTH+9F DudOl4kAjZ0yA== Date: Mon, 29 Jun 2026 08:23:21 -0700 From: "H. Peter Anvin" To: Tim Wiederhake , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, linux-kernel@vger.kernel.org Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v2_1/2=5D_x86/msr=3A_Document_I/O-l?= =?US-ASCII?Q?ike_MSR_semantics_in_/dev/cpu/*/msr_driver?= User-Agent: K-9 Mail for Android In-Reply-To: <759ad7207f201e9b81e1d4d9c5ba3d6375db44ec.camel@redhat.com> References: <20260626174037.1128563-1-twiederh@redhat.com> <20260626202323.1169433-2-twiederh@redhat.com> <03245373bd3912bb7421b93c383c9e07454aadd2.camel@redhat.com> <0239cda7-b638-44df-9739-746a7173a577@zytor.com> <759ad7207f201e9b81e1d4d9c5ba3d6375db44ec.camel@redhat.com> Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On June 29, 2026 8:14:12 AM PDT, Tim Wiederhake wro= te: >On Fri, 2026-06-26 at 14:42 -0700, H=2E Peter Anvin wrote: >> On 2026-06-26 13:33, Tim Wiederhake wrote: >> >=20 >> > This version splits the change in two: >> >=20 >> > =C2=A0 1/2 adds a comment explaining why the driver loops over the sa= me >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 register, so future readers don't have= to rediscover the >> > rationale=2E >> > =C2=A0 2/2 removes only the read loop, where repeated access to the s= ame >> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 register is less obviously useful=2E >> >=20 >> The same applies to the read loop, although the use case(s) are >> obviously >> different=2E >>=20 >> Either way, you risk breaking working tools for no reason=2E >>=20 >> -hpa >While looking into this I also noticed that /dev/cpu/*/msr is the only >register-addressed character device that doesn't advance ppos on read=2E >/dev/cpu/*/cpuid, /dev/port, and /dev/nvram do=2E That causes ftell() and >lseek(SEEK_CUR, 0) to disagree after an fread()=2E I don't know how >important that is though, and whether that is more of a glibc issue=2E > >Can you please point me to a tool that uses the multiple-read behavior? >I want to mention that in the file comment, but turbostat, rdmsr, >cpupower, coreboot's inteltool, all read exactly 8 bytes=2E > >Thanks for the review, >Tim > > /dev/ioport behave(d) that way as well, and was the model=2E=20 However, you are barking up the wrong tree here: when you want to change a= 25-year-old API for no technical reason =E2=80=94 your only argument raise= d has been aestetics =E2=80=94 then the burden of proof is on *you* that yo= u won't break anything=2E