Re: 5.2.saving modules problem

Hi

Am 04.07.2015 um 15:59 schrieb Andrew:
> 04.07.2015 16:23, Erich Titl пишет:
>>
>>
>> Am 04.07.2015 um 15:15 schrieb Andrew:
>>> 04.07.2015 15:59, Erich Titl пишет:
>>>> Hi
>>>>
>> ...
>>>>
>>>> Erich
>>> I'm not sure that we should store all modules in moddb by default.
>>> There's no profit for this.
>>
>> Sure there is, detecting dependencies is a fine thing at the first
>> installation or after a hardware or software upgrade, but completely
>> needless for day to day use.
>
> How we can detect, is hardware modules are already probed earlier?

So what, if the hardware is alredy serviced by a module, just leave it, 
I hope hwdetect is clever enough to do that.

Or
> how we can detect software upgrade fact during boot?

You cannot, except if the upgrade has been done by 'upgrade' and then 
this is mostly taken care of. Indeed a new installation may pose 
problems, but then we can just leave away moddb.

Anyway, IMHO there is more reason to keep moddb and populate it 
accordingly than the benefit of automagically detecting stuff. LEAF was 
running fine without hwdetect and all we had was a properly populated 
moddb. I admit detecting the right modules for hardware is a fine thing, 
but it _must_ be the last resort IMHO.

- On new installations this can easily be achieved by just leaving away 
moddb.

- On SW upgrade this is the job of the upgrade procedure and not init.

- On HW uprgade this can be achieved using the module repository in sqfs

- For cutom modules this is the job of the developer and not ours.

So by just changing the order of module loading we could achieve a 
pailess and pretty safe init without giving away the flexibility we had.


>>
...
>>
>> Let's just see, commercial equipment comes with all this and between 4
>> and 16 MB storage only. Also most of the time it has integrated
>> firmware upgrade options. I agree, it is by far not as flexible as
>> LEAF, but it should also be our goal to be KISS for the user. Upgrade
>> has ben written with this goal.
>>
...>
> You're not right - 4-16M is only actual for SOHO 'single-function'
> devices. For ex., Mikrotik (that is also SOHO-class, but with extra
> functional) uses 64M+ NAND flash.

Well, as I stated, these things are not as flexible, still look at the 
TP-Link SoHo stuff... And for what it is built it works quite OK.

>
> Also, support of one platform (like SOHO ones) is much easier than
> support of wide hardware list.

I know, and I see the benefit of hwdetect.

>
> And for correct upgrade we need to have all actual modules somewhere on
> storage, and load them at least on first boot

I disagree, this is the job of the upgrade procedure and not init. But 
if init wants to do this again, be my guest. Currently upgrade does 
populate moddb, like it or not. And yes, upgrade stores modules.sqfs 
just temporarily in RAM.

(to store them later to
> moddb) - else we may have broken system during upgrade, for ex., with
> broken network support which should cause a big headache during remote
> update. So, we should have sqfs on storage. And if we have it on storage
> - IMHO moddb usage becomes unnecessary.

I beg to disagree, hwdetct on an everyday basis is unneccessary and 
keeping a repository of unused modules on storage is unnecessary.

But if we change the init sequence all this can be saved and used 
individually, I would like to see moddb loaded _before_ autoprobing the 
system. If it is missing, and autoprobing cannot be done neither, then 
we bricked the device. In any case this can be avoided by having 
multiple bootable partitions on the system and cloning the system before 
upgrade.

cheers

Erich

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/


_______________________________________________
leaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/leaf-devel