> On Oct 14, 2016, at 9:50 AM, Andriy Gapon <a...@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.


freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to