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>
index | next in thread | previous in thread | raw e-mail
> 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’t 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’s been reasonably smooth moving from 10.3 to 11.0. > I see several possibilities now. > > Option 1. Change the documentation to reflect the actual behavior. > In this case data.rdata will remain unusable and unused. No interface changes. > > 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. > > 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. > > 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. > > I would like to hear other developers' opinions about this situation. Our opinion doesn’t 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’all decide is fine with us, we’ll just change code to match at the appropriate time. Thanks, lewhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1AA2BB21-0D6D-42F4-9CB2-3CBB00F389C6>