finishing the if.h/if_var.h split

[John Baldwin]

On 30-Sep-2003 Bruce Evans wrote:
> On Tue, 30 Sep 2003, John Baldwin wrote:
> 
>> On 30-Sep-2003 Bruce Evans wrote:
>> > On Mon, 29 Sep 2003, Brooks Davis wrote:
>> >> Unfortunately, "soon" hasn't happened yet and it is now tripping me
>> >> up.  To add the if_dev member to struct ifnet (see the forthcoming
>> >> post on that subject), it is necessary for sys/bus.h to be included in
>> >> net/if_var.h
>> >
>> > That would be namespace pollution, so it is not permitted :-).  Requiring
>> > all files that include <sys/if_var.h> (and especially <sys/if.h> to
>> > include <sys/bus.h> would be interface breakage so it is even less
>> > permitted.
>>
>> Well, if if.h stops including if_var.h, then only kernel files that
>> include net/if_var.h would need sys/bus.h.  I think that's manageable.
> 
> All userland files that include net/if_var.h would also need it (except
> they would only need device_t).

Is struct ifnet exposed to userland?  Ugh, why do we export such things?
I guess because ifconfig grovels around in the kernel due to a lack of
APIs between the kernel and userland.  *sigh*

>> >> which in turn requires that if_var.h NOT be included in
>> >> genassym.c.
>> >
>> > Do you mean in userland?  There don't seem to be any immediate problems
>> > for genassym.c or any other file in the kernel from including <sys/bus.h>
>> > unconditionally in <net/if_var.h>.  However, the pollution may be harmful
>> ...
>> The problem is that the newbus foo_if.h files don't exist when genassym
>> is compiled and used.  sys/bus.h needs bus_if.h and device_if.h, hence
>> the breakage.
> 
> I see.  This is a bug in the dependencies for genassym.o and .depend.
> "make depend" creates *_if.h but it also creates genassym.o.  There aren't
> enough dependencies so the order is mostly accidental.  genassym.o happens
> to get created first, so it doesn't compile unless *_if.h already exist.

I think that genassym shouldn't need anything that includes *_if.h
headers, and that if we find ourselves in that situation, perhaps some
huge header needs to be split up instead. :)  We shouldn't be going
near new-bus or kobj in assembly files.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/