[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: WiFi Refresh -- Report 1
In article <201807060910.28137.phil%NetBSD.org@localhost>,
Phil Nelson <phil%NetBSD.org@localhost> wrote:
>#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
>I am using the sbuf.h to get the files to compile, buf have not yet
>subr_sbuf.c. I am planning on including those two files to support the
>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
I would call it IEEE80211_KASSERT(), so that it can be fed back upstream.
>#3: FreeBSD directly manipulates the mbuf headers, specifically
>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
>#4: The 80211 code uses 12 proto specific flags with their mbufs. Our
>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
>flags to our mbufs. The following are the diffs I am using to get the
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.
>#6 VLAN support is disabled as FreeBSD and NetBSD vlan support is
>Once we have working code and more time, I'll review the VLAN support.
>#7 taskqueue (FreeBSD) vs workqueue (NetBSD) ... I'm looking at adding
>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
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.
>#10 ioctls and sysctls will need work. Almost nothing to date has been done.
>Now .... back to getting those 11 final files to compile.
Main Index |
Thread Index |