Re: problem building dev/e1000
On Sat, Feb 16, 2019 at 9:16 AM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > On Feb 15, 2019, at 11:47, Robert Huff wrote: > > > > > > Lev Serebryakov writes: > > > > > >>> My question would be: why? If some drivers have a new > > >>> dependency on iflib, why isn't that expressed in sys/conf/files > > >>> and handled automatically? > As expressed elsewhere that gets a bit messy when it is more than > just a few things that depend on this module, and historically > has been done by adding comments to GENERIC that describe the > dependency in the form of "requires iflib". > > Though there are some ideas floating around that might better > address this, for the time being that is how it is being handled. > > > >> My question exactly. > > > > > >I am so glad people who know what they're talking about have the > > > same response I did. :-) > > > > I totally missed the part where Robert said he was compiling it > > into the kernel. Also, I remember the days when drivers didn?t > > automatically compile in dependent options (example: ?device re? > > requires ?device miibus?). I guess things have changed a bit in > > the past year [while I was away] with some drivers? > > Thanks, > > -Enji > > >Respectcfully, > > >Robert Huff > > Nothing has changed, other than we now have another miibus > type thing called iflib and there are a half dozen drivers > that need to have iflib compiled in if you use them. What > is new is that these drivers already existed in the past, > but have been re-written to use iflib, so if your carrying > an old kernel config file around and update accross the > iflib'ification of that driver you have to pick up the > change that went into GENERIC that pulls in iflib. > That's always been true. We've never really had good support for invariant kernel config files on the branch that weren't derived from GENERIC in some way. Some recent branches have been better about this, but there's plenty of precedent in the past where changes like this have become required for this driver or that. > These are probably the types of changes that we should > consider not merging to something called stable/. > Generally, I tend to agree. However, apart from making the iflib standard, and impossible to remove, there's little that can be done in this case. We've made minor changes like this to kernel config files in the past, and merging this work would fall under that precedent. Not something to be done willy-nilly, but also not something to not do if the consequences of not doing it are worse than doing it. For our low end, already starting to feel the squeeze, being able to compile this out is a needful thing. config(8) sucks. Plain and simple. It's difficult to work on, doesn't express what it needs to, and is hard to transition away from. We are stuck with it for the life of the 12 branch (and like 13 and 14 too). It's easy to solve 80% of the problems with it, but hard to do so without introducing more problems that are much harder to paper-over. It needs to be taken out behind the woodshed and shot, but it does it job adequately enough that any replacement will have hard shoes to fill, especially since the number of weird, idiosyncratic edge cases config leans one way or the other have become expected and are actually the right thing to do. We also have enough velocity in the files, options and other files that trying to write a replacement and keep up is hard. tl;dr: config(8)'s unique quirks may force us to do things we'd rather not. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem building dev/e1000
> > > On Feb 15, 2019, at 11:47, Robert Huff wrote: > > > > Lev Serebryakov writes: > > > >>> My question would be: why? If some drivers have a new > >>> dependency on iflib, why isn't that expressed in sys/conf/files > >>> and handled automatically? As expressed elsewhere that gets a bit messy when it is more than just a few things that depend on this module, and historically has been done by adding comments to GENERIC that describe the dependency in the form of "requires iflib". Though there are some ideas floating around that might better address this, for the time being that is how it is being handled. > >> My question exactly. > > > >I am so glad people who know what they're talking about have the > > same response I did. :-) > > I totally missed the part where Robert said he was compiling it > into the kernel. Also, I remember the days when drivers didn?t > automatically compile in dependent options (example: ?device re? > requires ?device miibus?). I guess things have changed a bit in > the past year [while I was away] with some drivers? > Thanks, > -Enji > >Respectcfully, > >Robert Huff Nothing has changed, other than we now have another miibus type thing called iflib and there are a half dozen drivers that need to have iflib compiled in if you use them. What is new is that these drivers already existed in the past, but have been re-written to use iflib, so if your carrying an old kernel config file around and update accross the iflib'ification of that driver you have to pick up the change that went into GENERIC that pulls in iflib. These are probably the types of changes that we should consider not merging to something called stable/. -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem building dev/e1000
> On Feb 15, 2019, at 11:47, Robert Huff wrote: > > Lev Serebryakov writes: > >>> My question would be: why? If some drivers have a new >>> dependency on iflib, why isn't that expressed in sys/conf/files >>> and handled automatically? >> >> My question exactly. > >I am so glad people who know what they're talking about have the > same response I did. :-) I totally missed the part where Robert said he was compiling it into the kernel. Also, I remember the days when drivers didn’t automatically compile in dependent options (example: “device re” requires “device miibus”). I guess things have changed a bit in the past year [while I was away] with some drivers? Thanks, -Enji > >Respectcfully, > > >Robert Huff > > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem building dev/e1000
Am 15.02.19 um 21:28 schrieb Warner Losh: > On Fri, Feb 15, 2019 at 12:54 PM Ian Lepore wrote: > >> On Fri, 2019-02-15 at 12:32 -0700, Warner Losh wrote: >>> On Fri, Feb 15, 2019 at 12:17 PM Ian Lepore wrote: >> I guess the question would be how many things does '...' represent now >> and in the future? What it would need to be, given our current >> inflexible config(8) is >> >> net/iflib.c optional ether pci em | ether pci igb | ... >> >> So if ... is 2 or 3 more drivers, that's not so bad. If iflib is >> eventually going to be used by dozens of drivers, even the parens would >> make for a pretty ugly solution. > > Immediately, there's at least half a dozen. Count on there being a dozen or > two eventually. I had been thinking about a dependencies file for config, which either reports missing device/options lines, or adds obvious dependencies. This could also detect other missing pre-requisites, e.g. if inet or inet6 is to be compiled in, but no link-layer support (e.g. ether or wlan). The same applies to iflib for drivers that need it, miibus, CAM, ... The purpose of such a dependency check would be a clear indication of the missing definitions, especially if the dependencies have been changed as with iflib becoming non-standard. Open points: - How to generate these dependency files (could be derived from driver sources, e.g. an #include of some header might indicate that some "device xyz" is required). - Loadable kernel modules are an alternate method to provide a device driver or protocol (the dependency check could in such cases warn that a driver is not compiled in and will be required in form of a LKM). I have had a look at /sys/conf/files and have noticed that a number of lines contain bugs. E.g. there are network drivers that depend on "inet" and will not be compiled in if only "inet6" has been selected in the config file. Regards, STefan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem building dev/e1000
On Fri, Feb 15, 2019 at 12:54 PM Ian Lepore wrote: > On Fri, 2019-02-15 at 12:32 -0700, Warner Losh wrote: > > On Fri, Feb 15, 2019 at 12:17 PM Ian Lepore wrote: > > > > > On Fri, 2019-02-15 at 10:53 -0800, Enji Cooper wrote: > > > > > [...] > > > > > > > > HO Eric! > > > > > > > > iflib was a recently added requirement on stable/12 IIRC..? > > > > > > > > Does the manpage note this dependency, and is there an UPDATING > > > > entry > > > > for this change? > > > > > > > > Thanks! > > > > -Enji > > > > > > > > > > My question would be: why? If some drivers have a new dependency on > > > iflib, why isn't that expressed in sys/conf/files and handled > > > automatically? > > > > > > > Right now we have > > > > files:net/iflib.c optional ether pci iflib > > > > in the files file. This would need to change to > > > > files:net/iflib.c optional ether pci (em | igb | ...) > > > > but we don't have a () operator in config. Or we'd need dozens of > > lines, > > and the duplicate elimination code in config has been tricky (though > > I > > didn't check it just now). > > > > Warner > > > > I guess the question would be how many things does '...' represent now > and in the future? What it would need to be, given our current > inflexible config(8) is > > net/iflib.c optional ether pci em | ether pci igb | ... > > So if ... is 2 or 3 more drivers, that's not so bad. If iflib is > eventually going to be used by dozens of drivers, even the parens would > make for a pretty ugly solution. > Immediately, there's at least half a dozen. Count on there being a dozen or two eventually. MUST NOT RANT ABOUT CONFIG(8). Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem building dev/e1000
ifdi_if.h is a system generated interface file that network drivers that depend on iflib use. It's generated from ifdi_if.m in sys/net. My guess is that you don't have "device iflib" defined in your kernel configuration. em(4) depends on iflib in FreeBSD 12/13, and with r343617, iflib is now explicitly a module that needs to be included in your kernel config if you want to use a driver that depends on it. It's already in the GENERIC kernel for amd64; are you using a kernel config file that doesn't inherit from GENERIC? - Eric ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem building dev/e1000
On Fri, 2019-02-15 at 12:32 -0700, Warner Losh wrote: > On Fri, Feb 15, 2019 at 12:17 PM Ian Lepore wrote: > > > On Fri, 2019-02-15 at 10:53 -0800, Enji Cooper wrote: > > > > [...] > > > > > > HO Eric! > > > > > > iflib was a recently added requirement on stable/12 IIRC..? > > > > > > Does the manpage note this dependency, and is there an UPDATING > > > entry > > > for this change? > > > > > > Thanks! > > > -Enji > > > > > > > My question would be: why? If some drivers have a new dependency on > > iflib, why isn't that expressed in sys/conf/files and handled > > automatically? > > > > Right now we have > > files:net/iflib.c optional ether pci iflib > > in the files file. This would need to change to > > files:net/iflib.c optional ether pci (em | igb | ...) > > but we don't have a () operator in config. Or we'd need dozens of > lines, > and the duplicate elimination code in config has been tricky (though > I > didn't check it just now). > > Warner > I guess the question would be how many things does '...' represent now and in the future? What it would need to be, given our current inflexible config(8) is net/iflib.c optional ether pci em | ether pci igb | ... So if ... is 2 or 3 more drivers, that's not so bad. If iflib is eventually going to be used by dozens of drivers, even the parens would make for a pretty ugly solution. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem building dev/e1000
Lev Serebryakov writes: > > My question would be: why? If some drivers have a new > > dependency on iflib, why isn't that expressed in sys/conf/files > > and handled automatically? > > My question exactly. I am so glad people who know what they're talking about have the same response I did. :-) Respectcfully, Robert Huff ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem building dev/e1000
On Fri, Feb 15, 2019 at 12:17 PM Ian Lepore wrote: > On Fri, 2019-02-15 at 10:53 -0800, Enji Cooper wrote: > > > On Feb 15, 2019, at 10:46, Eric Joyner wrote: > > > > > > ifdi_if.h is a system generated interface file that network drivers > > > that depend on iflib use. It's generated from ifdi_if.m in sys/net. > > > > > > My guess is that you don't have "device iflib" defined in your > > > kernel configuration. em(4) depends on iflib in FreeBSD 12/13, and > > > with r343617, iflib is now explicitly a module that needs to be > > > included in your kernel config if you want to use a driver that > > > depends on it. It's already in the GENERIC kernel for amd64; are > > > you using a kernel config file that doesn't inherit from GENERIC? > > > > HO Eric! > > > > iflib was a recently added requirement on stable/12 IIRC..? > > > > Does the manpage note this dependency, and is there an UPDATING entry > > for this change? > > > > Thanks! > > -Enji > > > > My question would be: why? If some drivers have a new dependency on > iflib, why isn't that expressed in sys/conf/files and handled > automatically? > Right now we have files:net/iflib.c optional ether pci iflib in the files file. This would need to change to files:net/iflib.c optional ether pci (em | igb | ...) but we don't have a () operator in config. Or we'd need dozens of lines, and the duplicate elimination code in config has been tricky (though I didn't check it just now). Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem building dev/e1000
On 15.02.2019 21:59, Ian Lepore wrote: > My question would be: why? If some drivers have a new dependency on > iflib, why isn't that expressed in sys/conf/files and handled > automatically? My question exactly. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: problem building dev/e1000
On Fri, 2019-02-15 at 10:53 -0800, Enji Cooper wrote: > > On Feb 15, 2019, at 10:46, Eric Joyner wrote: > > > > ifdi_if.h is a system generated interface file that network drivers > > that depend on iflib use. It's generated from ifdi_if.m in sys/net. > > > > My guess is that you don't have "device iflib" defined in your > > kernel configuration. em(4) depends on iflib in FreeBSD 12/13, and > > with r343617, iflib is now explicitly a module that needs to be > > included in your kernel config if you want to use a driver that > > depends on it. It's already in the GENERIC kernel for amd64; are > > you using a kernel config file that doesn't inherit from GENERIC? > > HO Eric! > > iflib was a recently added requirement on stable/12 IIRC..? > > Does the manpage note this dependency, and is there an UPDATING entry > for this change? > > Thanks! > -Enji > My question would be: why? If some drivers have a new dependency on iflib, why isn't that expressed in sys/conf/files and handled automatically? -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem building dev/e1000
Looking through the SVN logs, it looks like kib put an entry in the stable/12 UPDATING in r344149 when he MFC'd the "make iflib a loadable module" changes. As for the em man page, they don't note the specific "device iflib" dependency, so that needs to be added (as well as a more general update since it looks like it's out of date). Though, there is at least a mention of it using iflib near the bottom. - Eric On Fri, Feb 15, 2019 at 10:53 AM Enji Cooper wrote: > > > On Feb 15, 2019, at 10:46, Eric Joyner wrote: > > > > ifdi_if.h is a system generated interface file that network drivers that > depend on iflib use. It's generated from ifdi_if.m in sys/net. > > > > My guess is that you don't have "device iflib" defined in your kernel > configuration. em(4) depends on iflib in FreeBSD 12/13, and with r343617, > iflib is now explicitly a module that needs to be included in your kernel > config if you want to use a driver that depends on it. It's already in the > GENERIC kernel for amd64; are you using a kernel config file that doesn't > inherit from GENERIC? > > HO Eric! > > iflib was a recently added requirement on stable/12 IIRC..? > > Does the manpage note this dependency, and is there an UPDATING entry for > this change? > > Thanks! > -Enji ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem building dev/e1000
> On Feb 15, 2019, at 10:46, Eric Joyner wrote: > > ifdi_if.h is a system generated interface file that network drivers that > depend on iflib use. It's generated from ifdi_if.m in sys/net. > > My guess is that you don't have "device iflib" defined in your kernel > configuration. em(4) depends on iflib in FreeBSD 12/13, and with r343617, > iflib is now explicitly a module that needs to be included in your kernel > config if you want to use a driver that depends on it. It's already in the > GENERIC kernel for amd64; are you using a kernel config file that doesn't > inherit from GENERIC? HO Eric! iflib was a recently added requirement on stable/12 IIRC..? Does the manpage note this dependency, and is there an UPDATING entry for this change? Thanks! -Enji ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem building dev/e1000
On Thu, Feb 14, 2019 at 04:24:28PM -0500, Robert Huff wrote: > > On a system running: > > FreeBSD 13.0-CURRENT r343080 amd64 > > with source tree updated at midnight last night, attempts to > build a kernel with "device em" die with: Did you added 'device iflib' to your kernel config ? > > > ctfconvert -L VERSION -g efirtc.o > cc -target x86_64-unknown-freebsd13.0 > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing > -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD > -MF.depend.if_em.o -MTif_em.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv > -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef > -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -Wno-error-unused-function > -Wno-error-pointer-sign -Wno-error-shift-negative-value > -Wno-address-of-packed-member -mno- ae > s -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/e1000/if_em.c > -I/usr/src/sys/dev/e1000 > In file included from /usr/src/sys/dev/e1000/if_em.c:30: > /usr/src/sys/dev/e1000/if_em.h:91:10: fatal error: 'ifdi_if.h' file not found > #include "ifdi_if.h" > ^~~ > 1 error generated. > *** Error code 1 > > > 'ifdi_if.h' is not in the local e1000 direstory, nor is it in the > equavalent place in the svn repository on FreeBSD.org. > Is this something I'm doing wrong? Or is there a problem in > "if_em.h"? > > > Respectfully, > > > Robert Huff > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem building dev/e1000
> On Feb 14, 2019, at 13:24, Robert Huff wrote: > > >On a system running: > > FreeBSD 13.0-CURRENT r343080 amd64 > >with source tree updated at midnight last night, attempts to > build a kernel with "device em" die with: > > > ctfconvert -L VERSION -g efirtc.o > cc -target x86_64-unknown-freebsd13.0 > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing > -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include > -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD > -MF.depend.if_em.o -MTif_em.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv > -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef > -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs > -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -Wno-error-unused-function > -Wno-error-pointer-sign -Wno-error-shift-negative-value > -Wno-address-of-packed-member -mno- ae > s -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/e1000/if_em.c > -I/usr/src/sys/dev/e1000 > In file included from /usr/src/sys/dev/e1000/if_em.c:30: > /usr/src/sys/dev/e1000/if_em.h:91:10: fatal error: 'ifdi_if.h' file not found > #include "ifdi_if.h" > ^~~ > 1 error generated. > *** Error code 1 > > >'ifdi_if.h' is not in the local e1000 direstory, nor is it in the > equavalent place in the svn repository on FreeBSD.org. >Is this something I'm doing wrong? Or is there a problem in > "if_em.h"? CCing erj@ for context. -Enji ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
problem building dev/e1000
On a system running: FreeBSD 13.0-CURRENT r343080 amd64 with source tree updated at midnight last night, attempts to build a kernel with "device em" die with: ctfconvert -L VERSION -g efirtc.o cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.if_em.o -MTif_em.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -mno-ae s -mno-avx -std=iso9899:1999 -Werror /usr/src/sys/dev/e1000/if_em.c -I/usr/src/sys/dev/e1000 In file included from /usr/src/sys/dev/e1000/if_em.c:30: /usr/src/sys/dev/e1000/if_em.h:91:10: fatal error: 'ifdi_if.h' file not found #include "ifdi_if.h" ^~~ 1 error generated. *** Error code 1 'ifdi_if.h' is not in the local e1000 direstory, nor is it in the equavalent place in the svn repository on FreeBSD.org. Is this something I'm doing wrong? Or is there a problem in "if_em.h"? Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
