From owner-freebsd-arch@freebsd.org Fri Oct 14 15:53:18 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 972BCC1021F for ; Fri, 14 Oct 2016 15:53:18 +0000 (UTC) (envelope-from lew@perftech.com) Received: from smtp-gw.pt.net (smtp-gw.pt.net [206.210.194.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp-gw.pt.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 648B4F9E for ; Fri, 14 Oct 2016 15:53:18 +0000 (UTC) (envelope-from lew@perftech.com) X-ASG-Debug-ID: 1476460306-09411a4d54e70f0001-9koHHG Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by smtp-gw.pt.net with ESMTP id s28qEGlHKHnbI0nj (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Oct 2016 10:51:46 -0500 (CDT) X-Barracuda-Envelope-From: lew@perftech.com X-Barracuda-Effective-Source-IP: mail.pt.net[206.210.194.11] X-Barracuda-Apparent-Source-IP: 206.210.194.11 Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 93CC3841DA5; Fri, 14 Oct 2016 10:51:46 -0500 (CDT) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id sXjNM9tidETp; Fri, 14 Oct 2016 10:51:46 -0500 (CDT) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 58E06842566; Fri, 14 Oct 2016 10:51:46 -0500 (CDT) X-Virus-Scanned: amavisd-new at pt.net Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id rGGR-kYdDMhc; Fri, 14 Oct 2016 10:51:46 -0500 (CDT) Received: from dhcp-221-110.perftech.com (dhcp-221-110.perftech.com [206.210.221.110]) (Authenticated sender: lew@pt.net) by mail.pt.net (Postfix) with ESMTPSA id 3FCE4841DA5; Fri, 14 Oct 2016 10:51:46 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: SM bus ioctls incorrect in FreeBSD 11 From: Lewis Donzis X-ASG-Orig-Subj: Re: SM bus ioctls incorrect in FreeBSD 11 In-Reply-To: Date: Fri, 14 Oct 2016 10:51:46 -0500 Cc: freebsd-current@FreeBSD.org, "freebsd-arch@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1AA2BB21-0D6D-42F4-9CB2-3CBB00F389C6@perftech.com> References: <06929AC5-D350-4236-A813-56C862B58174@perftech.com> To: Andriy Gapon X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: mail.pt.net[206.210.194.11] X-Barracuda-Start-Time: 1476460306 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://smtp-gw.pt.net:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 2592 X-Virus-Scanned: by bsmtpd at pt.net X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.33713 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2016 15:53:18 -0000 > On Oct 14, 2016, at 9:50 AM, Andriy Gapon wrote: > Could you please open a bugzilla issue for the bug? > https://bugs.freebsd.org/bugzilla/ Sure, will do. I was unsure of the effectiveness of that, because I = filed a much more serious report about a different issue a couple of = weeks ago and have seen no activity or even acknowledgement. > The src change is described as "Expand SMBUS API ...", but in fact it = also > _changed_ the existing ioctls. And both binary compatibility and = programming > compatibility were broken because of how struct smbcmd was changed. > In FreeBSD we try to not do that without a very strong reason, but = alas. > And, as you report, the change was not done entirely correctly. I was also surprised, but it wasn=E2=80=99t really a big deal, and the = new structure might be slightly easier to use. There have been other = similar things in 11.0, like __mq_oshandle() disappearing, and more .so = files needing to be added to our embedded system, so all things = considered, it=E2=80=99s been reasonably smooth moving from 10.3 to = 11.0. > I see several possibilities now. >=20 > Option 1. Change the documentation to reflect the actual behavior. > In this case data.rdata will remain unusable and unused. No interface = changes. >=20 > Option 2. Redefine SMB_READB, SMB_READW and SMB_PCALL ioctls using = _IOWR, so > that data.rdata could be returned from kernel. This seems like a = proper fix, > but it is another binary level incompatibility. >=20 > Option 3. Use a horrible hack to discover a userland address of = smbcmd and > explicitly copyout to data.rdata. No interface incompatibilities, but = it will > be a horrible hack. Besides, not sure how feasible it is. >=20 > Option 4. Revert smb ioctl changes to what they used to be before = r281985. > Personally, I would prefer this approach. But now that the new = interface is in > 11.0, it means another interface change just like Option 2. >=20 > I would like to hear other developers' opinions about this situation. Our opinion doesn=E2=80=99t count for much, but I like 2 or 4. Option 1 = would essentially obviate the entire purpose of changing the structure. = Option 2 basically finishes the job and makes it work properly. Option = 3 is, as you say, unappealing. I have no problem with Option 4, = obviously we can change our code back to the old way, but assuming there = was a good reason for this change in the first place, Option 2 seems = more logical. But whatever y=E2=80=99all decide is fine with us, we=E2=80=99ll just = change code to match at the appropriate time. Thanks, lew