Provide a backwards compatible way to have the extra macro by defining
PCCARD_API_LEVEL 5 before including pccarddevs for driver writers that
want/need to have the same driver on 5 and 6 with pccard attachments.
Approved by: re (dwhite)
struct ifnet or the layer 2 common structure it was embedded in have
been replaced with a struct ifnet pointer to be filled by a call to the
new function, if_alloc(). The layer 2 common structure is also allocated
via if_alloc() based on the interface type. It is hung off the new
struct ifnet member, if_l2com.
This change removes the size of these structures from the kernel ABI and
will allow us to better manage them as interfaces come and go.
Other changes of note:
- Struct arpcom is no longer referenced in normal interface code.
Instead the Ethernet address is accessed via the IFP2ENADDR() macro.
To enforce this ac_enaddr has been renamed to _ac_enaddr.
- The second argument to ether_ifattach is now always the mac address
from driver private storage rather than sometimes being ac_enaddr.
Reviewed by: sobomax, sam
there's not dependencies on pccard symboles, such a dependency is not
necessary. This means that drivers that have multiple attachments can
not drag bogus devices into the kernel at load time.
We can't (yet) do this with pci and isa. Drivers written for them
actually do seem to have symbols that depend on these busses'
implementation code.
ndis not touched until other things can be tested.
Make the pccard attachment work with NEWCARD
Start locking of the driver, but only the macros are defined right now
Tested on: Megahertz CC10BT/2
# (These cards are very popular on ebay these days, and run < $10 including
# shipping from some sellers).
network layer (ether).
- Don't abuse module names to facilitate ifconfig module loading;
such abuse isn't really needed. (And if we do need type information
associated with a module then we should make it explicit and not
use hacks.)
matching methods so that we can run the same driver on both NEWCARD
and OLDCARD. Also set the device description to the card that we
found, if any.
The sn driver should be ready when the NEWCARD catches up. There's a
config activation issue as well as a kernel thread issue to resolve
first.
possible to have different probe/attach semantics between the two
systems and yet still use the same driver for both.
Compatibility methods for OLDCARD drivers. We use these routines to make
it possible to call the OLDCARD driver's probe routine in the context that
it expects. For OLDCARD these are implemented as pass throughs to the
device_{probe,attach} routines. For NEWCARD they are implemented such
such that probe becomes strictly a matching routine and attach does both
the old probe and old attach.
compat devices should use the following:
/* Device interface */
DEVMETHOD(device_probe), pccard_compat_probe),
DEVMETHOD(device_attach), pccard_compat_attach),
/* Card interface */
DEVMETHOD(card_compat_match, foo_match), /* newly written */
DEVMETHOD(card_compat_probe, foo_probe), /* old probe */
DEVMETHOD(card_compat_attach, foo_attach), /* old attach */
This will allow a single driver binary image to be used for both
OLDCARD and NEWCARD.
Drivers wishing to not retain OLDCARD compatibility needn't do this.
ep driver minorly updated.
sn driver updated more than minorly. Add module dependencies to allow
module to load. Also change name to if_sn. Add some debugging code.
attempt to fix the cannot allocate memory problem I'd been seeing.
Minor formatting nits.
ether_ifdetach().
The former consolidates the operations of if_attach(), ng_ether_attach(),
and bpfattach(). The latter consolidates the corresponding detach operations.
Reviewed by: julian, freebsd-net
Add support, kinda, for megaheartz xjack nic cards. This support
works well for one machine per ethernet segment because it hard codes
the MAC address. The pccardd in -current doesn't have support to
parse the ethernet address from the CIS in the funky way that the
megaheartz card does things (it includes it in the info tuple, as
ascii, which is non-standard). I'd rather kludge this for the moment
and work to read the CIS from the kernel rather than mess with
pccardd.
The isa attachment is untested. The pccard attachment is known to
work since I'm committing over it.
Card Obtained from: Chris D. Faulhaber <jedger@fxp.org>
