Date: Fri, 14 Oct 2016 10:51:46 -0500 From: Lewis Donzis <lew@perftech.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, "freebsd-arch@freebsd.org" <freebsd-arch@FreeBSD.org> Subject: Re: SM bus ioctls incorrect in FreeBSD 11 Message-ID: <1AA2BB21-0D6D-42F4-9CB2-3CBB00F389C6@perftech.com> In-Reply-To: <fe780e23-f014-1c84-b702-12727cd68ef0@FreeBSD.org> References: <06929AC5-D350-4236-A813-56C862B58174@perftech.com> <fe780e23-f014-1c84-b702-12727cd68ef0@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Oct 14, 2016, at 9:50 AM, Andriy Gapon <avg@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1AA2BB21-0D6D-42F4-9CB2-3CBB00F389C6>