Hello there. I have an embedded system with the 2.6.32 kernel (I
agree that this is rather old, but it's stable on this board, and I'm
hesitant to change it as it's undergone and passed many tests).
The kernel works fine, the drivers included with the kernel work fine,
some additional drivers that I've added work fine (they are out of
kernel, but build against the built kernel).
The problem is with compat-drivers. I need to get some new wireless
drivers for newly supported hardware, however, compat-drivers insists
on compiling its own mac80211 and cfg80211 drivers, as it compiles the
stack of drivers. These clash with the mac80211 and cfg80211 drivers
that were compiled along with the kernel. The module sizes are very
different, it's clear they're not compatible, it's not a small change.
I couldn't find a way to disable this, and tell compat-drivers to use
mac80211/cfg80211 from my kernel instead of trying to compile its own.
if I load the mac80211 and cfg80211 from compat-drivers, and then load
a driver that was compiled against the kernel, there's no missing
symbols, but it crashes with an oops when it tries to register itself
with the mac80211/cfg80211 stack.
The vice versa also happens. If I load mac80211/cfg80211 from the
kernel, then load a driver from compat-drivers, I get an oops during
initialization.
It seems I can choose to use the mac80211/cfg80211 that came with the
kernel, *or*, the mac80211/cfg80211 that come with compat-drivers. Is
this correct? I'll have to maintain these two mac80211/cfg80211
drivers in separate directories, since they have the same name, and it
will complicate my detection/loading script, but if there's no other
way, then this is what needs to be done.
Could it be because I cross-compile compat-drivers? Looking at the
installation scripts, it's clearly intended to be ran by the end user
to replace the drivers in their distribution with updated drivers, and
it could be that I missed something when tweaking it to cross-compile
the drivers and not install them locally.
Has anybody else tried to use compat-drivers to build for an embedded
system? If so, what's the recommended solution? How to solve the
mac80211/cfg80211 problem, where the kernel-compiled mac80211/cfg80211
modules conflict with their equivalent compat-drivers modules?
Thanks! Any help would be appreciated.
Josh Lehan
On 05/11/2013 12:35 AM, Arend van Spriel wrote:
> On 05/11/2013 02:52 AM, JoSH Lehan wrote:
> Luis may correct me, but I think you are correct. compat-drivers
> provides a compat.ko which is the glue between new drivers and your
> kernel. With the new drivers you get new features provided you have new
> mac80211/cfg80211 as well. Hence the glue is between wireless modules
> (including mac80211/cfg80211) and rest of your kernel. On a non-embedded
> system the compat-driver modules are installed in a separate folder
> /lib/modules/<your_kernel_version/updates. depmod is run during the
> install in which this folder takes precedence.
Thanks! So, I'll need to maintain two sets of mac80211/cfg80211
modules: one for drivers that were compiled along with the kernel, and
another for drivers that were compiled as part of the compat-drivers
package.
> Not sure what your use-case is. You have a system in which different
> wireless devices may be plugged in or ...?
Yes. It's an embedded system, however, it has an exposed USB port and
the user is free (within reason) to plug in a USB device. I'm trying to
add support for as many USB wireless adapters that I can find. For some
adapters (such as vt6656 and rtl8712), I use the vendor's tarball (which
compiles directly against the kernel). So, this is why I need to mix
and match drivers compiled against the kernel's mac80211/cfg80211 with
drivers compiled against the mac80211/cfg80211 from compat.
> Probably not, provided you build it for your kernel version.
Thanks. Everything's being built for the same version, which is good.
It all compiles and loads OK. The problem is when the drivers are
actually used, then they oops.
> Depends what you call an embedded system. We used it to run our driver
> on Android. Just cross-compiling it and install it on the system is what
> we did. Recently, there have been a number of people walking that path
> and contacting us. It may be an idea to have a compat-drivers feature to
> generate Android tarballs as it is always running a few kernel versions
> behind mainline.
I'm just running the upstream Linux from kernel.org, not Android. Good
to see you supporting Android, though. Thanks for your help!
Josh Lehan
On Sat, May 11, 2013 at 5:46 PM, Adrian Chadd <[email protected]> wrote:
> No, you or the vendor should forward port it to linux-next, then you
> can just pick up the whole driver/framework set from compat-wireless.
For my needs, I can use the entire set of wireless drivers from
compat-drivers, plus the vt6656 and rtl8712 drivers.
If I were to undertake the task of porting the vt6656/rtl8712 vendor
tarballs to linux-next, so that I could integrate them into
compat-drivers and then build everything compatibly, I wonder if it
would be worth trying to improve what's in staging?
Ideally, I'd need to do some big three-way merge: the current contents
of staging, the original code drop that went into staging, and the
current versions of vendor tarballs. Would such a thing be practical?
It would be quite a project, and I would be hoping the results of it
would be accepted into staging. It might help others, as well. Since
compat-drivers only pulls from the regular kernel driver directory and
not from staging, it wouldn't help get them into compat-drivers,
though.
Josh Lehan
On 05/11/2013 02:52 AM, JoSH Lehan wrote:
> It seems I can choose to use the mac80211/cfg80211 that came with the
> kernel,*or*, the mac80211/cfg80211 that come with compat-drivers. Is
> this correct? I'll have to maintain these two mac80211/cfg80211
> drivers in separate directories, since they have the same name, and it
> will complicate my detection/loading script, but if there's no other
> way, then this is what needs to be done.
Luis may correct me, but I think you are correct. compat-drivers
provides a compat.ko which is the glue between new drivers and your
kernel. With the new drivers you get new features provided you have new
mac80211/cfg80211 as well. Hence the glue is between wireless modules
(including mac80211/cfg80211) and rest of your kernel. On a non-embedded
system the compat-driver modules are installed in a separate folder
/lib/modules/<your_kernel_version/updates. depmod is run during the
install in which this folder takes precedence.
Not sure what your use-case is. You have a system in which different
wireless devices may be plugged in or ...?
> Could it be because I cross-compile compat-drivers? Looking at the
> installation scripts, it's clearly intended to be ran by the end user
> to replace the drivers in their distribution with updated drivers, and
> it could be that I missed something when tweaking it to cross-compile
> the drivers and not install them locally.
Probably not, provided you build it for your kernel version.
> Has anybody else tried to use compat-drivers to build for an embedded
> system? If so, what's the recommended solution? How to solve the
> mac80211/cfg80211 problem, where the kernel-compiled mac80211/cfg80211
> modules conflict with their equivalent compat-drivers modules?
Depends what you call an embedded system. We used it to run our driver
on Android. Just cross-compiling it and install it on the system is what
we did. Recently, there have been a number of people walking that path
and contacting us. It may be an idea to have a compat-drivers feature to
generate Android tarballs as it is always running a few kernel versions
behind mainline.
Regards,
Arend
On Sat, May 11, 2013 at 2:18 AM, Hauke Mehrtens <[email protected]> wrote:
> On 05/11/2013 09:35 AM, Arend van Spriel wrote:
>> On 05/11/2013 02:52 AM, JoSH Lehan wrote:
>>> It seems I can choose to use the mac80211/cfg80211 that came with the
>>> kernel,*or*, the mac80211/cfg80211 that come with compat-drivers. Is
>>> this correct? I'll have to maintain these two mac80211/cfg80211
>>> drivers in separate directories, since they have the same name, and it
>>> will complicate my detection/loading script, but if there's no other
>>> way, then this is what needs to be done.
>>
>> Luis may correct me, but I think you are correct. compat-drivers
>> provides a compat.ko which is the glue between new drivers and your
>> kernel. With the new drivers you get new features provided you have new
>> mac80211/cfg80211 as well. Hence the glue is between wireless modules
>> (including mac80211/cfg80211) and rest of your kernel. On a non-embedded
>> system the compat-driver modules are installed in a separate folder
>> /lib/modules/<your_kernel_version/updates. depmod is run during the
>> install in which this folder takes precedence.
>>
>> Not sure what your use-case is. You have a system in which different
>> wireless devices may be plugged in or ...?
>
> You can only use mac80211/cfg80211 from compat-driver *or* the kernel.
> There was a plan to rename all exported symbols and make it possible to
> use both at the same time, but no one fully implemented it.
I ended up renaming as many exported symbols as I could when and only
when we were not providing a full subsystem backport for where that
exported symbol lived. You can find these pegged with a
LINUX_BACKPORT() macro. If a subsystem is backported fully we don't do
the mapping name change. I still looked at an option to provide what
you describe though and simply rename all exported symbols with a the
LINUX_BACKPORT() prefix, ie, backport_ -- and the best lead I found
was work done by Andi Kleen a while ago on introducing module
namespaces but this work got rejected. We could try to port that
ourselves somehow for backports. For details see this commit which
talks about it:
https://git.kernel.org/cgit/linux/kernel/git/mcgrof/compat.git/commit/?id=8ae967309876a9297dedfdf64dfcca406639686f
Under the new backports tree though we now use Python for some code
mangling to help us with our backport, this will specially be useful
later when we start using SmPL for patch treatment where the hunks
don't line up anymore or simply always with SmPL. Anyway, apart from
that - we also use the python script to do some mangling of Kconfig
entries for us. Given that -- it should then also be possible for us
to then treat all EXPORT_SYMBOL_GPL() (note on backports all symbols
are EXPORT_SYMBOL_GPL() or at least that was the intent, we should fix
if anything has leaked) to add the LINUX_BACKPORT() prefix for us --
but note that it still does not address the head file changes. I
suppose you could first scrape for all exported symbols and then go
also address headers.
So these are the two options I see right now, Andi's work or Python
magic. Both are projects in themselves. Patches welcomed.
I should note the compat-drivers git tree will be renamed to backports
where it now has compat and compat-drivers merged and I'll soon make
it available on kernel.org, as soon as I get all delta merged that
gets us to backport a v3.10 release. I the meantime interested
developers should look at the instructions I provided another
developer here:
http://marc.info/?l=linux-backports&m=136838721415310&w=2
As for kernel integration of backports -- that is not possible today
but I welcome such changes. I provided a hint as to how this could be
possible to do here:
http://marc.info/?l=linux-backports&m=136823203813610&w=2
Patches welcomed.
Luis
On 05/11/2013 04:10 PM, Larry Finger wrote:
> Neither driver r8712u, which has been in the kernel since 2.6.37, nor
> the equivalent vendor driver depends on anything from mac80211 or
> cfg80211. If it did, the kernel version would be in the
> drivers/net/wireless tree rather than in staging. I suspect the same is
> true for other wireless drivers from staging, which includes vt6656.
Interesting. I'll have to investigate more. I'm using kernel 2.6.32
for this system, so can't use the r8712u driver from the later kernel.
When I ran the vendor rtl8712 driver, it worked well enough with the
modules from the kernel, however, when I added compat-drivers to the
build (which replaced the mac80211/cfg80211 modules that were already
there), it crashed with an oops. More investigation is needed to know
why this happens, but it must have something to do with compat-drivers,
because that is the only difference. I removed compat-drivers from the
build, and it went back to being fully working. Something must be
interacting in a bad way.
Josh Lehan
Hi,
On 11 May 2013 15:54, JoSH Lehan <[email protected]> wrote:
> Thanks! So, I'll need to maintain two sets of mac80211/cfg80211
> modules: one for drivers that were compiled along with the kernel, and
> another for drivers that were compiled as part of the compat-drivers
> package.
No, you or the vendor should forward port it to linux-next, then you
can just pick up the whole driver/framework set from compat-wireless.
Adrian
On Sun, May 12, 2013 at 3:34 AM, Arend van Spriel <[email protected]> wrote:
> On 05/12/2013 02:46 AM, Adrian Chadd wrote:
>> No, you or the vendor should forward port it to linux-next, then you
>> can just pick up the whole driver/framework set from compat-wireless.
>
> That is indeed the approach. So integrate your vendor provided driver into
> your local linux-next tree and create you own compat-drivers package using
> that tree (see [1]). You have to tinker the framework to include that
> driver.
Thanks to both of you for the advice, on what best to do long-term.
Better yet, I should look into the feasibility of upgrading my
embedded system's kernel to something more recent (so that I wouldn't
need to use compat-drivers at all then).
Josh Lehan
On 05/12/2013 02:46 AM, Adrian Chadd wrote:
> Hi,
>
> On 11 May 2013 15:54, JoSH Lehan <[email protected]> wrote:
>
>> Thanks! So, I'll need to maintain two sets of mac80211/cfg80211
>> modules: one for drivers that were compiled along with the kernel, and
>> another for drivers that were compiled as part of the compat-drivers
>> package.
>
> No, you or the vendor should forward port it to linux-next, then you
> can just pick up the whole driver/framework set from compat-wireless.
That is indeed the approach. So integrate your vendor provided driver
into your local linux-next tree and create you own compat-drivers
package using that tree (see [1]). You have to tinker the framework to
include that driver.
Regards,
Arend
[1]
https://backports.wiki.kernel.org/index.php/Documentation/compat-drivers/hacking
On 05/11/2013 02:18 AM, Hauke Mehrtens wrote:
> You can only use mac80211/cfg80211 from compat-driver *or* the kernel.
> There was a plan to rename all exported symbols and make it possible to
> use both at the same time, but no one fully implemented it. The API
> between mac80211/cfg80211 is not stable and changing very often to
> implement new features so it is not possible to use new drivers with an
> older version of mac80211/cfg80211 or the other way around.
OK, thanks, that's probably why it crashes then. The ABI is different,
even though the symbols are the same. That would explain why it
compiles and links OK, but gets very confused at runtime.
Is my workaround acceptable: maintain two different sets of
mac80211/cfg80211 modules, one from the kernel compilation and another
from the compat-drivers compilation, then, based on which driver is
detected at runtime, make sure I load the correct set? I have a fairly
light embedded system, that lacks modern user features such as udev, so
I do module loading/detection based on a fairly simple hotplug script
that I wrote. It just takes the USB vendor/device ID and looks that up
in the modules.alias file, and loads that module with modprobe. So, I
can easily extend that to select the correct mac80211/cfg80211 set, and
make sure that's loaded first.
> compat.ko is not a glue it is more a module containing all the functions
> not available in the kernel comopat-drivers was compiled against, but
> needed by some drivers or frameworks like mac80211.
Thanks for the clarification. At first, I thought the compat.ko module
was only for the individual wireless device drivers, not for the entire
mac80211/cfg80211 stack, now I know.
> You should take all wireless drivers using mac80211/cfg80211 from
> compat-drivers and not use the in kernel versions any more.
Unfortunately some of my drivers (such as vt6656 and rtl8712) are from
tarballs that come from the vendor, and they exist outside the kernel
directory, but use it as a reference when compiling for that kernel.
It's similar to how compat-drivers is built. This means they don't see
each other, unfortunately, even though they are eventually being
compiled for the same kernel. I could not find a way to make these
vendor tarballs compatible with compat-drivers, given this setup.
I wonder if the compat-drivers tree can be copied into the kernel
directory itself, to replace what's already there, so that I can build
the kernel and it would contain the compat-drivers flavor of
mac80211/cfg80211 instead of the original kernel flavor of
mac80211/cfg80211? Then, I could compile the vendor tarballs against
that, which would seem to neatly solve my problem, if it were possible.
Does compat-drivers have an option to integrate into the kernel build
instead of being compiled outside of it?
Josh Lehan
On 05/11/2013 05:54 PM, JoSH Lehan wrote:
> Yes. It's an embedded system, however, it has an exposed USB port and
> the user is free (within reason) to plug in a USB device. I'm trying to
> add support for as many USB wireless adapters that I can find. For some
> adapters (such as vt6656 and rtl8712), I use the vendor's tarball (which
> compiles directly against the kernel). So, this is why I need to mix
> and match drivers compiled against the kernel's mac80211/cfg80211 with
> drivers compiled against the mac80211/cfg80211 from compat.
>
Neither driver r8712u, which has been in the kernel since 2.6.37, nor the
equivalent vendor driver depends on anything from mac80211 or cfg80211. If it
did, the kernel version would be in the drivers/net/wireless tree rather than in
staging. I suspect the same is true for other wireless drivers from staging,
which includes vt6656.
Larry
On 05/11/2013 09:35 AM, Arend van Spriel wrote:
> On 05/11/2013 02:52 AM, JoSH Lehan wrote:
>> It seems I can choose to use the mac80211/cfg80211 that came with the
>> kernel,*or*, the mac80211/cfg80211 that come with compat-drivers. Is
>> this correct? I'll have to maintain these two mac80211/cfg80211
>> drivers in separate directories, since they have the same name, and it
>> will complicate my detection/loading script, but if there's no other
>> way, then this is what needs to be done.
>
> Luis may correct me, but I think you are correct. compat-drivers
> provides a compat.ko which is the glue between new drivers and your
> kernel. With the new drivers you get new features provided you have new
> mac80211/cfg80211 as well. Hence the glue is between wireless modules
> (including mac80211/cfg80211) and rest of your kernel. On a non-embedded
> system the compat-driver modules are installed in a separate folder
> /lib/modules/<your_kernel_version/updates. depmod is run during the
> install in which this folder takes precedence.
>
> Not sure what your use-case is. You have a system in which different
> wireless devices may be plugged in or ...?
You can only use mac80211/cfg80211 from compat-driver *or* the kernel.
There was a plan to rename all exported symbols and make it possible to
use both at the same time, but no one fully implemented it. The API
between mac80211/cfg80211 is not stable and changing very often to
implement new features so it is not possible to use new drivers with an
older version of mac80211/cfg80211 or the other way around.
compat.ko is not a glue it is more a module containing all the functions
not available in the kernel comopat-drivers was compiled against, but
needed by some drivers or frameworks like mac80211.
You should take all wireless drivers using mac80211/cfg80211 from
compat-drivers and not use the in kernel versions any more.
>> Could it be because I cross-compile compat-drivers? Looking at the
>> installation scripts, it's clearly intended to be ran by the end user
>> to replace the drivers in their distribution with updated drivers, and
>> it could be that I missed something when tweaking it to cross-compile
>> the drivers and not install them locally.
>
> Probably not, provided you build it for your kernel version.
>
>> Has anybody else tried to use compat-drivers to build for an embedded
>> system? If so, what's the recommended solution? How to solve the
>> mac80211/cfg80211 problem, where the kernel-compiled mac80211/cfg80211
>> modules conflict with their equivalent compat-drivers modules?
>
> Depends what you call an embedded system. We used it to run our driver
> on Android. Just cross-compiling it and install it on the system is what
> we did. Recently, there have been a number of people walking that path
> and contacting us. It may be an idea to have a compat-drivers feature to
> generate Android tarballs as it is always running a few kernel versions
> behind mainline.
>
> Regards,
> Arend