src-test2/sys/modules/fxp, branch release/9.0.0 FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F9.0.0 2011-11-06T17:23:49Z MFC: r226154, r226165 2011-11-06T17:23:49Z Marius Strobl marius@FreeBSD.org 2011-11-06T17:23:49Z urn:sha1:42d9ccc9c871ec3dc35ebcfde15d3c4a3a8aba64 - Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. Approved by: re (kib) Remove bridge(4) from the tree. if_bridge(4) is a full functional 2005-09-27T18:10:43Z Max Laier mlaier@FreeBSD.org 2005-09-27T18:10:43Z urn:sha1:b6de9e91bd2c47efaeec72a08642f8fd99cc7b20 replacement and has additional features which make it superior. Discussed on: -arch Reviewed by: thompsa X-MFC-after: never (RELENG_6 as transition period) vlan.h is obsolete, don't create it anymore. 2001-09-05T23:47:02Z Brooks Davis brooks@FreeBSD.org 2001-09-05T23:47:02Z urn:sha1:0fddbf874719b9bd50cf66ac26d1140bb3f2be69 Unconditinally turn on VLAN support when building fxp as a module, since 2001-07-19T15:58:40Z Jonathan Lemon jlemon@FreeBSD.org 2001-07-19T15:58:40Z urn:sha1:9009a48f03c03b1fdbad930087b86be1d1659fab it may be plugged into a kernel that supports VLANs. If the kernel is not VLAN aware, things will still work as before. Modules don't really have option support, so this is somewhat of a hack. Update makefile to reflect vlan support. 2001-05-13T00:04:02Z Jonathan Lemon jlemon@FreeBSD.org 2001-05-13T00:04:02Z urn:sha1:336f51412c10e7b308863e7530550f6be31dc460 Back out 'KMODDEPS = miibus' addition in last commit. This isn't used. 2001-03-24T22:21:59Z Peter Wemm peter@FreeBSD.org 2001-03-24T22:21:59Z urn:sha1:f335dba0eff52af5c7e7eaf15f5507fd04fe6db6 Adjust the fxp module to use the correct directory path, and add a 2001-03-12T21:44:19Z Jonathan Lemon jlemon@FreeBSD.org 2001-03-12T21:44:19Z urn:sha1:7cbbb1afee4f4e4a5d580e97bcd962f9ca8de222 dependency on miibus. Use a consistent style and one much closer to the rest of /usr/src 2001-01-06T14:00:42Z David E. O'Brien obrien@FreeBSD.org 2001-01-06T14:00:42Z urn:sha1:c68159a6d8eede11766cf13896d0f7670dbd51aa Use .include <bsd.kmod.mk> to get to ../../*/conf/kmod.mk instead of 2000-05-27T01:14:33Z Peter Wemm peter@FreeBSD.org 2000-05-27T01:14:33Z urn:sha1:64db83a8ab2d1f72a9b2174b39d2ef42b5b0580c encoding the relative path. Pull in sys/conf/kmod.mk, rather than /usr/share/mk/bsd.kmod.mk. 2000-05-04T12:08:52Z Peter Wemm peter@FreeBSD.org 2000-05-04T12:08:52Z urn:sha1:56ca39961bd1c9946a505c41c3fc634ef63fdd42 This means that the kernel can be totally self contained now and is not dependent on the last buildworld to update /usr/share/mk. This might also make it easier to build 5.x kernels on 4.0 boxes etc, assuming gensetdefs and config(8) are updated.