svn commit: r299108 - head/sys/sys

[Julian Elischer]

On 5/05/2016 4:08 PM, Ngie Cooper (yaneurabeya) wrote:
>> On May 4, 2016, at 20:17, John Baldwin <jhb at freebsd.org> wrote:
>>
>> On Thursday, May 05, 2016 02:51:31 AM Garrett Cooper wrote:
>>> Author: ngie
>>> Date: Thu May  5 02:51:31 2016
>>> New Revision: 299108
>>> URL: https://svnweb.freebsd.org/changeset/base/299108
>>>
>>> Log:
>>>   Revert r299096
>>>
>>>   The change broke buildworld when building lib/libkvm
>>>
>>>   This change likely needs to be run through a ports -exp run as a sanity
>>>   check, as it might break downstream consumers.
>>>
>>>   Pointyhat to: adrian
>>>   Reported by: kargl (confirmed on $work workstation)
>>>   Sponsored by: EMC / Isilon Storage Division
>> 'struct foo *' can be use with a simple forward declare in headers without
>> requiring header pollution (and is often done for that reason).  device_t
>> should be used in any .c files, but headers might need to stick with
>> 'struct device *' in a few cases for that reason.  I suspect both of these
>> fall into that category.
> 	I agree based on the technical point (I didn’t dig into the why, but it makes sense), but this commit wasn’t even compile tested. I would rather figure out what the effects are before reintroducing the change.
> 	If this is being done to address compatibility issues with linuxkpi, I see two paths forward with this (there are probably more..):
> 	1. Convert everything over to device_t (which bde@ disagrees with), after doing a full tinderbox run and exp- run
> 	2. Localize the “shim”/typedef to linuxkpi so device_t is used there, or struct device* is used there.
> Thoughts?
> -Ngie
>
it seems a bit silly to change out code because there is symbol/type 
of the same name in Linux.
there must be some symbol munging possibility?