From owner-svn-src-all@FreeBSD.ORG Fri Jun 20 14:45:47 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EF95984; Fri, 20 Jun 2014 14:45:47 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 381DE2878; Fri, 20 Jun 2014 14:45:46 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.232.70]) (authenticated bits=0) by vps1.elischer.org (8.14.8/8.14.8) with ESMTP id s5KEjdaU079707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 20 Jun 2014 07:45:44 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53A4490E.6070107@freebsd.org> Date: Fri, 20 Jun 2014 22:45:34 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Konstantin Belousov , Attilio Rao Subject: Re: svn commit: r267651 - in head: share/man/man4 sys/dev/cpuctl sys/sys usr.sbin/cpucontrol References: <201406192154.s5JLsfed074305@svn.freebsd.org> <20140620040801.GA3991@kib.kiev.ua> <20140620074939.GE3991@kib.kiev.ua> In-Reply-To: <20140620074939.GE3991@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 14:45:47 -0000 On 6/20/14, 3:49 PM, Konstantin Belousov wrote: > On Fri, Jun 20, 2014 at 08:12:59AM +0200, Attilio Rao wrote: >> On Fri, Jun 20, 2014 at 6:08 AM, Konstantin Belousov >> wrote: >>> On Thu, Jun 19, 2014 at 09:54:41PM +0000, Attilio Rao wrote: >>>> Author: attilio >>>> Date: Thu Jun 19 21:54:41 2014 >>>> New Revision: 267651 >>>> URL: http://svnweb.freebsd.org/changeset/base/267651 >>>> >>>> Log: >>>> Following comments in r242565 add the possibility to specify ecx when >>>> performing cpuid calls. >>>> Add also a new way to specify the level type to cpucontrol(8) as >>>> reported in the manpage. >>>> >>>> Sponsored by: EMC / Isilon storage division >>>> Reviewed by: bdrewery, gcooper >>>> Testerd by: bdrewery >>>> Modified: head/sys/sys/cpuctl.h >>>> ============================================================================== >>>> --- head/sys/sys/cpuctl.h Thu Jun 19 21:05:07 2014 (r267650) >>>> +++ head/sys/sys/cpuctl.h Thu Jun 19 21:54:41 2014 (r267651) >>>> @@ -35,7 +35,8 @@ typedef struct { >>>> } cpuctl_msr_args_t; >>>> >>>> typedef struct { >>>> - int level; /* CPUID level */ >>>> + int level; /* CPUID level */ >>>> + int level_type; /* CPUID level type */ >>>> uint32_t data[4]; >>>> } cpuctl_cpuid_args_t; >>>> >>>> @@ -50,5 +51,6 @@ typedef struct { >>>> #define CPUCTL_UPDATE _IOWR('c', 4, cpuctl_update_args_t) >>>> #define CPUCTL_MSRSBIT _IOWR('c', 5, cpuctl_msr_args_t) >>>> #define CPUCTL_MSRCBIT _IOWR('c', 6, cpuctl_msr_args_t) >>>> +#define CPUCTL_CPUID_COUNT _IOWR('c', 7, cpuctl_cpuid_args_t) >>>> >>>> #endif /* _CPUCTL_H_ */ >>> The cpuctl(4) is used by third-party code, and this change breaks its >>> ABI. The numeric value for CPUCTL_CPUID is changed, which means that >>> old binaries call non-existing ioctl now. This is at least a visible >>> breakage, since the argument for the ioctl changed the layout as well. >>> >>> The following patch restored the CPUCTL_CPUID for me. I considered >>> naming its argument differently, instead of renaming the argument >>> of CPUCTL_CPUID_COUNT (which you tried to do ?), but decided not, >>> to preserve the API as well. >> No, breaking the ABI is fine for -CURRENT so I don't see why we need the bloat. > No, breaking ABI is not fine at all, be it CURRENT or not. We try to > keep the ABI stable, doing costly measures like symbol versioning, where > applicable. Since this is a change to ABI for kernel interface, it > cannot be covered by symver tricks and must be done in kernel. > >> I don't plan on MFC this patch. If I need to (or any user requests >> that) I will do with the appropriate ABI-compliant way (ie. adding a >> new argument like this one). > Besides the same-world ABI issue, people run jails with lower world > version on higher-versioned kernels. exactly.. breaking this would be a big departure from our normal procedure. The basic question to ask yourself is can I run a FreeBSD 4.4 jail with this? For kmods it's probably a little less strict.. I'd like it to be "Can I still load a FreeBSD 7 kernel module" but I doubt we've been that careful.