26.07.2015 19:14, kp kirchdoerfer пишет:
> Am Sonntag, 26. Juli 2015, 18:16:51 schrieb Andrew:
>> 26.07.2015 18:09, kp kirchdoerfer пишет:
>>> Hi Andrew;
>>>
>>> Am Samstag, 25. Juli 2015, 19:32:10 schrieb Andrew:
>>>> Hi.
>>>>
>>>> I'll try to add it at this weekend.
>>> I've updated config.lrp and initrd.lrp and it seems to work regarding
>>> saving modules.
>>> But it seems there is a problem when removing modules.sqfs.
>>> While I do have saved the modules to moddb.lrp, it seems modules saved in
>>> moddb.lrp are not loaded (modules.sqfs has been deleted/removed).
>> Strange, fallback code should work OK. I'll test it
> Please do.
>
>>> In addition we should make shure for updates that modules.sqfs overwrites
>>> moddb.lrp - "if modules.sqfs is available, do not load moddb.lrp"
>>>
>>> kp
>> I'm not sure that it's a good idea. At least - moddb may be leaved for
>> user drivers/fresh versions of drivers.
> My wording was misleading ("overwritten").
>
>> Currently we:
>> 0) probing drivers from initmod
>> 1) trying to probe drivers from moddb
>> 2) trying to probe drivers from sqfs and copy missed drivers to /lib/modules
> That's what I meant - good it's in place aleady.
>
> kp
Currently we didn't check if driver was loaded from moddb or from sqfs.
So if there's already available drivers in /lib/modules (for different
kernel) - they will not be overwritten.
>
>>>> 25.07.2015 19:15, kp kirchdoerfer пишет:
>>>>> Hi Andrew;
>>>>>
>>>>> Am Samstag, 4. Juli 2015, 16:00:24 schrieb Andrew:
>>>>>> 04.07.2015 15:45, kp kirchdoerfer пишет:
>>>>>>> Am Samstag, 4. Juli 2015, 15:31:40 schrieb Andrew:
>>>>>>>> 04.07.2015 15:14, kp kirchdoerfer пишет:
>>>>>>>>> Hi;
>>>>>>>>>
>>>>>>>>> I almost agree with Erich :)
>>>>>>>>>
>>>>>>>>> Am Samstag, 4. Juli 2015, 14:56:33 schrieb Andrew:
>>>>>>>>>> 04.07.2015 11:34, Erich Titl пишет:
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> Am 04.07.2015 um 09:50 schrieb Andrew:
>>>>>>>>>>>> Hi.
>>>>>>>>>>>>
>>>>>>>>>>>> In most cases probing from squashfs is preferred over loading
>>>>>>>>>>>> from
>>>>>>>>>>>> moddb
>>>>>>>>>>>> - at least, this will not break system after update if it'll
>>>>>>>>>>>> require
>>>>>>>>>>>> some modules that aren't in moddb (for ex., some ethernet
>>>>>>>>>>>> driver).
>>>>>>>>>>>>
>>>>>>>>>>>> We may add some option to use legacy behavior with sqfs, or we
>>>>>>>>>>>> may
>>>>>>>>>>>> add
>>>>>>>>>>>> fallback behavior with tgz package for hwdetect.
>>>>>>>>>>> This would IMHO be a very ugly behaviour. I belived and still
>>>>>>>>>>> believe
>>>>>>>>>>> that the sqfs was a more elegant replacement for modules.tgz, and
>>>>>>>>>>> it
>>>>>>>>>>> is. You decided to use it also on startup with hwdetect, which
>>>>>>>>>>> makes
>>>>>>>>>>> IMHO most of the modules in initmod completely redundant.
>>>>>>>>>> This makes moddb completely redundant, and this is leaved only for
>>>>>>>>>> systems with small storage + rare cases like custom modules.
>>>>>>>>>> Initmod
>>>>>>>>>> is
>>>>>>>>>> needed anycase - it's mounted with rootfs, and requires loaded
>>>>>>>>>> storage-related modules.
>>>>>>>>> Indeed; if we empty moddb, we have to make shure most of the modules
>>>>>>>>> are
>>>>>>>>> referenced in /etc/modules, so they'll be loaded by hwdtect during
>>>>>>>>> boot
>>>>>>>>> from sqfs.
>>>>>>>> No, they'll be loaded like with filled moddb.
>>>>>>>>
>>>>>>>>> Will free about 1.8MB on the images, but I believe requires
>>>>>>>>> more
>>>>>>>>>
>>>>>>>>> maintenance cvause we need to keep /etc/modules in sync with kernel
>>>>>>>>> modules
>>>>>>>>> (netfilter etc). Don't know if wildcards are suppported in
>>>>>>>>> /etc/modules.
>>>>>>>> netfilter/iptables/shaper modules are in .depend list of
>>>>>>>> corresponding
>>>>>>>> packages (<DependsOn> section, lines like 'Module = ipt_*' - yes,
>>>>>>>> with
>>>>>>>> wildcards; algorithm earlier was used in getdep.sh).
>>>>>>> Seems I saw it, but forgot the changes you've made. So we can start to
>>>>>>> work
>>>>>>> with an empty moddb, but keep it for saving modules after hwdetect or
>>>>>>> added by the user?
>>>>>> Right. On my 5.2 boxes there's no moddb at all.
>>>>>>
>>>>>>>>>>> To me all this looks like we have no clear policy for module
>>>>>>>>>>> handling,
>>>>>>>>>>> at least in a transition phase. Just using the sqfs looks like a
>>>>>>>>>>> regression to me.
>>>>>>>>>>>
>>>>>>>>>>> Reducing the size or even making initmod redundant would be great
>>>>>>>>>>> if
>>>>>>>>>>> we could achieve that. I believe with the inclusion of sqfs
>>>>>>>>>>> support
>>>>>>>>>>> in
>>>>>>>>>>> the kernel this is possible. We should only do hwdetect if sqfs is
>>>>>>>>>>> present and definitely not inhibit saving modules in moddb.
>>>>>>>>>>>
>>>>>>>>>>> I don't want to run hwdetect at each and every boot and there
>>>>>>>>>>> should
>>>>>>>>>>> be a boot time selection either just by the presence of sqfs or a
>>>>>>>>>>> command line switch.
>>>>>>>>>> Will it be enough good to add legacy .tgz handling to hwdetect (so
>>>>>>>>>> systems with tgz instead of sqfs will have same behavior as
>>>>>>>>>> earlier)?
>>>>>>>>> I don't think it's necessary to revive tgz; it will just waste
>>>>>>>>> disk-space
>>>>>>>>> adds code etc..
>>>>>>>>>
>>>>>>>>> Saving modules in modbd and get rid of modules.sqfs later and until
>>>>>>>>> next
>>>>>>>>> update works if I remoce /var/lib/lrpkg/sqfs.modules (the
>>>>>>>>> "blacklist").
>>>>>>>>>
>>>>>>>>> An idea could be to add configuration option in /etc/lrp.conf (like
>>>>>>>>> lrp_SAVE_MODULES) and if set to "yes" hwdetect does not write the
>>>>>>>>> modules
>>>>>>>>> loaded into the blacklist - waht dou you think?
>>>>>>>>>
>>>>>>>>> kp
>>>>>>>> Ok, we may do this. This shouldn't be too complex. Where this option
>>>>>>>> should be (leaf.cfg, kernel boot line, /etc/lrp.conf or somewhere
>>>>>>>> else?).
>>>>>>> I think leaf.cfg would be the most obvious place.
>>>>>>>
>>>>>>> kp
>>>>>> Ok, I'll try to add option to init/hwdetect util in some days. I think
>>>>>> that by default we shouldn't save probed modules to moddb.
>>>>> What about this one?
>>>>> Do you have time to add the code soon?
>>>>>
>>>>> I'd like to have it before we are doing another rc release for 5.2.
>>>>>
>>>>> kp
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel
------------------------------------------------------------------------------
_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
