Am 09.04.2015 um 14:25 schrieb Andrew: > 09.04.2015 14:35, Erich Titl пишет: >> Am 09.04.2015 um 11:12 schrieb Andrew: >>> Hi. >>> >> ... >> >>> For me, it's much easier to update just one file instead of hundreds of >>> modules on persist storage. Esp. when one broken (non-updated) module >>> can break system. >> You can't be serious. If we upgrade, we upgrade the kernel, initrd, >> initmod and of course the kernel modules plus all installed user level >> packages. This is what upgrade does. Nobody is forced to use it. And, >> btw. broken modules exist even inside tarballs :-( > You proposed to fetch all 1236 modules (5.1 branch, i686 release) during > upgrade file-by-file? I think that it's a really bad idea.
I never said that. > Or you proposed to fetch only modules that are currently loaded by > kernel? This is also a bad idea, it'll cause a great headache in future, > when somebody will try to install new wireless (or other) card to his box. We already discussed this. I will reiterate. 1) An upgrade function does _not_ imply hardware modifications. 2) A small box _cannot: hold all modules. It will always be configured with the _necessary_ subset of modules. >> >>> So let's leave modules updating for tiny embedded systems which can't >>> fit module package. >> Why should we? Just because you don't like a directory tree? > Let's calculate. 1236 files on FS with cluster size=4kb will result in > average 2kb per file overhead, or more than 2MB wasted storage space. I don't care about 2MB on the server, I care for the space wasted on the embedded system. > Then, wget takes usually near 0.5 sec per file to connect&get (ftp) - so > modules updating will require near 10 minutes. Yes, it takes the same time to download the full squashfs, and I only download the modules needed. That is quite a difference Or more. > Then, if wget fails on some enough critical module (for ex., library) - > you'll get a broken module dir (modules are here, but part of them are > unusable because one dependent module is compiled for other kernel) and > a big headache if this module is required by driver for NIC that is > connected to Internet. No, because 1) upgrade detects a failure and notified the user 2) upgrade is an add on to a cloning tool which allows to reboot from another partition >> We can either use the unpacked tarball (then I doubt the necessity of >> the tarball as a whole) or use a squashfs. If we decide for the squashfs >> then we ned to adapt a few more things. The unpacked tarball is easier >> because a trained monkey can handle it. You have a directory tree before >> it is tarballed and compressed (which I consider work) Let's not forget, >> this is a programmable computer. > How many people will require custom kernel modules? Ask aroung in the user list, I would guess less than 10. > How many of them will get this module from 3rd-party sources, not by > compiling module for their kernel? See above > And for that people we can (ad must) leave moddb - just shrink from > moddb all modules from squashfs. I am building moddb of course, and for the people requiring extra modules they will be able to include them easily. >>>> On the downside squashfs needs adaptation of busybox and the kernel. >>>> Also we need to create the squashfs files when building the package >>>> directory on the server. >>> Just kernel. AFAIK squash file doesn't need something special for it's >>> mount. >> That is just part of the story. Busybox mount squashfs needs to be enabled. >> >>>> We need to decide >>>> >>>> - do we really need a single file for the modules on the server? >>>> - is a compressed tarball or a squashfs the right solution if there is >>>> to be a single file? >>> Is there a better alternatives than tarball/squashfs for single modules >>> package? >> I don't care for either. I can live with a squashfs, but it means that >> you can only access these files on a system that supports it. I can live >> with that, can everybody? > Why not? Custom modules may (and should) be placed into r/w package like > moddb. They are, but of course they cannot be replaced automatically if they are not in either the tarball, the squashfs or in the modules directory. No method in the world can do this. And this is not a question of flavour. We are talking here about the storage of a few binary files, not how a system can or cannot be upgraded. I have proven that I can, at least with the hardware I have for testing and I am pretty confident that my method is pretty generic. Upgrade warns the user on failure. At that moment he can still decide if he wants to fix the problem. You can of course brick a system if you continue on a broken upgrade. It is the users decision, it is like a red traffic light, you can always ignore it. As I said, I would like a tool to save and restore the whole operating system plus settings on en external system and I am probably going to write one. Right now I save my system to a second partition on the flash disk and I can select at boot time which partition I want to boot from. This has saved me from a lot of grief. So.... - I understand you want to have your tarball, that is fine. - I need access to the modules and I don't want to be restricted by too little space, so I either need the modules directory or a squashfs file. I don't think this is too difficult, it is just utterly redundant. IMHO not bundling the files is the easiest way, but it appears there is a lot of opposition against it and I am too lazy to fight. To avoid redundany we need to replace the tarballs with squashfs files. This forces us to add squashfs support to the kernel and Busybox and of course buildimage and the build environment. There may be other scenarios, but I don't believe they are any better. In the end I just want to reach an agreement on the storage of a few files on a server, not if my ideas are bad or not. "eppur si muove" (Gallilei) ET
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
