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
> >> 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
