Re: WiFi Refresh -- Report 1

[christos%astron.com@localhost (Christos Zoulas)]

In article <201807060910.28137.phil%NetBSD.org@localhost>,
Phil Nelson  <phil%NetBSD.org@localhost> wrote:
>Hello tech-net,
>
>#1:  sbuf routines.   A number of the files use the sbuf routines.  These
>appear  to be relatively contained to two files, sys/sbuf.h and
>kern/subr_sbuf.c.
>I am using the sbuf.h to get the files to compile, buf have not yet
>tried compiling
>subr_sbuf.c.   I am planning on including those two files to support the
>ieee80211
>code instead of rewriting that code. 

Fine, we can decide what to do later.

>#2: KASSERT has different arguments on each platform.  In ieee80211_netbsd.h
>I have defined a FBSDKASSERT that matches and in any ieee8021*.c file that
>uses a KASSERT, I redefine KASSERT to be FBSDKASSERT.   By not adding that
>redefinition to the ieee80211_netbsd.h file, it doesn't redefine KASSERT for the
>NetBSD code.

I would call it IEEE80211_KASSERT(), so that it can be fed back upstream.

>#3: FreeBSD directly manipulates the mbuf headers, specifically
>m->m_pkthdr.rcvif.
>NetBSD uses a set of m_set_rcvif, m_get_rcvif, ... and those changes had
>to be made.

Good. You can add macros for the FreeBSD case (so that we can feed the
changes upstream).


>#4:  The 80211 code uses 12 proto specific flags with their mbufs.   Our
>mbufs don't
>have that many defined and instead of using M_PROTOn (where n is 0 .. 11), our
>mbufs have a number of M_LINKn flags.  It appeared better to me to add
>more M_LINKn
>flags to our mbufs. The following are the diffs I am using to get the
>files compiling.

Yes, I did the same.

>#5  FreeBSD module code is been disabled and due to that a number of __unused
>modifiers have been added ... but this will not be the final fix.   This
>will all be reviewed
>as I continue.

OK.

>
>#6  VLAN support is disabled as FreeBSD and NetBSD vlan support is
>completely different.
>Once we have working code and more time, I'll review the VLAN support.

OL.

>#7  taskqueue (FreeBSD) vs workqueue (NetBSD) ...  I'm looking at adding
>a taskqueue
>API front end to workqueue.   I have not attempted it yet.   taskqueue
>code has been
>ifdeffed out with a "#ifdef notyet" which will be removed once the final
>solution is complete.

Taylor had an implementation I think.

>#8  the "struct ifnet"  has some different fields between the two OSes
>and I haven't
>worked on that issue yet.   That will be required to get the final 11
>files compiling.

Yes, there are slightly different...

>#9  the struct ieee80211com is different in the new code and most
>drivers fail to compile
>due to missing fields.   Nothing has been done on this yet.

Ok.

>#10 ioctls and sysctls will need work.  Almost nothing to date has been done.
>
>Now .... back to getting those 11 final files to compile.

Great progress.

christos