Re: finishing the if.h/if_var.h split

From: John Baldwin (jhb_at_FreeBSD.org)
Date: 09/30/03

  • Next message: John Baldwin: "Re: adding if_dev member to struct ifnet"
    Date: Tue, 30 Sep 2003 13:14:34 -0400 (EDT)
    To: Bruce Evans <bde@zeta.org.au>
    
    

    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@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
    "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
    

  • Next message: John Baldwin: "Re: adding if_dev member to struct ifnet"

    Relevant Pages

    • Re: finishing the if.h/if_var.h split
      ... APIs between the kernel and userland. ... This is a bug in the dependencies for genassym.o and .depend. ... huge header needs to be split up instead. ...
      (freebsd-net)
    • Re: Attempted summary of "RT patch acceptance" thread
      ... tries to keep the userland API as close as possible to the non-RT one, ... by increasing the kernel complexity with relative slowdown. ... RTAI quickly becomes useless (ok it can run nanosleep with fusion fine, ... RTAI/rtlinux as the only hard-RT with guaranteed deadline. ...
      (Linux-Kernel)
    • Re: [RFC] Splitting kernel headers and deprecating __KERNEL__
      ... >> two parties on an ABI doesn't imply that one party gets to define it ... imposition, kernel developers won't care. ... because there's a contract with userland that they don't want to ... change in the copy/extract/whatever of kernel headers that userland is ...
      (Linux-Kernel)
    • Re: "Enhanced" MD code avaible for review
      ... be required to make this work correctly using a userland approach. ... > kernel, and having to try harder to crash the kernel. ... protected *sooner* if the system crashes. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Why is GForth-ITC fast?
      ... The kernel and the application code (so-called "userland") do not run ... That jump entails a "stack switch", ... the only thing is I guess if you want to do syscalls ...
      (comp.lang.forth)