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