alx - next round of review / portability comments
Adrian Chadd
adrian at freebsd.org
Mon Apr 8 15:45:06 EDT 2013
Hiya!
I've spent a few days going back over the alx code to see how hard
it'd be to bring up the hardware side of things in non-Linux.
It's in better shape than before.
The architectural (high level) overview:
* there's a mix of network stack facing and hardware specific code in
both alx_main.c and alx_hw.c, which makes it hard to port.
* the hardwre registers are in a separate header, but the transmit /
receive descriptors are in alx_hw.h, which includes the linux specific
netdev stuff.
* alx_hw.c and alx_main.c have a variety of different things all
glumped together - transmit/receive obviously, but there's also PHY
related code, MDIO bus stuff, MAC setup/start/stop stuff, PCIe stuff,
etc.
So what I'm thinking of doing:
* Separate out the hardware facing code from the driver facing code
into two subdirectories for now - hw/ will have hardware specific
code, drv/ will have the linux driver code;
* drv/ will only call into hw/ to get things done - ie, there's no
hardware code _in_ drv/ ;
* split struct alx_hw into struct alx_hw and struct alx_hal (I know, I
know) - move as much hardware state into alx_hal;
* portability types / calls / etc only go into the code in hw/, not
the code in drv/;
* Make sure that works.
I don't think I'll be able to fully capture all of the hardware code
in this split in the first pass - there's just too much stuff entwined
with driver facing code. But it's a good start.
My aim is to get everything in hw/ compilable on non-Linux, so then I
can (hopefully!) get device probe/attach/detach working on FreeBSD.
Comments?
Adrian
More information about the unified-drivers
mailing list