[OpenWrt-Devel] Split kernel modules out of the base opkg repo?

Matthias Schiffer mschiffer at universe-factory.net
Sat Jul 25 13:18:44 EDT 2015


On 07/25/2015 06:16 PM, Florian Fainelli wrote:
> On Jul 25, 2015 7:39 AM, "Matthias Schiffer" <mschiffer at universe-factory.net>
> wrote:
>>
>> On 07/25/2015 03:55 PM, John Crispin wrote:
>>>
>>>
>>> On 25/07/2015 14:46, Matthias Schiffer wrote:
>>>> Hi,
>>>> I'd like to propose to split the current "base" opkg repo into two, one
>>>> for userspace applications and one for kernel modules. This would
>>>> greatly simplify providing your own kernel module repository with
>>>> modules for a customized kernel, while still being able to rely on the
>>>> upstream "base" repo for userspace.
>>>>
>>>> I'll provide a patch for this if you think this is a reasonable idea.
>>>>
>>>> Matthias
>>>>
>>>
>>> i think the current setup works very well for open drivers and code.
>>> fixing up openwrt for out of tree modules is imho not a good idea as it
>>> allows companies to easily avoid upstreaming stuff.
>>>
>>> why dont you just include your magic USP into openwrt and/or upstream ?
>>
>> I'm not talking about out-of-tree modules at all, I'm talking about the
>> kmod-* packages in the base repo. I want to provide an own opkg repo
>> with the same kernel modules, but built for a customized kernel.
>>
>> As these modules' ABI depends on the kernel configuration (and thus the
>> kernel configuration is included in the version number as "vermagic"), I
>> need to provide the kernel modules built matching my configuration. As
>> far as I know there's no way to tell opkg to prefer the modules from my
>> repo, regardless of the version number, so I'm asking for a base repo
>> without any kmod-* packages.
> 
> But since this is already a custom repository, why not take care yourself
> of synchronizing the base packages (but not kmod-*) from OpenWrt's upstream
> directly?

Sure, that would be the alternative, but it would be much easier if I
could just take the upstream repo as is.

> 
> If you dedicate a custom kernel image version to make sure that OpenWrt
> kmods cannot be installed, does not that work already?
> 

If I ensure that my custom kernel version number is higher than the
version number of the official OpenWrt image's kernel, that would work
(so opkg will select my modules and not the upstream ones); I guess I
can live with that. Can I assume that the LINUX_RELEASE variable will
never have a value different from 1 in official OpenWrt builds?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150725/ef609f1a/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list