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. 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. > >> 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. Then, wget takes usually near 0.5 sec per file to connect&get (ftp) - so modules updating will require near 10 minutes. 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. > 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? How many of them will get this module from 3rd-party sources, not by compiling module for their kernel? And for that people we can (ad must) leave moddb - just shrink from moddb all modules from squashfs. >>> 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. > ... > >> Historically tarball was used because modules were uncompressed. > In the real old days there was a module directory on the iso files. But > this was much smaller. > > cheers > > ET > > > > > ------------------------------------------------------------------------------ > 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
------------------------------------------------------------------------------ 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
