FreeBSD support for AR8161/AR8162

[Luis R. Rodriguez]

I'm adding unified-drivers at lists.infradead.org list. This is
a public list and we should be talking about how to do,
if its however possible, unification through communication
between both FreeBSD and Linux folks.

My reply below.

On Wed, Mar 06, 2013 at 02:39:34PM +0900, YongHyeon PYUN wrote:
> On Wed, Mar 06, 2013 at 04:16:03AM +0000, Chadd, Adrian wrote:
> > Hi,
> > 
> > Thnks for your reply.
> > 
> > The reason to have as much shared code as possible is pretty simple - it
> > simplifies both existing and new hardware validation.
> 
> I can understand the desire for having an unified driver. If I was
> hired to maintain driver for multiple OSes I would also have
> thought about that.
> 
> > The problem with having separate drivers on each OS is that you end up
> > needing multiple teams, one for each driver, with all of the issues that
> > show up when you try to have them work together with completely different
> > codebases.
> > 
> 
> I don't think vendor has to write different drivers for every OSes.
> They can't do that due to various reasons. I think maintaining a
> single reference driver for chosen OS(i.e. Linux) would be enough
> for most cases and have open source driver writers do their own
> work on different OSes by providing both sanitized data sheet and
> engineering samples. Maintaining unified driver also would be big
> burden to the vendor since every single bit of change would affect
> multiple OSes. As I said I didn't see well written unified driver
> in the past.

Well guess what? Most vendors do this anyway already. Then you
get huge massive piles of mess. There are many examples to
provide here.

We want to take a slightly different approach.

> > The alx driver is pretty simple. We could break out the MAC, PHY and MDIO
> > related logic pretty easily. It doesn't have to be as "dirty" as the way
> > Intel does it. But the way Intel does it is because they don't _have_ to do
> > it any other way to make it work on Linux, so they don't bother making it
> > well-designed. We have that option - I want to see things better designed.
> > :-)
> 
> I'm afraid every ethernet controllers require its own magic. It
> may not work as it is designed for and errata shows up later. Its
> internal structure could be improved to save cost/power in later
> revisions.  For Attansic/Atheros cases, they do not seem to
> maintain register/descriptor compatibilities in wired ethernet
> controllers such that it used to require different driver in the
> past.  I also don't like the way Intel driver is synced in FreeBSD
> but it's acceptable to me given that it mostly works on various
> configurations and the maintainer is very responsive to user/
> community requests/questions.
> 
> I'm not saying unified driver is not doable. It just costs more
> than maintaining a single reference driver for Linux. And I believe
> unified driver should be maintained by developers who work for the
> vendor. It can't be separately developed/adopted by outside
> developers as it requires more information than that of the
> interface of the shared code.

This is a shared sentiment amongst most of us as well. However one
idea is -- what if we, the community -- that is, not vendors, tried
to address unification ourselves. And in the end if that does not
work we at the very least work with vendors pushing out a public
reference driver that is:

1. Cleaner
2. Public
3. Has some stuff to help with the port

Problem today is most unified vendor drivers are:

1. Crap
2. Private
3. Have some nasty stuff to port to different OSes

> I don't think FreeBSD is mainline OS for many vendors so I didn't
> expect much from vendors. 

This is true, however FreeBSD licenses work for supporting
other OSes well too. In other words, one could argue a reference
FreeBSD driver can help with streamlining an open reference
driver for other OSes as well.

> Probably QCA would be the one that try
> to offer more flexibilities to various communities. I really
> appreciate the endeavor but maintaining the driver is more
> important than designing one. Just dumping the unified driver into
> tree shall not guarantee it would be automatically maintained by
> other developers. We already seen these kind of 10G ethernet
> drivers in the past.

Sure, this is reasonable and we get it. The idea is to work with
the community on a different strategy with unification and if that
does not work at least get the pipeline on vendor driver releases
more in sych with what we in the community think is best. This
does include documentation, etc.

As for unification I personally have started to look at SmPL as
a way to try to address OS differences without affecting the
actual code and without needing a HAL. That is, the actual code
never has OS Shims but instead we have SmPL grammar that helps
interpret things.

http://coccinelle.lip6.fr/

Have you looked into that by any chance before?

  Luis