On 5/05/2016 4:08 PM, Ngie Cooper (yaneurabeya) wrote:
On May 4, 2016, at 20:17, John Baldwin <j...@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?
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
