Am 30.03.2015 um 17:09 schrieb kp kirchdoerfer: > Am Montag, 30. März 2015, 16:40:01 schrieb Erich Titl: >> Am 30.03.2015 um 16:10 schrieb kp kirchdoerfer: >>> Hi Erich; >>> ...
>> : > > are in a ? Fingers slower than brain :-( The modules are in a directory tree. > > >>> I prefer you load the tarball, which is easier to maintain during a >>> release >>> and use re-use hwdetect on the router. >> >> No way, the tarball is just too big. > > It might too big for less than xxMB RAM, but it isn't too big itself :) Yes, unless you find a third state for the bit there is not enough xxMB RAM on some systems. > ... >> >> Not really. As of now there are no kernel files nor initrd or initmod. >> This has to be provided in any case, so why not just install them with >> more generic names. > > This requires a lot rework of the toolchains. I don't see anyone who can > accomplish this task right now. IMHO the above should be a one liner in the toolchain. I don't even know which toolchain functions you use to generate a new version in the package directory. > > I also believe that a new feature like upgrades, shouldn't make assumptions > about a rework of a long-proven process, nor it should make the assumption > that someone will work around the issues until the process has been fixed. Right, that is why I left the master branch untouched with the exception of two files which are unused as of now anyway. Everything is as it was before. If you want to use upgrade, everything is in the release branches. If they are missing the system works as before, just upgrade will abort. > >>> And why do you even need the version? Just remove the suffix from >>> linux-xxx. >> I don't need the version, that is why I removed it. The version is just >> there (was just there as the way the stable directory was set up). If >> there is no version number in the future I am fine. > > Remove it when downloaded by the script, otherwise it has to be done manually > for each release. I cannot even find the files if they are named differently all the time. When writing software someone has to set a few generic rules, e.g. a kernel is always named the same way, independent of the version it was created with. > >>> Similar is true for moddb-xxx.lrp, just remove the version when storing >>> the >>> file. >> >> No, because upgrade builds moddb.lrp on the fly based on the modules >> loaded in the running kernel. I don't care about a prebuilt moddb.lrp. > > This could lead to errors, you can foresee yet. > See Andrews remarks. Yes I understand those remarks and the worst that can happen is that support for a piece of hardware is now handled by a completely differently named module. If the kernel people decide to do this there will be an outcry in the community, so I doubt this is relevant at all. If the above should happen it will be just the same if you install the classic manual way. Parts of the hardware may not be supported and you will need to find the new corresponding driver, if there is one at all. Forget about modules.tgz _it_does_not_fit_on_all_our_target_machines_ So IMHO this is really irrelevant. If you want to keep the modules tarballs, this is your choice. Just tell me what is the difference between modules-geode.tgz and modules-i486.tgz? > > I think a longterm solution shouldn't neglect the pre-built moddb.lrp. I doubt its validity as I doubt the validity of initmod.lrp in the geode version. Quite a number of modules in this tarball supports hardware which will hardly ever be built on that platform. The same might be true for the prebuilt moddb.lrp. I am rather convinced that moddb built on the assumption that the modules are named the same will provide better results than a prebuilt moddb. > > As I wrote before, the upgrade process may make use of hwdetect. It does in a way, as it uses the modules it detects on the running system. It cannot guess for dependencies in a system that is not running yet. As an analogon if you are sitting a VW beetle in the late sixties you cannot know about LED headlamps, nor will it be applicable to you. You can consider replacing your spark plugs though and with a little bit of luck the engine will start again. With possibly additional power you may consider changing the brakes but you will need to drive to the next dealer and that requires a running engine. In any case, nobody is forced to use upgrade and as this is open source I invite everyone cordially to improve it. I am sure it can be improved and I am the first to clap my hands. > ...> > Great progress of course! I will try to upgrade my old 4.x WRAP based wireless router, let's see if it crashes :-) BTW.... Can you compile the kernel on master, on my system it crashes miserably DEPMOD 3.10.69-i686 make[1]: Leaving directory `/home/mega/leaf/devel/bering-uclibc/source/i486-unknown-linux-uclibc/linux/linux-i686' find: `/home/mega/leaf/devel/bering-uclibc/build/i486-unknown-linux-uclibc/kernel/lib/modules/3.14.36-i686': No such file or directory ^_<8b>^H^@ q^YU^B^C^C^@^@^@^@^@^@^@^@^@WARNING: Couldn't open directory /home/mega/leaf/devel/bering-uclibc/build/i486-unknown-linux-uclibc/kernel/lib/modules/3.14.36-i686: No such file or directory FATAL: Could not open /home/mega/leaf/devel/bering-uclibc/build/i486-unknown-linux-uclibc/kernel/lib/modules/3.14.36-i686/modules.dep.temp for writing: No such file or directory make: *** [.build] Fehler 1 make: Verlasse Verzeichnis '/home/mega/leaf/devel/bering-uclibc/source/i486-unknown-linux-uclibc/kernel' cheers ET
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
