Re: [leaf-devel] git master
Hi Andrew Am 07.03.2016 um 22:46 schrieb Andrew: > Delayed unmounting is mostly for services that have delayed modules > loading (like wpa-supplicant or hostapd) to ensure that all is ok. If you really want to do this right, then you would need to insert control logic that communicates with the application in a separate protocol if the application wants to talk to you at all. I believe wpasupplicant supports the D-BUS protocol to do this. Then you need quite extensive control logic to do _what_ exactly? To just check that a module was loaded? There are more interesting problems to solve for a LEAF box. Ever heard of the KISS principle? > > + it isn't too complex - just store umount pid and then check in mount - > if pid file exists then kill process instead of mounting sqfs. IMHO it is too complex and simply unnecessary in our case. We don't need another timed control circuit and kill signals are notoriously slow. This is IMHO a solution for a non existing problem. cheers ET -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master
Hi Andrew Am 07.03.2016 um 21:46 schrieb Andrew: > 07.03.2016 20:41, kp kirchdoerfer пишет: ... >> >> Another drawback is the time it needs to load modules.sqfs. >> If we choose to that for several packages it will raise startup times >> significantly. > Delayed umount can solve this. Just terminate sleeping umount process in > next mount - and voila, no umount/mount overhead. This is on an old and really slow WRAP SALT# date; mount_modules ; date ; umount_modules; date Mon Mar 7 21:29:23 UTC 2016 Mon Mar 7 21:29:24 UTC 2016 Mon Mar 7 21:29:24 UTC 2016 Adding complexity here is IMHO completely useless. Your suggested evaluation/kill code takes probably a lot more time. cheers ET -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master
Hi Andrew Am 07.03.2016 um 21:46 schrieb Andrew: > 07.03.2016 20:41, kp kirchdoerfer пишет: >> Am Montag, 7. März 2016, 20:26:58 schrieb Andrew: >>> Maybe we should just mount storage till hostapd will start? >> Will hostapd really load the modules without changes to the init process? > If it loads modules earlier - it should load them now with full-weight > /lib/modules mounted. of course > >> The later is something I try to avoid,cause it will make us to maintain a >> different init for hostapd. >> >> Another drawback is the time it needs to load modules.sqfs. >> If we choose to that for several packages it will raise startup times >> significantly. Please support this with numbers. I don't believe in it. > Delayed umount can solve this. Just terminate sleeping umount process in > next mount - and voila, no umount/mount overhead. Complicated stuff to solve a IMHO non existing problem. cheers ET -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master
07.03.2016 20:41, kp kirchdoerfer пишет: > Am Montag, 7. März 2016, 20:26:58 schrieb Andrew: >> Maybe we should just mount storage till hostapd will start? > Will hostapd really load the modules without changes to the init process? If it loads modules earlier - it should load them now with full-weight /lib/modules mounted. > The later is something I try to avoid,cause it will make us to maintain a > different init for hostapd. > > Another drawback is the time it needs to load modules.sqfs. > If we choose to that for several packages it will raise startup times > significantly. Delayed umount can solve this. Just terminate sleeping umount process in next mount - and voila, no umount/mount overhead. -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master
Hi KP Am 07.03.2016 um 19:41 schrieb kp kirchdoerfer: > Am Montag, 7. März 2016, 20:26:58 schrieb Andrew: >> Maybe we should just mount storage till hostapd will start? > > Will hostapd really load the modules without changes to the init process? I doubt it. > The later is something I try to avoid,cause it will make us to maintain a > different init for hostapd. If we come to the conclusion that an application, and that is what hostapd or wpa_supplicant are, are responsible for the loading of modules, and I am strongly in favour of this behaviour, then yes, we possibly need to patch init. We can go the legacy way and just add it to /etc/modules, which is fine with me too. > > Another drawback is the time it needs to load modules.sqfs. > If we choose to that for several packages it will raise startup times > significantly. Not really, the delays are hardly significant. But this is the current situation, not the future one, so we don't need to discuss this here. I am just reporting the current problems, addressing future solutions will be when I install the new-initrd mode of operation. cheers ET -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master
Sorry, another response Am Montag, 7. März 2016, 20:26:58 schrieb Andrew: > Maybe we should just mount storage till hostapd will start? And what happens if hostpad isn't loaded at all? kp -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master
Am Montag, 7. März 2016, 20:26:58 schrieb Andrew: > Maybe we should just mount storage till hostapd will start? Will hostapd really load the modules without changes to the init process? The later is something I try to avoid,cause it will make us to maintain a different init for hostapd. Another drawback is the time it needs to load modules.sqfs. If we choose to that for several packages it will raise startup times significantly. > Also, maybe it'll be good to add delayed umount (for ex., 3-5 seconds)? > > 07.03.2016 19:06, Erich Titl пишет: > > Hi Folks > > > > OK after some twiddling with buildtool.cfg in master I succeeded to > > build a 486 version. > > > > There are a few quirks in shorewall and specifically we need to add the > > following to /etc/modules in case we want to connect to WPA2 protected > > AP's > > > > # appears to be needed for WPA/WPA2 > > ccm > > ctr Currently those modules are in initmod AFAIK. Adding those to /etc/modules raises the question: - shall they be enbaled by default? - and if so, why don't we add them to the kernel config? > > Now my WRAP based Wireless repeater runs > > > > SALT# cat /etc/motd > > LEAF Bering-uClibc 6.0.0-alpha1 Rev 1 uClibc 1.0.12 at SALT > > Linux 4.4.3-i486 #1 Mon Mar 7 14:26:11 CET 2016 Congrats :) kp -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master
Maybe we should just mount storage till hostapd will start? Also, maybe it'll be good to add delayed umount (for ex., 3-5 seconds)? 07.03.2016 19:06, Erich Titl пишет: > Hi Folks > > OK after some twiddling with buildtool.cfg in master I succeeded to > build a 486 version. > > There are a few quirks in shorewall and specifically we need to add the > following to /etc/modules in case we want to connect to WPA2 protected AP's > > # appears to be needed for WPA/WPA2 > ccm > ctr > > Now my WRAP based Wireless repeater runs > > SALT# cat /etc/motd > LEAF Bering-uClibc 6.0.0-alpha1 Rev 1 uClibc 1.0.12 at SALT > Linux 4.4.3-i486 #1 Mon Mar 7 14:26:11 CET 2016 > > cheers > > ET > > -- > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://makebettercode.com/inteldaal-eval > > ___ > leaf-devel mailing list > leaf-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-devel -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master broken?
Am Montag, 7. März 2016, 11:13:47 schrieb Erich Titl:
> Hi Folks
>
> Is master supposed to compile completely? To me it looks broken.
>
> mega@leafbuilder:~/leaf/devel/bering-6$ git branch
> * master
> new-initrd-6.x
> mega@leafbuilder:~/leaf/devel/bering-6$ git pull
> remote: Counting objects: 31, done.
> remote: Compressing objects: 100% (16/16), done.
> remote: Total 16 (delta 13), reused 0 (delta 0)
> Unpacking objects: 100% (16/16), done.
>
> >From ssh://git.code.sf.net/p/leaf/bering-uclibc
>
>56707d7..c20e020 master -> origin/master
>3c8352d..22fb99f new-initrd-6.x -> origin/new-initrd-6.x
> Updating 56707d7..c20e020
> Fast-forward
> repo/clamav/buildtool.cfg| 2 +-
> repo/clamav/{clamav-0.99.tar.gz => clamav-0.99.1.tar.gz} | Bin 15968038
> -> 15990867 bytes
> 2 files changed, 1 insertion(+), 1 deletion(-)
> rename repo/clamav/{clamav-0.99.tar.gz => clamav-0.99.1.tar.gz} (66%)
> mega@leafbuilder:~/leaf/devel/bering-6$ ./buildtool.pl build hdsupp
> make the list of required source packages:
> linux,kernel,util-linux,e2fsprogs,syslinux,hdsupp [0.K.]
>
> source/package: linux
>
> downloading: buildtool.cfg from server localrepo type filesymlnk [0.K.]
> downloading: kernel-mkmakefile.patch from server localrepo type
> filesymlnk [0.K.]
> downloading: linux-4.4.tar.xz from server localrepo type filesymlnk [0.K.]
> downloading: bitreverse.patch from server localrepo type filesymlnk [0.K.]
> downloading: patch-4.4.2.xz from server localrepo type filesymlnk
> download failed: file
> /home/mega/leaf/devel/bering-6/repo/linux/patch-4.4.2.xz does not exist
>
> you might find useful information in log/buildtoollog
>
Needs to be patch-4.4.3.xz in repo/linux/buildtool.cfg
Fixed in git.
kp
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master
06.03.2016 15:48, Erich Titl пишет: > Am 06.03.2016 um 11:05 schrieb Andrew: >> 4.4 config seems to be re-created from scratch; + currently we use i486 >> as base config - so I moved all changes from i486 cdiff to base config. > That is quite a bit puzzling that the 486 config should be common to all. > > OK IMHO it's easier that maintain abstract 'common config' that isn't correspond to any target so can't be checked at all. >> P.S. it seems like you forgot to commit umount_modules script into repo. > M... possible, it should just be a link to mount_modules though, not > a separate script. Ok. Also question about local.local file - why /lib/firmware local dir was added in such uncommon way? Maybe it'll be better to declare it as 'local' somewhere in package config (like /root dir)? > cheers > > ET > > > -- > > ___ > leaf-devel mailing list > leaf-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-devel -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master
Hi Andrew Am 05.03.2016 um 20:30 schrieb Andrew: > I cleaned configs (there was a lot of strange things - as I understood, > you just build storage drivers in kernel instead of modules, all other > changes are unnecessary?). There should not be any other changes in config, if they are I would like to identify the source. > > Can you review branch diff to master? I looked up the changes just on the web interface. To me, such changes are frightening without an explanation why each of them was done. I am wondering why there should be such a difference on your side, as I started with a clean master this afternoon and the modifications came all from just rebasing. I have no clue what the relationship of new-initrd-6 to master is right now. It used to be built on the configs from maint, so apparently master drifted off quite a bit. cheers ET -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master
Hi Andrew Am 05.03.2016 um 11:54 schrieb Andrew: > Hi. > > I'll try to look on it at this weekend. I believe I made some progress mega@leafbuilder:~/leaf/devel/bering-6$ git status On branch new-initrd-6.x Your branch and 'origin/new-initrd-6.x' have diverged, and have 101 and 17 different commits each, respectively. (use "git pull" to merge the remote branch into yours) nothing to commit, working directory clean This is after the rebase of new-initrd-6 to master. Now if I use pull, all the fixes I made appear to be gone, that cannot be the real purpose. Git log appears to show the correct data after a rebase. So now I pushed a new copy of new-initd-6.x to origin and if you could verify that your changes to master appear correctly I hope to be done. Thanks ET -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master
Hi. I'll try to look on it at this weekend. 05.03.2016 12:51, Erich Titl пишет: > Am 05.03.2016 um 00:57 schrieb kp kirchdoerfer: >> Hi Erich; >> ... >> >> They are not forgotten, they are still used for armv6 toolchain. >> We need to update the raspberry kernel (armv6) to 4.4, until then both kernel >> versions configs are needed to keep the kernel for raspberry pi at 4.1, which >> is known to work. > Then IMHO 4.4 does not belong to master but to an experimental side > branch until it is established :-) > > It is almost impossible to keep synchronized with such a development. As > mentioned before new-initrd-6 cannot safely be rebased due to some > development in master. Unfortunately it difficult to trace development > in git as the individual changes to distinct files are somehow lost in > the maze and cannot easily be reverted (or at least I don't know how > that can be done) > > Maybe someone else has a secure way to rebase new-initrd-6 to master > > cheers > > ET > > -- > > ___ > leaf-devel mailing list > leaf-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-devel -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master
Am 05.03.2016 um 00:57 schrieb kp kirchdoerfer: > Hi Erich; > ... > > They are not forgotten, they are still used for armv6 toolchain. > We need to update the raspberry kernel (armv6) to 4.4, until then both kernel > versions configs are needed to keep the kernel for raspberry pi at 4.1, which > is known to work. Then IMHO 4.4 does not belong to master but to an experimental side branch until it is established :-) It is almost impossible to keep synchronized with such a development. As mentioned before new-initrd-6 cannot safely be rebased due to some development in master. Unfortunately it difficult to trace development in git as the individual changes to distinct files are somehow lost in the maze and cannot easily be reverted (or at least I don't know how that can be done) Maybe someone else has a secure way to rebase new-initrd-6 to master cheers ET -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master
Hi Erich; Am Freitag, 4. März 2016, 22:50:09 schrieb Erich Titl: > Hi Folks > > I am trying to rebase new-initrd to master and failing miserably due to > weird (for me) conflicts. In order to make progress I would like to > suggest to clean up master in a way to be at least consistent with the > actual kernel release, e.g. the person responsable for the introduction > of 4.4 should also wipe 4.1 files. It is quite difficult to navigate > through the minefield of forgotten files otherwise. They are not forgotten, they are still used for armv6 toolchain. We need to update the raspberry kernel (armv6) to 4.4, until then both kernel versions configs are needed to keep the kernel for raspberry pi at 4.1, which is known to work. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
