[leaf-devel] 6.1 - troubles in syslinux

[Andrew]

Hi all.

It seems like syslinux i LEAF becomes broken - I can't make flash 
bootable with it. I've got 'Error converting to codepage 850 Success' 
error, IMHO it's related to uClibc-ng libiconv.

Anybody tried to make bootable disk from LEAF 6.1? Or from 6.0?


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] kernel 4.9 in master

[Andrew]

buildpacket does not rely on apkg at all; buildpacket creates tarball, 
and apkg extracts it much later.

trouble is here:

 # fetch the numeric uid/gid is user- and group-names were specified
 my ($uid, $gid) = split(/\:/,$ownership);

 if (!isNumeric($uid)) {
  $uid   = getpwnam($uid);
  confess "$uid not in passwd file" unless defined($uid);
 }

 if (!isNumeric($gid)) {
  $gid   = getgrnam($gid);
  confess "$gid not in passwd file" unless defined($gid);
 }

getpwnam/getgrnam, which is used to convert string uid/gid to numeric, 
uses system passwd/group. which is an mistake.

On 29.01.2017 16:19, Erich Titl wrote:
> Hi Andrew
>
> Am 29.01.2017 um 14:33 schrieb Andrew:
>> this is not an apkg issue. it's an buildpacket issue.
>>
>
> Alledgedly buildpacket has requirements that cannot always be met, 
> because apkg cannot or does not set UID/permissions. I see this as a 
> weakness of the packaging system.
>
> cheers
>
> ET
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] kernel 4.9 in master

[Andrew]

this is not an apkg issue. it's an buildpacket issue.

On 29.01.2017 02:38, Erich Titl wrote:
> Hi KP
>
> Am 29.01.2017 um 00:45 schrieb kp kirchdoerfer:
>> Am Samstag, 28. Januar 2017, 10:04:59 schrieb Andrew:
>>> On 28.01.2017 03:30, kp kirchdoerfer wrote:
>>>> Hi Andrew;
>>>>
>>>> Am Freitag, 27. Januar 2017, 20:55:15 schrieb Andrew:
>>>>> Hi.
>>>>>
>>>>> I've fixed perf, it should be built now.
>>>>
>>>> I'm testing...
>>>>
>>>>> Also I noticed one trouble with packaging: when owner/group is set as
>>>>> literal (for ex., www-data), buildpacket.pl tried to resolve it using
>>>>> system passwd file. Which may not correspond to platform passwd...
>>>>
>>>> Do you have an (example) package you refer to?
>>>>
>>>> kp
>>>
>>> lighttpd, vnstats
>>>
>>> I have no local www-data user, and packaging fails.
>>
>> Can you pls try to change user/group "www-data" in lighttpd 
>> buildtool.cfg with
>> "33"?
>
> Wouldn't this be a clear case for a install procedure? Shouldn't we 
> better enable apkg to handle such a situation?
>
> cheers
>
> ET
>
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] kernel 4.9 in master

[Andrew]

On 28.01.2017 03:30, kp kirchdoerfer wrote:
> Hi Andrew;
>
> Am Freitag, 27. Januar 2017, 20:55:15 schrieb Andrew:
>> Hi.
>>
>> I've fixed perf, it should be built now.
> I'm testing...
>
>> Also I noticed one trouble with packaging: when owner/group is set as
>> literal (for ex., www-data), buildpacket.pl tried to resolve it using
>> system passwd file. Which may not correspond to platform passwd...
> Do you have an (example) package you refer to?
>
> kp
lighttpd, vnstats

I have no local www-data user, and packaging fails.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] kernel 4.9 in master

[Andrew]

Hi.

I've fixed perf, it should be built now.

Also I noticed one trouble with packaging: when owner/group is set as 
literal (for ex., www-data), buildpacket.pl tried to resolve it using 
system passwd file. Which may not correspond to platform passwd...

On 15.01.2017 18:35, kp kirchdoerfer wrote:
> Hi all;
>
> I've committed a 4.9.(3) kernel to master for review.
>
> While I believe we should wait for an official new LTS kernel (probably 4.10),
> upgrading the kernel to 4.9 made me aware of missing and failing packages
> (ipt-netflow, igb,...), the only remaining package to fail is perf.lrp. And
> hopefully it will be easier to upgrade to 4.10, once we ironed out errors with
> the 4.9 kernel.
>
> Note: Currently the arm* toolchains do not build with with the 4.9 kernel.
>
> Please review the configs for x86_64, i486, geode etc..
>
> Andrew maybe you can look into perf and fix it?
>
> I'm currently running the x86_64 kernel, and it seems to work pretty well.
>
> regards kp
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] leaf upgrade versioning

[Andrew]

hi.

about versioning:

 The current proposed translation is:
 
 5.2.8 -> 52800
 6.0.0 -> 6
 6.0.0-minorfix -> 60001
 6.0.1-beta1 -> 60010
 6.0.1-rc-1 -> 60020
 6.0.1 -> 60100
 6.0.1-minorfix -> 60101
 6.0.2-beta1 -> 60110

this limits versioning to max 10 releases per branch. I think that it'll be 
better to use 2 digits per release (for ex., 5020800).


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] intel network drivers

[Andrew]

On 03.10.2016 11:45, kp kirchdoerfer wrote:
> Am Montag, 3. Oktober 2016, 10:41:05 schrieb Andrew:
>> On 02.10.2016 23:37, Erich Titl wrote:
>>> Hi Andrew
>>>
>>> Am 02.10.2016 um 19:58 schrieb Andrew:
>>>> On 02.10.2016 20:45, Erich Titl wrote
>>>>
>>> :...
>>> :
>>>>> We need to find out if this is an issue for the majority of our users.
>>>>> most of the drivers will probably just work as they work in standad
>>>>> distros.
>>>> This is issue for everybody who uses intel server cards in high-load
>>>> applications.
>>> Yes and this is why I asked if this was an issue for the _majority_
>> I don't know statistics how much people uses LEAF as home box/small
>> office router, and how much people uses LEAF somewhere in production
>> environment with high traffic.
>> I know at least some people who uses LEAF in production (access
>> servers/borders/etc), and I know only one case of usage as office
>> router(just because soho router in that place frequently hangs).
>>
>>> ...
>>>
>>>> Actually intel NIC card is the only available choice for high-troughput
>>>> routing. Other cards have too high CPU usage, or starts to drop packets
>>>> at 60-70% of bandwidth usage.
>>> So on a Gbit card you would have a throughput of roughly 600 Mbit. For
>>> most users and I said _most_ users they will never be able to buy that
>>> much power.
>>>
>>> And unless you have a massive parallel system you will have difficulties
>>> to pass that much data through any kind of traffic management. I
>>> observed issues in that aera, never at NIC level.
>>>
>>> So - yes, if it isn't a home routing box,
>>>
>>>> it uses Intel NIC.
>>> Still the same question, is this an issue for the majority and therefore
>>> a killer criterion? It might well be so, but I would like to know numbers.
>>>
>>> I for once do not have any intel NICs in usage, but yes, I did use them
>>> a few years back and might have been happy to have hight troughput, but;
>>> even then I never had a saturation issue at hand. YMMV
>>>
>>> Still I would not consider it a killer criterion, but yes, if someone is
>>> willing to put in the effort to overcome limitations in that area,
>>> great. I understand that you are working in a high speed/throughput
>>> environment and there I see of course the usefulness of having
>>> specialized drivers, but I _guess_ the majority of our users are not
>>> limited there. They have problems in the integration of some of our
>>> packages as seen lately in the leaf-user list.
>>>
>>> cheers and yes, please if you have spare time to integrate those
>>> drivers, go for it.
>>>
>>> ET
>> It isn't too hard to integrate them. I'll try to update drivers to
>> latest version in master (which is 4.4-based), because there's no
>> 4.7-based branch in git.
> This was meant as testing what has to be done when moving to a newer kernl,
> prefrrably a LTS as well.
> And it occured that migrations issues will be with e1000e and igb.
>
> There will be enough time to solve once we move on.
>
> kp
Hi.

Drivers update seems to be trivial - I just placed new archives, and 
removed some compat patches (that were added because driver fails to 
built with 4.4 kernel). If all will be built OK, I'll push changes.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] intel network drivers

[Andrew]

On 02.10.2016 23:37, Erich Titl wrote:
> Hi Andrew
>
> Am 02.10.2016 um 19:58 schrieb Andrew:
>> On 02.10.2016 20:45, Erich Titl wrote
> :...
>>> We need to find out if this is an issue for the majority of our users.
>>> most of the drivers will probably just work as they work in standad
>>> distros.
>> This is issue for everybody who uses intel server cards in high-load
>> applications.
> Yes and this is why I asked if this was an issue for the _majority_
I don't know statistics how much people uses LEAF as home box/small 
office router, and how much people uses LEAF somewhere in production 
environment with high traffic.
I know at least some people who uses LEAF in production (access 
servers/borders/etc), and I know only one case of usage as office 
router(just because soho router in that place frequently hangs).
> ...
>
>> Actually intel NIC card is the only available choice for high-troughput
>> routing. Other cards have too high CPU usage, or starts to drop packets
>> at 60-70% of bandwidth usage.
> So on a Gbit card you would have a throughput of roughly 600 Mbit. For
> most users and I said _most_ users they will never be able to buy that
> much power.
>
> And unless you have a massive parallel system you will have difficulties
> to pass that much data through any kind of traffic management. I
> observed issues in that aera, never at NIC level.
>
> So - yes, if it isn't a home routing box,
>> it uses Intel NIC.
> Still the same question, is this an issue for the majority and therefore
> a killer criterion? It might well be so, but I would like to know numbers.
>
> I for once do not have any intel NICs in usage, but yes, I did use them
> a few years back and might have been happy to have hight troughput, but;
> even then I never had a saturation issue at hand. YMMV
>
> Still I would not consider it a killer criterion, but yes, if someone is
> willing to put in the effort to overcome limitations in that area,
> great. I understand that you are working in a high speed/throughput
> environment and there I see of course the usefulness of having
> specialized drivers, but I _guess_ the majority of our users are not
> limited there. They have problems in the integration of some of our
> packages as seen lately in the leaf-user list.
>
> cheers and yes, please if you have spare time to integrate those
> drivers, go for it.
>
> ET
It isn't too hard to integrate them. I'll try to update drivers to 
latest version in master (which is 4.4-based), because there's no 
4.7-based branch in git.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] intel network drivers

[Andrew]

On 02.10.2016 20:45, Erich Titl wrote:
> Hi
>
> Am 02.10.2016 um 18:36 schrieb kp kirchdoerfer:
>> Hi;
>>
>> Am Sonntag, 2. Oktober 2016, 19:29:37 schrieb Andrew:
>>> Hi.
>>>
>>> Built-in drivers have much less parameters. For ex., interrupt
>>> throttling, etc.
> We need to find out if this is an issue for the majority of our users.
> most of the drivers will probably just work as they work in standad
> distros.
This is issue for everybody who uses intel server cards in high-load 
applications.

>
>> Is this also true for kernel driver 4.7+?
>>
>> If so, we'll need certainly need to fix the buildtoo setup, when moving to a
>> newer kernel.
> We are not yet at 4.4 for stable and I am wondering if the intel drivers
> are used by a huge user base. If someone thinks he needs to twiddle the
> net parameters in extensive ways I would suggest to invite him to port
> those drivers. Our environment is good enough to provide all the
> necessary tools. If the need is not there then IMHO this is a waste of
> development resources, which are scarce.
>
> cheers
>
> ET
Actually intel NIC card is the only available choice for high-troughput 
routing. Other cards have too high CPU usage, or starts to drop packets 
at 60-70% of bandwidth usage. So - yes, if it isn't a home routing box, 
it uses Intel NIC.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] intel network drivers

[Andrew]

On 02.10.2016 19:36, kp kirchdoerfer wrote:
> Hi;
>
> Am Sonntag, 2. Oktober 2016, 19:29:37 schrieb Andrew:
>> Hi.
>>
>> Built-in drivers have much less parameters. For ex., interrupt
>> throttling, etc.
> Is this also true for kernel driver 4.7+?
I think yes. You may try to look in source.
> If so, we'll need certainly need to fix the buildtoo setup, when moving to a
> newer kernel.
Just update e1000e/igb drivers, + fix other kernel-related packages.
> kp
>
>> On 02.10.2016 19:25, kp kirchdoerfer wrote:
>>> Hi;
>>>
>>> I've had some spare time and was looking at what is ahead .
>>>
>>> I've updated for testing uclibc-ng to 1.0.18 (which seems about 100 kb
>>> smaller) and kernel 4.7.6 (which seems about 100 kb larger).
>>>
>>> A few packages are failing to compile - notably ipt-netflow (looking into
>>> the src repository it claims to be for kernel up to 4.4; and both
>>> packages providing Intel network drivers  (igb and e1000e) fail to build.
>>>
>>> Is there any advantage to use these compared to the ones in the kernel
>>> source?
>>>
>>> kp
>>>
>>> --
>>>  Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>
>>> ___
>>> leaf-devel mailing list
>>> leaf-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/leaf-devel
>> 
>> -- Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>
>> ___
>> leaf-devel mailing list
>> leaf-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/leaf-devel
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel



--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] intel network drivers

[Andrew]

Hi.

Built-in drivers have much less parameters. For ex., interrupt 
throttling, etc.

On 02.10.2016 19:25, kp kirchdoerfer wrote:
> Hi;
>
> I've had some spare time and was looking at what is ahead .
>
> I've updated for testing uclibc-ng to 1.0.18 (which seems about 100 kb
> smaller) and kernel 4.7.6 (which seems about 100 kb larger).
>
> A few packages are failing to compile - notably ipt-netflow (looking into the
> src repository it claims to be for kernel up to 4.4; and both packages
> providing Intel network drivers  (igb and e1000e) fail to build.
>
> Is there any advantage to use these compared to the ones in the kernel source?
>
> kp
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel



--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] linux-headers

[Andrew]

Hi.

No, I just reassembled kernel headers tarball while trying to fix perf. 
It didn't help, but I've already committed it.

On 30.07.2016 19:04, kp kirchdoerfer wrote:
> Hi Andrew;
>
> I saw you committed new linux-headers to toolchain.
> Just out of interest, has there been anythin wrong with the tarball I
> committed a few days ago, and if so what have I done wrong?
>
> I did
> #./buildtool.pl headers linux
> #cd headers/include
> #tar cvfJ  repo/toolchain/linux-headers.tar.xz headers/include/
>
> I'll add a note to the deveoper wiki pages, if that the way to go or a
> corrected procedure if needed.
>
> kp
>
>
>
> --
>
> ___
> 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] 6.0.0-beta

[Andrew]

28.07.2016 19:31, kp kirchdoerfer пишет:
> Hi Andrew;
>
> Am Donnerstag, 28. Juli 2016, 12:24:58 schrieb Andrew:
>> Hi.
>>
>> I think that we should move root, config and maybe some other 'core'
>> packages to initrd - to make it possible to run on tiny systems with
>> small amount of RAM and available persistent ROM for permanently mounted
>> initrd (like SOHO routers).
> Looks almost like a packaging task, or am I wrong?
Yes, it's mostly packages reorganization. Simple, but very important 
step. Other step - use r/o squash + r/w tmpfs over the top on it if 
kernel option is specified - slightly harder, but harmless and may be 
done even after first beta.

Maybe we even should move iptables here too - IMHO in 95% use cases 
iptables is used.
> Do you expect space savings or just simplification?
I don't think that it'll have significant space changing. Maybe +-20-30kb.
>
> I think the most important task for very small platforms is to get rid of
> modules.sqfs.
> E.g. the modules for rpi kernel is still 4.9MB, and of course it can be
> reduced nect to zero, if decisions are made what devices will be supoorted and
> what not - though rpi is still an somewhat open platform and with enough space
> on the CF and RAM, so I'm not bothered too much; but for closed SOHO routers
> this won't be acceptable.
We'll target to SOHO routers with USB - boxes w/o USB (esp. with 4M ROM) 
aren't too perspective for LEAF, OpenWRT better fits there.

About modules.sqfs - IMHO it'll be a good idea to try to mount it till 
modprobing + add delayed umount to prevent needless umount/mount on each 
module.

Basically we should build SoC/platform 'core' modules (important ones 
that are 99% used - for ex., storage, wired network) as 
statically-linked to save space and to make maintaining easier.

> Not shure if we should add it to 6.0.0 (for a beta), but if we do make steps
> forward it could be at least for 6.1.0, which could be targeted until end of
> year if things goes well.
> Will you try in a new branch??
>
Yes, I'll try to look on it.

> For 6.0.0 an issue with perf needs to be solved, may I ask you to have a look
> at it first?
>   
Ok, I'll look on this package on this week.

>> Also, on beta release we should also freeze uClibc-ng version for this
>> branch.
> Agreed.
>
> kp
>


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] 6.0.0-beta

[Andrew]

Hi.

I think that we should move root, config and maybe some other 'core' 
packages to initrd - to make it possible to run on tiny systems with 
small amount of RAM and available persistent ROM for permanently mounted 
initrd (like SOHO routers).

Also, on beta release we should also freeze uClibc-ng version for this 
branch.

27.07.2016 20:03, kp kirchdoerfer пишет:
> Hi all;
>
> I've comitted changes to support the linux 4.4.x kernel for raspberry pi
> boards rev 1.
> While the raspberry pi 1 was mainly a proof-of-concept, we now support all the
> platforms that we did with 5.2.x.
> With the changes for rpi rev 1, we do have an example how to support booting
> architectures depending on device trees (and overlays) - though it shurely can
> be improved.
>
> Done that it, I think we are on the way to a first beta version for 6.0.0.
> Therefor I'd like to pint you to some errors during a complete build amd
> packaging of the sources in git.
>
> There aren't many, but
>   
> perf  fails to build
> initmod fails to build (no surprise, as we do not need initmod anymore)
> ... maybe i forgot one more?
>
>
> Any help to fix that errors are welcome.
>
> Any ideas what should be accomplished before moving forward to a first beta?
>
> regards kp
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity planning
> reports.http://sdm.link/zohodev2dev
>
> ___
> 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] init problem sda1 still mounted

[Andrew]

Trouble is present when install script installs data on pre-formatted 
flash, or when it formats flash by itself?

When script formats flash - it sets root dir size to 1024, and all is 
work OK.

When flash was formatted by calling mkfs.vfat w/o args - file copying 
fails because rootdir becomes full.

 From other side, we may place packages in subdirectory, and there'll be 
no troubles with FAT in future :)

10.04.2016 22:51, Erich Titl пишет:
> Am 10.04.2016 18:37, schrieb Andrew:
> ...
>>> kp
>> 128MB DOM and 256-512MB flash works OK.
>>
>> As I understood, trouble happens on flash that is formatted manually...
> What difference does that make? Don't we pass the right parametres?
>
> cheers
>
> ET
>
>
>
> --
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
> gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] init problem sda1 still mounted

[Andrew]

10.04.2016 16:28, kp kirchdoerfer пишет:
> Hi;
>
> Am Samstag, 9. April 2016, 14:23:31 schrieb Erich Titl:
>> Hi KP
>>
>> Am 09.04.2016 10:44, schrieb kp kirchdoerfer:
>>> Hi;
>>>
>>> I've booted LEAF 6.0.0-alpha1 iso image in a vm with an attached (virtual)
>>> hd. If the disk is partitioned and formatted it will be mounted during
>>> boot, but never umounted.
>>>
>>> mount shows
>>> /dev/sda1 on /tmp/tmp.kci8fg type vfat etc
>>>
>>> This shouldn't happen.
>>> I suspect the problem is in linuxrc/init.
>> Yes I guess this is possible. Probably something that is not checked in
>> the current linuxrc. I have never used a CD image so I would not know.
>>
>>> Any ideas how to solve?
>> Need to look into linuxrc, where this should be umounted. As I forgot
>> the charger for my other laptop, I have no access to the source code, sorry.
> Are you away for a few days, or will it have to wait until end of summer?
>
>> On the otherr tread about the amount of directory/FAT table entries.
>> Nobody will ever need all the LEAF packages, so copying all of them is
>> plain crazyness. Upgrade could provide a solution, elsse maybe the
>> images should just hold the basic packages and we should point to a
>> package repository. This would make thesee errors go away.
> It will not help, if a user loads more packages than the ~80MB limit, or less
> if he'll add a unknown amount packages with long names(?), from a packages
> repository.
>
> It's a flaw, we have to solve otherwise.
>
> We solved that limitation in install.sh, though I don't know what happens if a
> user installs from ISO image to a 1GB partition, with a command setting root-
> dir-entries to 1024 - for FAT32 it's to 0/ignored.
>
> Probably the solution should be to make ext2/3/4 the default instead of
> VFAT...?
>
> kp
128MB DOM and 256-512MB flash works OK.

As I understood, trouble happens on flash that is formatted manually...

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] more obscure menu items

[Andrew]

02.04.2016 10:48, Erich Titl пишет:
> Hi Andrew
>
> Am 02.04.2016 um 00:37 schrieb Andrew:
>> 31.03.2016 23:30, Erich Titl пишет:
>>> Hi KP
>>>
>>> some more bugging
>>>
>>>
>>>   Network configuration menu
>>>
>>>   1) interfaces file
>>>   2) hosts IP adresses
>>>   3) hostname
>>>   4) resolv.conf
>>>   5) superserver daemon configuration
>>>   6) hosts.allow
>>>   7) hosts.deny
>>>   8) networks
>>>
>>> q) quit
>>>
>>> 
>>>   Selection:
>>>
>>> I tried 1) and I believe the interface configuration in webconf is way
>>> better
>> it's usual Debian-like network config file. and it's really flexible
>> (e.g. you may specify pre-up/up/down actions, configure bridges/vlans
>> and so on).
>>
>> webconf is good for home routers, but home routers isn't a single target
>> for LEAF.
> You are right, but this is mostly due to the fact that the webconf
> interface does not attract our developers. Maybe the fact that it is
> written in shell keeps them away. Even big Cisco and HP routers/switches
> have quite powerful web interfaces.
AFAIK Cisco 65xx/76xx/ASR/etc are configured just via CLI. For ex: 
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/xe-3s/asr1000/dhcp-xe-3s-asr1000-book/config-dhcp-server-xe.html
 


And that is not even close to reality as can be seen above. The menu
item is plain misleading.

>> it's content of /etc/hosts.
> Yes and the menu entry is completely misleading.
It comes from 3.x (or older) version w/o changes.

How it should be named for more clear understanding?

>> If you want to see some diag info - IMHO it'll be good to add separate
>> section with diag commands (like 'ip a' or 'iptraf' if it's available).
>> but it's easier to enter these commands in shell.
> That is what I normally do, because I am quite familiar with the shell.
>
> - The menu entries are partially misleading and not always useful
> - I just hate the editor called in the menu, so I prefer to use vi, but
> that is a very personal choice.
you can configure which editor you want to use.
> cheers
>
> ET
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] more obscure menu items

[Andrew]

31.03.2016 23:30, Erich Titl пишет:
> Hi KP
>
> some more bugging
>
>
>  Network configuration menu
>
>  1) interfaces file
>  2) hosts IP adresses
>  3) hostname
>  4) resolv.conf
>  5) superserver daemon configuration
>  6) hosts.allow
>  7) hosts.deny
>  8) networks
>
>q) quit
>
> 
>  Selection:
>
> I tried 1) and I believe the interface configuration in webconf is way
> better
it's usual Debian-like network config file. and it's really flexible 
(e.g. you may specify pre-up/up/down actions, configure bridges/vlans 
and so on).

webconf is good for home routers, but home routers isn't a single target 
for LEAF.

> Then I tried 2) expecting to see the following
>
> 3: eth0:  mtu 1500 qdisc pfifo_fast
> master br0 state DOWN group default qlen 1000
>  link/ether 00:0d:b9:04:6e:d8 brd ff:ff:ff:ff:ff:ff
> 4: wlan0:  mtu 1500 qdisc mq state UP
> group default qlen 1000
>  link/ether 00:0b:6b:36:bb:cd brd ff:ff:ff:ff:ff:ff
>  inet 194.124.158.69/24 brd 194.124.158.255 scope global wlan0
> valid_lft forever preferred_lft forever
> 5: wlan1:  mtu 1500 qdisc mq master br0
> state UP group default qlen 1000
>  link/ether 00:0b:6b:33:1e:23 brd ff:ff:ff:ff:ff:ff
> 8: br0:  mtu 1500 qdisc noqueue state
> UP group default qlen 1000
>  link/ether 00:0b:6b:33:1e:23 brd ff:ff:ff:ff:ff:ff
>  inet 192.168.217.1/24 brd 192.168.217.255 scope global br0
> valid_lft forever preferred_lft forever
>
> but I was presented with
>
> 127.0.0.1   localhost
> 192.168.1.254   firewall
>
> # The following lines are desirable for IPv6 capable hosts
> ::1 ip6-localhost ip6-loopback
> fe00::0 ip6-localnet
> ff00::0 ip6-mcastprefix
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
> ff02::3 ip6-allhosts
>
> And that is not even close to reality as can be seen above. The menu
> item is plain misleading.
it's content of /etc/hosts.

If you want to see some diag info - IMHO it'll be good to add separate 
section with diag commands (like 'ip a' or 'iptraf' if it's available). 
but it's easier to enter these commands in shell.

> Then I just grumbled and stopped
>
> cheers
>
> ET
>
>
>
>
>
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Delayed umount

[Andrew]

It just blocks killing on console logout (IMHO it'll be bad if all 
remains mounted after logout). It oesn't hurt TERM/KILL signals.

31.03.2016 11:35, Erich Titl пишет:
> Am 31.03.2016 um 10:30 schrieb Andrew:
>> 31.03.2016 01:32, Erich Titl пишет:
>>> Am 30.03.2016 um 17:20 schrieb Andrew:
>>>> 30.03.2016 17:17, Erich Titl пишет:
> ...
>> Command can push itself in background. Something like this:
>>
>> if [ "$1" == "--nofork" ]; then
>>   umount all fs here
>> else
>>   nohup $0 --nofork &
>> endif
> nohup is probably not a good idea it might block the killing
>
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Delayed umount

[Andrew]

31.03.2016 01:32, Erich Titl пишет:
> Am 30.03.2016 um 17:20 schrieb Andrew:
>> 30.03.2016 17:17, Erich Titl пишет:
> ...
>>> There are a few drawbacks with the invocation
>>>
>>> - umount_delayed must be pushed to the background to terminate
>> it may call itself with some parameter (that indicates that it's fork)
>> and if parameter is present - do delayed umunt, if not - run itself in
>> background with parameter via nohup (to be sure that all is umounted
>> even if console is terminated).
> Maybe I was not clear enough. The calling process needs to push the
> umount command to the background to make sure it can continue its own
> process. Else it will wait for the termination of the called process.
Command can push itself in background. Something like this:

if [ "$1" == "--nofork" ]; then
 umount all fs here
else
 nohup $0 --nofork &
endif

> cheers
>
> ET
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Delayed umount

[Andrew]

30.03.2016 17:17, Erich Titl пишет:
> Hi Folks
>
> I am not convinced this is necessary but it does not hurt, so I added
> another function to mount_modules to allow delayed umount
>
> Tests show
>
> SALT# mount_modules
> SALT# umount_modules
> SALT# mount_modules
> SALT# umount_delayed &
> SALT# mount_modules
> SALT# umount_delayed &
> [1]-  Terminated umount_delayed
> [2]+  Done   umount_delayed
>
> Mar 30 13:55:29 SALT mount_modules: mounted /dev/sda2 on /tmp/tmp.GVlxkl
> Mar 30 13:55:38 SALT umount_delayed: unmount of /lib/modules/4.4.3-wrap
> scheduled in 10 seconds
> Mar 30 13:55:45 SALT mount_modules: killing umount_delayed process-id=17932
> Mar 30 13:55:55 SALT umount_delayed: unmount of /lib/modules/4.4.3-wrap
> scheduled in 10 seconds
> Mar 30 13:56:05 SALT umount_modules: unmounted /lib/modules/4.4.3-wrap
> Mar 30 13:56:06 SALT umount_modules: unmounted /tmp/tmp.GVlxkl
>
> There are a few drawbacks with the invocation
>
> - umount_delayed must be pushed to the background to terminate
it may call itself with some parameter (that indicates that it's fork) 
and if parameter is present - do delayed umunt, if not - run itself in 
background with parameter via nohup (to be sure that all is umounted 
even if console is terminated).
> - processes in the background spit out termination messages
this isn't a trouble.
> cheers
>
> ET
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] What about removing moddb?

[Andrew]

28.03.2016 23:13, Erich Titl пишет:
> Am 27.03.2016 um 18:26 schrieb kp kirchdoerfer:
>> Am Sonntag, 27. März 2016, 16:03:06 schrieb Erich Titl:
>>> Hi KP
>>>
>>> Am 26.03.2016 um 16:55 schrieb kp kirchdoerfer:
 H Gents;
>>> ...
>>>
 At last I changed hwdetect to neglect moddb, and to do not use
 /var/lib/lrpkg/*.depmod any  longer - there is no need to copy modules to
 /lib/modules any more.
>>> IMHO we could also ditch hwdetect. There is hardly any difference in the
>>> code than in linuxrc. WE might need to add mount_modules to the hotplug
>>> script though.
>> hotplug seems not to be a replacement for hwdetect.
>>
>> Yes the hwdetect code is in linuxrc, but as I said it could be convenient to
>> run hwdetect and load modules *without reboot*.
> What for? It is highly unlikely the hardware configration changes on a
> running machine. The only place I could see this is with unknown usb
> hardware. But then hwdetect needs to mount modules.
Yes, mostly USB, or pcmcia/expresscard/firewire (which is less common 
for routers).

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] ALIX specific kernel

[Andrew]

I'm not sure that it's really will be a big difference between all 
CS553x drivers enabled and CS5535-only driver...

15.03.2016 18:32, Erich Titl пишет:
> Hi KP
>
> Am 15.03.2016 um 17:28 schrieb kp kirchdoerfer:
>> Hi Erich;
>>
> ...
>> Just to be clear I don't argue against a seperate WRAP image, until it's
>> proofed to be outdated by download stats.
>> But I'm questioning seperate images for ALIX and Geode.
> That is fine. But then I _believe_ the geodes all use the same PATA
> companion chips, so we might really restrict them there too. Seeing the
> difference in size, it hardly matters. I just don't like to include dead
> code.
>
> ET
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

I'm not sure that it even requires intrusion... it seems like storage 
drivers are compiled as built-in.

It'll require more testing on live hardware/emulator to ensure this.

15.03.2016 00:55, Erich Titl пишет:
> Am 14.03.2016 um 23:07 schrieb LEAF Linux Embedded Appliance Framework
> Git repository:
>>  Branch: new-initrd-6.x
>>
>> linux: revert changes for versatile/bcmrpi configs
>>
>> it seems like configs are completely wrong, taretted to x86_64
> Very possible as marked in the comment to those changes. If the diff
> stuff works, it should be easy though to work out the correct configs.
>
> Thanks
>
> ET
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] ALIX specific kmodules

[Andrew]

These files are for moddb/initmod. It seems like we should clean them 
after merge your changes.

14.03.2016 19:22, Erich Titl пишет:
> Am 14.03.2016 um 17:28 schrieb Andrew:
>> Hi.
>>
>> modules-xxx.sqfs is built for each subarch specified in makefile.
> What are the files applied to each subarch and how are they
> defined/generated?
>
> mega@leafbuilder:~/leaf/devel/bering-6/source/i486-unknown-linux-uclibc/kmodules$
> ls
> buildtool.cfg  common-kmod.geode  files.geode  mod.geode
> modulelist.i486
> buildtool.mk   common-kmod.i486   files.i486   mod.i486
> modulelist.i686
> common.geode   common-kmod.i686   files.i686   mod.i686
> modulelist.pcie
> common.i486common-kmod.tplfirmware.common  modulelist.common
> package.cfg
> common.i686common.tpl Makefile modulelist.geode
> specific.geode
>
>
> Thanks
>
> ET
>
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] ALIX specific kernel

[Andrew]

Hmm, right, it wasn't a master, it was new-initrd-6.x. It still didn't 
merged in master.

14.03.2016 19:09, Erich Titl пишет:
> Hi Andrew
>
> Am 14.03.2016 um 17:24 schrieb Andrew:
>> It seems like you do something wrong. Because in master these modules
>> are already compiled in kernel:
> Mhhh... this is master
>
> mega@leafbuilder:~/leaf/devel/bering-6/repo/linux$ git branch
> * master
>new-initrd-6.x
> mega@leafbuilder:~/leaf/devel/bering-6/repo/linux$ grep CS553
> Bering-4.4.config-geode
> CONFIG_CS5535_MFGPT=m
> CONFIG_PATA_CS5530=m
> CONFIG_PATA_CS5535=m
> CONFIG_PATA_CS5536=m
> CONFIG_GPIO_CS5535=m
> CONFIG_MFD_CS5535=m
> CONFIG_SND_CS5530=m
> CONFIG_SND_CS5535AUDIO=m
> CONFIG_CS5535_MFGPT_DEFAULT_IRQ=7
> CONFIG_CS5535_CLOCK_EVENT_SRC=m
>
> mega@leafbuilder:~/leaf/devel/bering-6/repo/linux$ git checkout
> new-initrd-6.x
> Switched to branch 'new-initrd-6.x'
> Your branch is up-to-date with 'origin/new-initrd-6.x'.
>
> mega@leafbuilder:~/leaf/devel/bering-6/repo/linux$
> ../../tools/confpatch.py Bering-4.4.config Bering-4.4.config-geode.cdiff
>> Bering-4.4.config-geode
> mega@leafbuilder:~/leaf/devel/bering-6/repo/linux$ grep CS553
> Bering-4.4.config-geode
> CONFIG_CS5535_MFGPT=m
> CONFIG_PATA_CS5530=y
> CONFIG_PATA_CS5535=y
> CONFIG_PATA_CS5536=y
> CONFIG_GPIO_CS5535=m
> CONFIG_MFD_CS5535=m
> CONFIG_SND_CS5530=m
> CONFIG_SND_CS5535AUDIO=m
> CONFIG_CS5535_MFGPT_DEFAULT_IRQ=7
> CONFIG_CS5535_CLOCK_EVENT_SRC=m
>
> You are right, I was in master when I checked, not in new-initrd.
>
> Thanks
>
> ET
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] ALIX specific kmodules

[Andrew]

Hi.

modules-xxx.sqfs is built for each subarch specified in makefile.

14.03.2016 17:55, Erich Titl пишет:
> Hi Folks
>
> The code generating kmodules/modules-karch.sqfs is quite cryptic and I
> don't really want to play a guessing game on how it works. What do I
> have to do in kmodules to get modules-xxx.sqfs built? It appears the
> documentation lacks a bit there.
>
> Thanks
>
> ET
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] ALIX specific kernel

[Andrew]

It seems like you do something wrong. Because in master these modules 
are already compiled in kernel:

# grep CS553 .config
CONFIG_CS5535_MFGPT=m
CONFIG_CS5535_MFGPT_DEFAULT_IRQ=7
CONFIG_CS5535_CLOCK_EVENT_SRC=m
*CONFIG_PATA_CS5530=y**
**CONFIG_PATA_CS5535=y**
**CONFIG_PATA_CS5536=y*
CONFIG_GPIO_CS5535=m
CONFIG_MFD_CS5535=m
CONFIG_SND_CS5530=m
CONFIG_SND_CS5535AUDIO=m


14.03.2016 17:35, Erich Titl пишет:
> Hi Andrew
>
> Am 14.03.2016 um 16:30 schrieb Andrew:
>> Strange. Maybe you didn't specify ARCH=i386 in command line on x86_64?
> I started with the config for geode, which is running on ALIX. Now the
> current config is aimed at loading CS5536 as a module, not compiled into
> the kernel.
>
> What is needed to compile the code into the kernel is the following
>
> < -# CONFIG_COMPILE_TEST is not set
> < +CONFIG_COMPILE_TEST=y
>
> cheers
>
> ET
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] ALIX specific kernel

[Andrew]

Strange. Maybe you didn't specify ARCH=i386 in command line on x86_64?

14.03.2016 15:50, Erich Titl пишет:
> Am 14.03.2016 um 14:15 schrieb Erich Titl:
>> Hi Folks
>>
>> I am trying to build a specific kernel for the ALIX board, but I am
>> failing configuring the CS553x ATA driver into the kernel, e.g. the
>> driver can be enabled as a module but menuconfig does not allow it to be
>> compiled into the kernel.
>>
>> Am I missing some prerequisite here?
> Found it, it needs the ability to compile drivers for non existing HW.
>
> cheers
>
> ET
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] usefullness of kernel config cdiff files

[Andrew]

14.03.2016 14:45, Erich Titl пишет:
> Am 14.03.2016 um 13:32 schrieb Andrew:
>> 14.03.2016 12:28, Erich Titl пишет:
>>> Hi Andre
>>>
>>> Am 12.03.2016 um 19:40 schrieb Andrew:
>>>> Hi.
>>> ...>>
>>>>> Please let us know how you do a major kernel upgrade. If you write it
>>>>> down, you might see that there are unnecessaty steps or you may
>>>>> convince me that the diff files are valuable.
>>>>>
>>>> 1. Upgrade kernel version, copy configs,
>>> Will you have to generate the config files here using the diff files?
>> No, Just copy/rename config + cdiffs in repo in this step
> Well, in the repository there are no config files, just the default and
> cdiffs.
Right, configs are generated by 'buildtool.pl source linux' and then 
'make build' into the dir
>
>>> generate default (=i486) config
>>>
>>> How do you generate this one? According to one of your last mails it
>>> should already exist as Bering_KRELEASE_.config.
>>>> by generic procedure ('make oldconfig' is called), then - break process
>>>> on next arch.
>>> Note somewhere drivers (= kernel options) that should be
>>>> enabled in some specific arches (for ex., PCI-E cards drivers) if they
>>>> exists; usually - max 3-5 devices, or even none
>>> This is the manual intervention
>> Yes, of course. In other case we'll receive a lot of trash like
>> proximity/light sensors and a lot of missed useful drivers.
> OK, so you manually select/deselect new drivers in the default config
> only, and the hope is that the diff files can take care of that. My only
> concern here is, that the diff files do not appear to play nicely with
> git rebase/merge, as those functions apply diffs to diffs.
>
> ..>
cdiff files changes specified in them options.

If there is a trouble with diff syntax - we may use different syntax for 
them (for ex., "-"/"+" replace to "<"/">"

>>> If we really could just work on the default config and the diff
>>> mechanism would allow us to upgrade all existing archs automatically
>>> then I would be all for it. But to me right now, this assumption appears
>>> to be wrong.
>> You may change 'make oldconfig' into 'make olddefconfig' in makefile,
>> and got same useless semi-generic configs for all archs/subarchs like in
>> your example.
> True, it applies the default values to all new options, it does not need
> manual intervention though. If we really can use cdiffs _without_
> _touching_ them _after_ an upgrade, that would be beneficial.
Yes, cdiff just changes options that are specified into it.
>
> cheers
>
> ET
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] usefullness of kernel config cdiff files

[Andrew]

14.03.2016 12:28, Erich Titl пишет:
> Hi Andre
>
> Am 12.03.2016 um 19:40 schrieb Andrew:
>> Hi.
> ...>>
>>> Please let us know how you do a major kernel upgrade. If you write it
>>> down, you might see that there are unnecessaty steps or you may
>>> convince me that the diff files are valuable.
>>>
>> 1. Upgrade kernel version, copy configs,
> Will you have to generate the config files here using the diff files?
No, Just copy/rename config + cdiffs in repo in this step
>
> generate default (=i486) config
>
> How do you generate this one? According to one of your last mails it
> should already exist as Bering_KRELEASE_.config.

>> by generic procedure ('make oldconfig' is called), then - break process
>> on next arch.
> Note somewhere drivers (= kernel options) that should be
>> enabled in some specific arches (for ex., PCI-E cards drivers) if they
>> exists; usually - max 3-5 devices, or even none
> This is the manual intervention
Yes, of course. In other case we'll receive a lot of trash like 
proximity/light sensors and a lot of missed useful drivers.
>> 2. Copy default config to repo
>> 3. Clean generated configs, run 'make build' again
>> 4. If I have some specific new drivers that must be enabled on some arch
>> - then I run 'make menuconfig' or edit config file manually (with 'make
>> oldconfig' to ensure that no additional options hapened), and then -
>> re-create cdiff.
> Another manual intervention on all of the arch files which will need to
> be generated from the diff files.
Yes. In other case you'll receive some kind of generic config.
>
>> 5. Try to make kernel configs for other archs (to ensure that no
>> arch-specific options added), if needed - enable some drivers manually,
>> and if config is changed - re-create cdiff
> You see here, you generate configs and recreate diffs, I don't think
> this step is necessary, but in the end the results should be the same,
> IHMO just too much work and could be avoidedd.
Ok, maybe you know easier way how to:
1. Enable per-platform driver set (including staging/experimental 
drivers like WiFi ones - IMHO untested/partially working device is 
better that non-working device), having same driver set across similar 
platforms (for ex., x86_64 and i686)
2. Make strictly similar set of network-related features 
(iptables/nftables module set and so on) across all archs
3. Have possibility to easily check which options differs between targets

> If we really could just work on the default config and the diff
> mechanism would allow us to upgrade all existing archs automatically
> then I would be all for it. But to me right now, this assumption appears
> to be wrong.
You may change 'make oldconfig' into 'make olddefconfig' in makefile, 
and got same useless semi-generic configs for all archs/subarchs like in 
your example.


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] usefullness of kernel config cdiff files

[Andrew]

Hi.

12.03.2016 13:02, Erich Titl пишет:
> Hi Andrew
>
> Am 11.03.2016 um 18:19 schrieb Andrew:
>> 11.03.2016 16:24, Erich Titl пишет:
>>> Hi Andrew
>>>
>>> Am 11.03.2016 um 12:50 schrieb Andrew:
>>>> 11.03.2016 08:48, Erich Titl пишет:
>>>>> Hi Andrew
>>>>>
>>>>> Am 10.03.2016 um 21:19 schrieb Andrew:
>>>>>> 10.03.2016 22:07, Erich Titl пишет:
>>>>>>> Am 10.03.2016 um 19:39 schrieb Andrew:
>>>>>>>> 10.03.2016 20:03, Erich Titl пишет:
>>>>> ...
>>>>>
>>>>>>>>> But in the end you have to do it for every arch, not only 
>>>>>>>>> common config.
>>>>>>>>> Humans are notoriously weak when looking at changed/missed lines.
>>>>>>>> Not always.
>>>>> Always, humans are just not good at that.
>>>> If no options added into new kernel patch (this is 99% cases) - you
>>>> don't need to touch kernel configs at all.
>>> Good, but how do you handle the new options. just leaving them away and
>>> sticking with an old config does not really cut it for me.
>> If new option is added - kernel building stucks on 'make defconfig'.
>
> Why do you always refer to defconfig? I did not mention it. Look at 
> olddefconfig.
>
Sorry, I mean 'make oldconfig' here.


>
>>
>>>>>>>> When there is usual kernel config - at kernel update there's 
>>>>>>>> usual tens
>>>>>>>> or even hundreds new options that should be choosed. And using 
>>>>>>>> .cdiff
>>>>>>>> with generic kernel you should only enable new platform-specific
>>>>>>>> drivers; generic options like network stack are applied 
>>>>>>>> automatically.
>>>>>>> The same applies if you use make olddefconfig.
>>>>>> And you'll lack, for ex., new iptables features from new kernel, 
>>>>>> and got
>>>>>> a lot of unneeded drivers.
>>>>> Well, I am not that sure we are using the best of all 
>>>>> configurations and
>>>>> typically the defaults are quite OK.
>>>> What you mean as 'best configuration'? Default configuration that 
>>>> have a
>>>> lot of stuff disabled (for ex., network drivers, a lot of iptables
>>>> modules and so on) and a log of useless stuff enabled (for ex., video
>>>> drivers are completely useless for us - we don't use graphic modes)
>>>> isn't a best configuration for our case.
>>> Without knowing what new modules are provided I am not sure. Someone 
>>> may
>>> use video drivers for whatnot or audio drivers for hardware I don't
>>> have. We are providing a lot of packages which I have no clue what they
>>> could be useful for.
>> Why you think that new modules are unknown? Use 'make defconfig' - and
>> you'll always know what is added to kernel, and what of them you 
>> enabled.
>
> Well defconfig will use the defaults and you might not want them. 
> Whatever. it is not merely to discuss the way to do kernel upgrade but 
> the usefulness of the diff files. I personally doubt they are any 
> good, but if someone thinks they are, well I could not care less. I 
> can live with the current set-up, I don't fancy it but that is my 
> opinion.
>
Sorry, I again missed... I mean 'make oldconfig' here too.

And diff files are mostly used for easing kernel upgrade process and 
make it's result more predictable. There's no difference how configs are 
stored till we want to change config parameters/upgrade kernel.


>
>
>>>>>>>>> And you still have
>>>>>>>>> to generate the full config for every arch. But then time is 
>>>>>>>>> not the
>>>>>>>>> only parameter to look at. We should analyze if there were non 
>>>>>>>>> necessary
>>>>>>>>> steps involved in this process.
>>>>>>>> In any case, you should look at configs difference - so 
>>>>>>>> generating some
>>>>>>>> kind of diffs is necessary.
>>>>>>> Why? The kernel developers gave us pretty good tools to manage 
>>>>>>> kernel
>>>>>>> upgrades and they did _not_ provide diff files. I believed in 
>>>&g

Re: [leaf-devel] usefullness of kernel config cdiff files

[Andrew]

11.03.2016 16:24, Erich Titl пишет:
> Hi Andrew
>
> Am 11.03.2016 um 12:50 schrieb Andrew:
>> 11.03.2016 08:48, Erich Titl пишет:
>>> Hi Andrew
>>>
>>> Am 10.03.2016 um 21:19 schrieb Andrew:
>>>> 10.03.2016 22:07, Erich Titl пишет:
>>>>> Am 10.03.2016 um 19:39 schrieb Andrew:
>>>>>> 10.03.2016 20:03, Erich Titl пишет:
>>> ...
>>>
>>>>>>> But in the end you have to do it for every arch, not only common config.
>>>>>>> Humans are notoriously weak when looking at changed/missed lines.
>>>>>> Not always.
>>> Always, humans are just not good at that.
>> If no options added into new kernel patch (this is 99% cases) - you
>> don't need to touch kernel configs at all.
> Good, but how do you handle the new options. just leaving them away and
> sticking with an old config does not really cut it for me.
If new option is added - kernel building stucks on 'make defconfig'.

>>>>>> When there is usual kernel config - at kernel update there's usual tens
>>>>>> or even hundreds new options that should be choosed. And using .cdiff
>>>>>> with generic kernel you should only enable new platform-specific
>>>>>> drivers; generic options like network stack are applied automatically.
>>>>> The same applies if you use make olddefconfig.
>>>> And you'll lack, for ex., new iptables features from new kernel, and got
>>>> a lot of unneeded drivers.
>>> Well, I am not that sure we are using the best of all configurations and
>>> typically the defaults are quite OK.
>> What you mean as 'best configuration'? Default configuration that have a
>> lot of stuff disabled (for ex., network drivers, a lot of iptables
>> modules and so on) and a log of useless stuff enabled (for ex., video
>> drivers are completely useless for us - we don't use graphic modes)
>> isn't a best configuration for our case.
> Without knowing what new modules are provided I am not sure. Someone may
> use video drivers for whatnot or audio drivers for hardware I don't
> have. We are providing a lot of packages which I have no clue what they
> could be useful for.
Why you think that new modules are unknown? Use 'make defconfig' - and 
you'll always know what is added to kernel, and what of them you enabled.
>>>>>>> And you still have
>>>>>>> to generate the full config for every arch. But then time is not the
>>>>>>> only parameter to look at. We should analyze if there were non necessary
>>>>>>> steps involved in this process.
>>>>>> In any case, you should look at configs difference - so generating some
>>>>>> kind of diffs is necessary.
>>>>> Why? The kernel developers gave us pretty good tools to manage kernel
>>>>> upgrades and they did _not_ provide diff files. I believed in the past
>>>>> this was a wekness, now I am convinced they knew why.
>>>> To be sure that you didn't missed something.
>>> You typically miss stuff when you do it manually
>> Ok, so you prefer disable all potentially useful stuff (like network
>> drivers, some iptables modules) because these drivers disabled in
>> default kernel config? Or in what way we may be sure that, for ex.,
>> iptables modules set is identical across all archs?
> If you want to assure this, then indeed you may need a diff file, but
> just to compare two full config files, not to generate one from the other.
IMHO update in this case will be harder + there is more chances to make 
error in configs.
> And then AFAIK olddefconfig just sets the default values to _new_
> parameters, and I agree they may be wrong. Speaking for me, I often
> don't know what those new parameters are and I believe it is the same
> with most others, so the default appears logical.
Any kernel parameter has built-in help.
> AFAIK olddefconfig does _not_ use defaults for options already set, just
> for new options, so we get a new clean config file without having to
> manually accept stuff.
And with a lot of disabled useful drivers or kernel modules, + a lot of 
enabled useless...

>
>>
>>>>>>> I looked at my routine to get master in sync with new-initrd.
>>>>>> It seems like you re-generated kernel config from scratch.  With a lot
>>>>>> of completely unneeded stuff.
>>> Nope, I did not. I applied olddefconfig
>> So something went completely wrong in your case.
> Not necessarily, just rebasing yielde

Re: [leaf-devel] usefullness of kernel config cdiff files

[Andrew]

11.03.2016 08:48, Erich Titl пишет:
> Hi Andrew
>
> Am 10.03.2016 um 21:19 schrieb Andrew:
>> 10.03.2016 22:07, Erich Titl пишет:
>>> Am 10.03.2016 um 19:39 schrieb Andrew:
>>>> 10.03.2016 20:03, Erich Titl пишет:
> ...
>
>>>>> But in the end you have to do it for every arch, not only common config.
>>>>> Humans are notoriously weak when looking at changed/missed lines.
>>>> Not always.
> Always, humans are just not good at that.
If no options added into new kernel patch (this is 99% cases) - you 
don't need to touch kernel configs at all.

>
>>>> When there is usual kernel config - at kernel update there's usual tens
>>>> or even hundreds new options that should be choosed. And using .cdiff
>>>> with generic kernel you should only enable new platform-specific
>>>> drivers; generic options like network stack are applied automatically.
>>> The same applies if you use make olddefconfig.
>> And you'll lack, for ex., new iptables features from new kernel, and got
>> a lot of unneeded drivers.
> Well, I am not that sure we are using the best of all configurations and
> typically the defaults are quite OK.
What you mean as 'best configuration'? Default configuration that have a 
lot of stuff disabled (for ex., network drivers, a lot of iptables 
modules and so on) and a log of useless stuff enabled (for ex., video 
drivers are completely useless for us - we don't use graphic modes) 
isn't a best configuration for our case.

> 
>>>> release.
>>> Potentially with each new kernel release and at out speed that is every
>>> two weeks.
>> There's mostly
> Mostly is not always :-)
>
> no config difference between kernel patch releases. It
>> just requires to replace kernel patch...
> And then it is easy to just use oldconfig.
There's no need to touch kernel configs at all.

>>>>> And you still have
>>>>> to generate the full config for every arch. But then time is not the
>>>>> only parameter to look at. We should analyze if there were non necessary
>>>>> steps involved in this process.
>>>> In any case, you should look at configs difference - so generating some
>>>> kind of diffs is necessary.
>>> Why? The kernel developers gave us pretty good tools to manage kernel
>>> upgrades and they did _not_ provide diff files. I believed in the past
>>> this was a wekness, now I am convinced they knew why.
>> To be sure that you didn't missed something.
> You typically miss stuff when you do it manually
Ok, so you prefer disable all potentially useful stuff (like network 
drivers, some iptables modules) because these drivers disabled in 
default kernel config? Or in what way we may be sure that, for ex., 
iptables modules set is identical across all archs?


>>>>> I looked at my routine to get master in sync with new-initrd.
>>>> It seems like you re-generated kernel config from scratch.  With a lot
>>>> of completely unneeded stuff.
> Nope, I did not. I applied olddefconfig
So something went completely wrong in your case.

>   and yes, if you are sure that
> the suggested defaults from the kernel people are wrong then I had more
> stuff compiled in than necessary. But if you don't trust those folks
> then you better write your own kernel :-)

As I said, generic config isn't a best choice. For ex, you don't need a 
SMP on i486/Geode. You don't need a lot of RAID drivers for Geode/i486 
(physically they are missed on these platforms). You don't need SATA 
drivers here. And of course you don't need PCI-E cards drivers for that 
platforms.

 From other side, for i686/x86_64 you need all PCI-E network cards 
drivers (a lot of them are disabled - for ex., Mellanox, Emulex 10GbE 
and so on).

And you also don't need drivers for power controllers, proximity/light 
sensors and a lot of other stuff targetted for mobile devices/notebooks.

That's why defconfig is a bad idea.

>
>>>> I just applied your changes in your old branch to new kernel configs.
>>>> They lays perfectly.
>>> But you need the full config files to do this and then you just convert
>>> them back to diffs :-(
>> No.
> So you just apply the diffs to a completely new kernel config?
Yes. Because diffs are trivial (storage drivers are compiled as built-in 
instead of modules), + minor manual edit of .cdiff (for one new SATA 
driver that was added in 4.4 kernel)

> IMHO this
> is utterly dangerous. And yes, then you need to inspect the files and
> you will miss stuff and after some time it wil

Re: [leaf-devel] usefullness of kernel config cdiff files

[Andrew]

10.03.2016 22:07, Erich Titl пишет:
> Am 10.03.2016 um 19:39 schrieb Andrew:
>> 10.03.2016 20:03, Erich Titl пишет:
>>> Hi Andrew
>>>
>>> Am 10.03.2016 um 18:53 schrieb Andrew:
>>>> Hi.
>>>>
>>>> For common config case you can easily check what real differences are
>>>> between configs.
>>>>
>>>> + kernel upgrade is enough easy: just update common config (be make
>>>> oldconfig) and try to generate other configs (looking on cdiff output -
>>>> for changed/missed lines); and then look on result of 'make oldconfig' +
>>>> maybe correct some subarch-specific settings (for ex., enable new
>>>> drivers for i686/x86_64).
>>> But in the end you have to do it for every arch, not only common config.
>>> Humans are notoriously weak when looking at changed/missed lines.
>> Not always.
>>
>> When there is usual kernel config - at kernel update there's usual tens
>> or even hundreds new options that should be choosed. And using .cdiff
>> with generic kernel you should only enable new platform-specific
>> drivers; generic options like network stack are applied automatically.
> The same applies if you use make olddefconfig.
And you'll lack, for ex., new iptables features from new kernel, and got 
a lot of unneeded drivers.

>
>>>> For me, migration to new kernel (when I experimented with different
>>>> versions due to crashes with PPPoE on 4.1) takes max 10-15 minutes -
>>>> even when I switched from 4.1 to old 3.2.
>>> Which I consider very long for just a kernel upgrade.
>> Not too long - it's done just once (ok, maybe - twice as in 5.2 case,
>> when we switched from 5.1's  3.10 to 3.14 and then to 4.1) per minor
>> release.
> Potentially with each new kernel release and at out speed that is every
> two weeks.
There's mostly no config difference between kernel patch releases. It 
just requires to replace kernel patch...
>>> And you still have
>>> to generate the full config for every arch. But then time is not the
>>> only parameter to look at. We should analyze if there were non necessary
>>> steps involved in this process.
>> In any case, you should look at configs difference - so generating some
>> kind of diffs is necessary.
> Why? The kernel developers gave us pretty good tools to manage kernel
> upgrades and they did _not_ provide diff files. I believed in the past
> this was a wekness, now I am convinced they knew why.
To be sure that you didn't missed something.

>>> I looked at my routine to get master in sync with new-initrd.
>> It seems like you re-generated kernel config from scratch.  With a lot
>> of completely unneeded stuff.
>>
>> I just applied your changes in your old branch to new kernel configs.
>> They lays perfectly.
> But you need the full config files to do this and then you just convert
> them back to diffs :-(
No.

> Whatever, I _believe_ _now_ that keeping the full config files would
> make transition easier, mostly because of the format of the config
> files, which _mark_ the absence of an option instead of just leaving it
> out. If the config format would hold less of this non_information it
> would be better suited to automatic upgrades.
>
> cheers
>
> ET
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] usefullness of kernel config cdiff files

[Andrew]

10.03.2016 20:03, Erich Titl пишет:
> Hi Andrew
>
> Am 10.03.2016 um 18:53 schrieb Andrew:
>> Hi.
>>
>> For common config case you can easily check what real differences are
>> between configs.
>>
>> + kernel upgrade is enough easy: just update common config (be make
>> oldconfig) and try to generate other configs (looking on cdiff output -
>> for changed/missed lines); and then look on result of 'make oldconfig' +
>> maybe correct some subarch-specific settings (for ex., enable new
>> drivers for i686/x86_64).
> But in the end you have to do it for every arch, not only common config.
> Humans are notoriously weak when looking at changed/missed lines.
Not always.

When there is usual kernel config - at kernel update there's usual tens 
or even hundreds new options that should be choosed. And using .cdiff 
with generic kernel you should only enable new platform-specific 
drivers; generic options like network stack are applied automatically.

>
>> For me, migration to new kernel (when I experimented with different
>> versions due to crashes with PPPoE on 4.1) takes max 10-15 minutes -
>> even when I switched from 4.1 to old 3.2.
> Which I consider very long for just a kernel upgrade.
Not too long - it's done just once (ok, maybe - twice as in 5.2 case, 
when we switched from 5.1's  3.10 to 3.14 and then to 4.1) per minor 
release.

> And you still have
> to generate the full config for every arch. But then time is not the
> only parameter to look at. We should analyze if there were non necessary
> steps involved in this process.
In any case, you should look at configs difference - so generating some 
kind of diffs is necessary.

>
> I looked at my routine to get master in sync with new-initrd.
It seems like you re-generated kernel config from scratch.  With a lot 
of completely unneeded stuff.

I just applied your changes in your old branch to new kernel configs. 
They lays perfectly.

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] usefullness of kernel config cdiff files

[Andrew]

Hi.

For common config case you can easily check what real differences are 
between configs.

+ kernel upgrade is enough easy: just update common config (be make 
oldconfig) and try to generate other configs (looking on cdiff output - 
for changed/missed lines); and then look on result of 'make oldconfig' + 
maybe correct some subarch-specific settings (for ex., enable new 
drivers for i686/x86_64).

For me, migration to new kernel (when I experimented with different 
versions due to crashes with PPPoE on 4.1) takes max 10-15 minutes - 
even when I switched from 4.1 to old 3.2.

10.03.2016 12:11, Erich Titl пишет:
> Hi Folks
>
> Some time ago I suggested to not keep complete kernel config files, but
> base them on a common basic configuration and diff files, so common
> settings would be kept in a single file only. This has been implemented
> in the config.cdiff files. I was falsely convinced, that common config
> settings could be handled easier that way. I _believe_ now I was wrong.
>
> Working extensively on a few config settings lately I was forced all the
> time to make a detour by generating full kernel config files from the
> cdiff files just to upgrade to new kernel releases and modify small
> settings. This appears orthogonal to the original idea of standardizing
> kernel configs. It also appears that git does not handle the cdiff files
> nicely and therefore it appears not to be obvious to merge or rebase the
> branches.
>
> It also appears that upgrading kernel releases always requires to
> generate a full config to be copied to the new kernel and running make
> oldconfig or olddefconfig, just to be forced to generate a new diff file
> afterwards. So this also defeats to a certain degree the usefulness of
> the kernel diff files.
>
> I would like to discuss here if it would not be better to drop this
> feature as at least for me it does not show any potential to make the
> administration of the kernel config files any easier. I suggest to move
> back to keep complete kernel config files.
>
> cheers
>
> ET
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] master vs. new-initrd-6.x

[Andrew]

Hi.

Can you also run 'free' to see RAM usage in both cases?

09.03.2016 13:38, Erich Titl пишет:
> Hi Folks
>
> I have successfully installed new-initrd-6.x on my WRAP testbed. This
> system does not have neither moddb nor initmod anymore.
>
> Here a few numbers to compare it to the current master branch. Master is
> alpha1, new-initrd-6.x is alpha2 for comparison
>
> 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
>
> SALT# df
> Filesystem   1K-blocks  Used Available Use% Mounted on
> tmpfs25600 0 25600   0% /tmp
> tmpfs 819288  8104   1% /var/log
> root 40960 22284 18676  54% /
>
> Total boot time 03:50
>
> SALT# cat /etc/motd
> LEAF Bering-uClibc 6.0.0-alpha2 Rev 1 uClibc 1.0.12  at SALT
> Linux 4.4.3-i486 #1 Tue Mar 8 22:57:03 CET 2016
>
> SALT# df
> Filesystem   1K-blocks  Used Available Use% Mounted on
> tmpfs2560064 25536   0% /tmp
> tmpfs 819292  8100   1% /var/log
> root 40960 19132 21828  47% /
>
> Total boot time 03:30
>
> So we are saving roughly 20 seconds boot time and use about 15% less memory
>
> cheers
>
> ET
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
>
> ___
> 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://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] git master

[Andrew]

Delayed unmounting is mostly for services that have delayed modules 
loading (like wpa-supplicant or hostapd) to ensure that all is ok.

+ 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.

07.03.2016 23:31, Erich Titl пишет:
> 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


--
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

[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.

> 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

[Andrew]

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

[Andrew]

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

[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.

P.S. it seems like you forgot to commit umount_modules script into repo.

06.03.2016 00:33, Erich Titl пишет:
> 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


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] git master

[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?).

Can you review branch diff to master?

05.03.2016 14:55, Erich Titl пишет:
> 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


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] git master

[Andrew]

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] status of modules loading - old, proposed new and questions

[Andrew]

And they should be accessible at least for some time after daemon start 
(for ex., 5-10 seconds) - daemon may not always load modules at start, 
it may load modules on demand. And I expect that it shouldn't unload 
modules.

Also, now we are freeing unused modules on device plug out. And for new 
realization we shouldn't unload modules (else each device disconnect 
will require manual modules re-probing) or on each connect event we 
should try to mount storage for 5-10 seconds.

08.02.2016 19:59, Erich Titl пишет:
> Am 08.02.2016 um 18:54 schrieb Andrew:
>> Modules can be loaded by daemon (for ex. accel-ppp loads needed modules).
> Right, so at daemon start the modules need to be accessible
>
> ET
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] status of modules loading - old, proposed new and questions

[Andrew]

Modules can be loaded by daemon (for ex. accel-ppp loads needed modules).

08.02.2016 19:32, Erich Titl пишет:
> Hi KP
>
> Am 08.02.2016 um 18:26 schrieb kp kirchdoerfer:
> ...
>> You may analyze ppp/pppoe instead, where /var/lib/lrpkg/*.depmod provides the
>> necesssry modules and therefor requires no user intervention to load the
>> necessary modules.
> OK, so who is loading the modules, please. LINUXRC does not.
>
> ET
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] status of modules loading - old, proposed new and questions

[Andrew]

04.02.2016 08:49, Erich Titl пишет:
> Hi Andrew
>
> Am 03.02.2016 um 22:56 schrieb Andrew:
>> 03.02.2016 22:47, Erich Titl пишет:
>>> Hi Andrew
>>>
>>> Am 03.02.2016 um 19:03 schrieb Andrew:
>>>> Hi.
>>>>
>>> ...>>
>>>>> Erich made the proposal to change the init scripts of such packages to 
>>>>> mount
>>>>> modules.sqfs and load whatever required.
>>>> Good solution.
>>>>
>>>> But IMHO we should leave possibility to use old behavior on systems.
>>> What behaviour would you like preserved?
>>>
>>> cheers
>>>
>>> ET
>>>
>> Copying all modules specified in .depmod (or loaded by
>> autoprobing/probing /etc/modues) into /etc/modules
> Copying does not make sense, as this is exactly what we want to get rid
> of. Autoprobing is preserved as is handling of /etc/modules. In case an
> application needs additional modules, they are easily pulled from
> modules.sqfs, which can be made available in the init script.
>
> cheers
>
> ET

I mean not to preserve old behavior for all cases. I mean to leave 
possibility to enable old behavior via some flag..

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] status of modules loading - old, proposed new and questions

[Andrew]

03.02.2016 22:47, Erich Titl пишет:
> Hi Andrew
>
> Am 03.02.2016 um 19:03 schrieb Andrew:
>> Hi.
>>
> ...>>
>>> Erich made the proposal to change the init scripts of such packages to mount
>>> modules.sqfs and load whatever required.
>> Good solution.
>>
>> But IMHO we should leave possibility to use old behavior on systems.
> What behaviour would you like preserved?
>
> cheers
>
> ET
>
Copying all modules specified in .depmod (or loaded by 
autoprobing/probing /etc/modues) into /etc/modules

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] status of modules loading - old, proposed new and questions

[Andrew]

Hi.

03.02.2016 17:44, kp kirchdoerfer пишет:
> Hi all;
>
> I'll try to summarize the current and proposed status of loading modules as
> this raises questions.
>
> Pls correct me whereelse needed if I missed something or got it wrong.
>
> This summary is based on 5.2.x, master and new-initrd-6x branch
>
>
> A) The current status
>
> At the time we do have three mechanisms to load modules, which itself is is a
> state of transition.
>
> 1) First one is to load all hardware related modules during boot in linuxrc
>
> 2) Next we load(copy??) all modules from /etc/modules - esp. added for modules
> which are not hardware-related like tun.ko (openvpn), ppp*.ko etc.
>
> 3) A third mechanism has been introduced last year to add modules to
> load(copy??) for a given Package in buildtool.cfg in the  section
> of buildtool.cfg. This concurs with loading from /etc/modules and is intented
> to replace the need to add a module for a Package to /etc/modules and have
> loaded(copied??) instead "automagically" - like other Packages a Package
> depends on.
> Although 2) and 3) are similar loading(copying??) from /etc/modules is a
> welcome fallback, in case we do miss a module when building a package in
> buildtool.cfg.
>
> As you can see above, I'm not shure if modules in step 2 and 3 are really
> loaded or just copied to /lib/modules.
> Anyway this works, if we later start packages that need modules, they
> DependOn.
2) - modules are loaded to kernel
3) - modules are just copied. they are loaded by software if needed (for 
ex., iptables modules)

> A major drawback is that this way we do have a lot modules just copied into
> the RAM (although compressed).
>
> Did I get this correct so far?
>
> B) Proposed status
>
> Erich invested work to reduce the number of copied/loaded  modules in the new-
> initrd branch to  minimize RAM usage.
> He started to  build the essential modules from initmod.lrp into the kernel -
> that way we can get rid off initmod.lrp at all. While it will raise the kernel
> size, it is hoped that we can go wihout having modules as compressed modules
> in /lib/modules as well as uncompressed loaded into the RAM.
> This effort will buy out even more if we want to support more specialized
> architectures/images than today.
>
> In a second step he replaced the current way to load/copy every module into
> /lib/modules with a mimic to work with modules.sqfs and to now
> really load required modules into instead insted of copy the compressed module
> and load afterwards.
>
> new-initrd is able to load
> a) hardware related modules during boot
> b) load modules from /etc/modules
>
> but does not work with modules defined in  
> (/var/lib/lrpkg/*.depmod)
>
> Instead it usees for shorewall the /etc/shorewall/modules* to oad all modules
> required modules with a modification to shorewal[6]l's init files (once again
> mount modules.sqfs, load modules and umount ).
>
> While this works for shorewall[6] with a well-defined configuraton, which
> modules to load, and therefor does not load any netfilter/xtables etc module
> unndeeded, and keep the necessary size in RAM as small as possible, it fails
> to load needed  modules of packages that assumes that modules are available
> (like openvpn, arptables, ppp*).
>
> Erich made the proposal to change the init scripts of such packages to mount
> modules.sqfs and load whatever required.
Good solution.

But IMHO we should leave possibility to use old behavior on systems.

> Another option could be to modprobe all modules in question from
> /var/lib/lrpkg/*depmod, but it will load more modules into than needed.
>
> I've discussed this with Erich forth and back, each one with better or worse
> arguments, but without a proper solution.
>
> So we decided to move the discussion to leaf-devel (again) to find a proper
> solution and to have as much feedback as possible.
>
> I may have been to short in describing what's possible with new-initrd, and
> also to describe the drawbacks - but I want to start a discussion how to deal
> with
>
> a) the current situation to deal with modules
>
> b) how to keep the advantages of new-initrd, while getting the best of the
> work we've done in the past
>
> Any input/ideas is welcome.
>
> thy kp
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobi

Re: [leaf-devel] LEAF rebase/merge

[Andrew]

Hi.

Git conflict appears when there's two modifications of same code in 
merged branches.

So only case of avoiding it - don't touch code which is modified in 
other branch, that is impossible in real world :)

14.01.2016 10:20, Erich Titl пишет:
> Hi Yves
>
> Am 14.01.2016 um 09:10 schrieb Yves Blusseau:
>> Hi Erich,
>>
>> the best is to merge the new-initrd branch into the maint or master.
>> In either case (merge or rebase) you need to resolve the conflicts.
>> There are no other alternative.
> Pretty disappointing :-(
>
> Is there a best practise strategy to avoid conflicts? With Git conflicts
> appear to be inherent.
>
> cheers
>
> Erich
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] vlan

[Andrew]

Hi.

It is in core now (utility is in busybox)

08.01.2016 14:29, Erich Titl пишет:
> Hi Folks
>
> What happened to vlan support, e.g vlan.lrp
>
> 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] How to create a link in a .lrp package

[Andrew]

I'm not sure about hardlinks. IMHO they weren't needed earlier so 
there's no hardlinks support. But I didn't look in code.

05.01.2016 21:45, Erich Titl пишет:
> Hi Andrew
>
> Am 05.01.2016 um 20:37 schrieb Andrew:
>> Hi.
>>
>> Look at any library package.
> Link creates a symlink, not a hard link. Is this not supported?
>
> Thanks
>
> 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] How to create a link in a .lrp package

[Andrew]

Hi.

Look at any library package.

05.01.2016 21:35, Erich Titl пишет:
> Hi Folks
>
> The subject says it all, I could not find the right way to include a
> link in a .lrp package, so the file gets created like
>
> SALT# > foo
> SALT# ln foo bar
> SALT# ls -l
> -rw-r--r--2 root root 0 Jan  5 19:33 bar
> -rw-r--r--2 root root 0 Jan  5 19:33 foo
>
> I tried with file Type=LINK in buildtool.cfg but it barfed
>
> 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] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

04.01.2016 11:32, Erich Titl пишет:
> Hi Andrew
>
> Am 04.01.2016 um 10:18 schrieb Andrew:
>> IMHO it's bad idea - toolchain depends on system libs (so it may not
>> work on some systems), + it may be 32bit or 64bit.
> We used to not be system dependent, but I agree, it is a big difference.
Binaries compiled for host system (gcc, binutils and so on) are 
system-dependent and may not work on other distros (or, at least, all 
that stuff should be compiled as static or on some old legacy distro - 
there is some forward ABI compatibility in gcc/glibc, that may be 
breaked between major gcc releases, but there's no backward compatibility).
In any case, this is a headache to support it.
> Still, having multiple workspaces from the same repository is asking for
> trouble.
Why? I have 2-3 workspaces with same local git repo (that 1) saves space 
and 2) allows to easily merge branches); there's script 
'git-new-workdir' to create sch environment; it is usually available in 
git package.
> 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] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

IMHO it's bad idea - toolchain depends on system libs (so it may not 
work on some systems), + it may be 32bit or 64bit.

03.01.2016 22:54, Erich Titl пишет:
> Am 03.01.2016 um 20:28 schrieb Andrew:
>> Use two separate dirs with same repo?
>>
>> In any case, gcc update may also break binary compatibility.
>>
> Crufty way to handle this, we need to take the development environment
> into Git
>
> 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] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

Use two separate dirs with same repo?

In any case, gcc update may also break binary compatibility.

03.01.2016 20:40, Erich Titl пишет:
> Am 03.01.2016 um 16:11 schrieb Andrew:
>> I just replaced uClibc with uClibc-ng (uClibc fork) in toolchain. +
>> added some compat fixes to packages.
> Right, but how to switch from master to maint and back?
>
> 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] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

I just replaced uClibc with uClibc-ng (uClibc fork) in toolchain. + 
added some compat fixes to packages.

Tree is compiled OK.

03.01.2016 16:25, Erich Titl пишет:
> Hi
>
> How do we handle this step for the development environment?
>
> cheers
>
> ET
>
>
>  Weitergeleitete Nachricht 
> Betreff:  [leaf:bering-uclibc] New commit by Andrew Denisenko
> Datum:Fri, 01 Jan 2016 14:57:33 +
> Von:  LEAF Linux Embedded Appliance Framework Git repository
> 
> Antwort an:   LEAF Linux Embedded Appliance Framework Git repository
> 
> An:   LEAF Linux Embedded Appliance Framework Git repository
> 
>
>
>
>      Branch: master
>
> toolchain: switch to uClibc-ng
>
> By Andrew Denisenko on 01/01/2016 14:56
> *View Changes*
> <http://sourceforge.net/p/leaf/bering-uclibc/ci/49f1440f79727aa570832d0f0a0145d916903c6c/>
>
> 
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/leaf/bering-uclibc/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>
>
>
>
> --
>
> ___
> 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] uclibc-ng build error

[Andrew]

Hi.

It seems like there's troubles with parallel compilation. I thought that 
it was due to building all and utils in one make call. I've committed 
changes but forgot to push it. Try now. If it'll fail again (it may run 
OK but may fail), we'll need to remove $(MAKEOPTS) from make call.

01.01.2016 17:56, kp kirchdoerfer пишет:
> Hi Andrew;
>
> just tried to build toolchain with uclibc-ng, but ifailed the error
>
>   AR cr libc/libc_so.a
>STRIP -x -R .note -R .comment libc/libc_so.a
>AR cr libc/libc_so.a
> i486-unknown-linux-uclibc-ar: libc/libc_so.a: Error reading
> libc_multiple_threads.oS: File truncated
>
>
> ...?
> kp
>
> --
>
> ___
> 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] findfs in linuxrc

[Andrew]

It seems like it was dropped by unknown reason, so it should be enabled.

23.12.2015 13:11, Erich Titl пишет:
> Hi David
>
> Am 23.12.2015 um 11:41 schrieb David M Brooke:
>> Hi Erich,
>>
>> I added that code in 2012 in response to a user request.
>> The need for findfs was flagged up at the time.
> I guessed so, but looking at the actual busybox configuration this code
> snippet is lame.
>
> # Actually there is no findfs in busybox, so this is lame
>
>  # Convert any UUID= or LABEL= to device file name
> case "$1" in
> UUID=*|LABEL=*) dev=`/sbin/findfs "$1"`;;
> *) dev="$1";;
> esac
>
> So either we reenable findfs or remove the code as it will throw errors
> if anyone uses UUID or LABEL.
>
> 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] new module/init structure test first results

[Andrew]

This is for i486 target? USB is compiled in, or as module? Is USB 
present on target platform? USB is enough fat, and not all legacy 
platforms have USB.

For geode, of course it have a big sense (there's a single CPU and 
single chipset). + I think thatsome platform-specific things like WDT 
should be also compiled into kernel.

But I'm in doubt about generic targets with tens of ATA/SATA controllers.

15.12.2015 20:18, Erich Titl пишет:
> Am 15.12.2015 um 17:07 schrieb Andrew:
>> Hi.
>>
>> Look on memory usage. Storage contains compressed code, linux image in
>> RAM will be uncompressed after loading. I think that built-in modules
>> will require much more RAM.
> Possibly, but we are loading the compressed modules plus installing some
> of them, both to memory right now.
>
> -r1 root root 1342058496 Dec 15 17:57 kcore
> -r1 root root 1342058496 Dec 15 18:04 kcore
>
> Well, kcore looks identical
>
> This is with loaded modules
>
> SALT# cat meminfo
> MemTotal:  60660 kB
> MemFree:   22544 kB
> MemAvailable:  21328 kB
>
> This is with compiled modules
>
> SALT# cat meminfo
> MemTotal:  59728 kB
> MemFree:   25684 kB
> MemAvailable:  24480 kB
>
> And we still have all modules copied to /lib/modules and a very
> unspecified i486 image. I believe the numbers would be even better if it
> was a geode, as we have much more specific module selection.
>
> Anyway, this is encouraging enough to dig a bit deeper into init.
>
> cheers
>
> ET


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] new module/init structure test first results

[Andrew]

Hi.

Look on memory usage. Storage contains compressed code, linux image in 
RAM will be uncompressed after loading. I think that built-in modules 
will require much more RAM.

15.12.2015 17:38, Erich Titl пишет:
> Hi Folks
>
> first results from my test with module handling
>
> I compiled kernels with all the modules from initmod compiled into the
> kernel for each of the three i386 architectures
>
> SALT# ls -l linux* initrd*
> -rwxr-xr-x1 root root   1313792 Dec 15 08:37 initrd.lrp
> -rwxr-xr-x1 root root546639 Dec 15 15:19 initrd1.lrp
> -rwxr-xr-x1 root root   1786576 Dec 15 08:37 linux
> -rwxr-xr-x1 root root   2214912 Dec 15 15:21 linux1
>
> Adding another entry to boot linux1 with initrd1 to the grub menu is, of
> course, extremely simple. My test system is a WRAP running with a non
> optimized i486 variant of the kernel
>
> We can save about roughly 800 KB on initrd which does not need any
> modules anymore. We have to spend about 450 KB on the kernel, which
> definitely holds too many drivers for my type of architecture. As a net
> result it takes about 350 KB less space on storage than the traditional
> initmod approach.
>
> In this setup there is no moddb involved.
> I still need to test modifications on init to just load the modules from
> sqfs instead of copying them to /lib/modules and getting rid of the
> calls to depmod as this information is written to the modules.sqfs anyway.
>
> 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] [leaf:bering-uclibc] 2 new commits to Bering-uClibc

[Andrew]

There was an error in makefile - gzipped kernel modules weren't be 
copied to /lib/modules/linux-.

14.12.2015 00:37, Erich Titl пишет:
> Hi Andrew
>
> Am 13.12.2015 um 14:53 schrieb LEAF Linux Embedded Appliance Framework
> Git repository:
>>  Branch: master
>>
>> Merge branch 'maint'
>>
>> By Andrew Denisenko on 12/13/2015 13:53
>> *View Changes*
>> <http://sourceforge.net/p/leaf/bering-uclibc/ci/b52343a3bc9488008eec07ef4fc1caaa5076671e/>
>>
>> 
>>
>>
>>  Branch: maint
>>
>> xtables-addons: fix kernel modules installing
> Could you elaborate on this?
>
> Thanks
>
> 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] iperf/iperf3

[Andrew]

Hi.

Iperf 2/3 protocol incompatibility.


12.12.2015 19:11, kp kirchdoerfer пишет:
> Andrew;
>
> any reason we still provide iperf(2) additionally to iperf3?
>
> kp
>
> --
>
> ___
> 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] [leaf:bering-uclibc] New commit by kapeka

[Andrew]

I'm not sure that configs are changed...

11.12.2015 21:57, Erich Titl пишет:
> Am 11.12.2015 um 20:40 schrieb Andrew:
>> Just merge, and rename your configs to 4.1.14...
> This, I believe, is insufficient, as the configs have changed and we
> store just the cdiffs now
>
> cheers
>
> Erich
>
>
>
> --
>
> ___
> 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] [leaf:bering-uclibc] New commit by kapeka

[Andrew]

Just merge, and rename your configs to 4.1.14...

11.12.2015 19:52, Erich Titl пишет:
> Hi Folks
>
> I am working on new Kernel config stuff, based on 4.1.13 and I would
> like to get this work into maint.
>
> Am 11.12.2015 um 16:49 schrieb LEAF Linux Embedded Appliance Framework
> Git repository:
>>  Branch: maint
>>
>> kernel: updated to upstream version 4.1.14
> Could someone please let me know how to safely do that with an ever
> changing kernel version?
>
> 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] LEAF Kernel config

[Andrew]

Hi.

Right, it's unneeded now.

09.12.2015 10:54, Erich Titl пишет:
> Hi Andrew
>
> I am digging in the linux source directory and I am wondering why this
> is/was necessary
>
> # workaround -- patch 2.7.1 needs --follow-symlinks, patch 2.61 will not
> work
>  cp -L $(LINUX_CONFIG) $(LINUX_CONFIG).n; rm $(LINUX_CONFIG); mv
> $(LINUX_CONFIG).n $(LINUX_CONFIG)
>
> This makes a local copy of the generic linux config file and I don't see
> a reason to do this.
>
> Thanks
>
> 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] LEAF Kernel config

[Andrew]

08.12.2015 13:03, Erich Titl пишет:
> Hi Andrew
>
> Am 08.12.2015 um 11:28 schrieb Andrew:
>> Hi.
>>
>> You're right, only .cdiff files (+ generic config) are needed.
>>
>> Other per-target .config files are present just for easier update (this
>> was actual when usual .diff were used - after config change new config
>> not always lays smooth, usually there were patching errors due to
>> changed context)
> Right, so
>
> - Could we clean this up, it is confusing?
Yes.

> - Where should I start to make generic changes for all platforms? On the
> generic config file?
>
> Thanks
>
> ET
>
Yes.

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] LEAF Kernel config

[Andrew]

Hi.

You're right, only .cdiff files (+ generic config) are needed.

Other per-target .config files are present just for easier update (this 
was actual when usual .diff were used - after config change new config 
not always lays smooth, usually there were patching errors due to 
changed context)

08.12.2015 11:41, Erich Titl пишет:
> Hi Folks
>
> What is the canonical way to modify kernel config files? I see there is
> a number of cdiff files in the repo, also the same number of
> architecture related config files. Now I am wondering where exactly the
> modifications should go and why we are keeping all this redundant
> information. I believe we either need the diff/cdiff files or the actual
> hardware related config files, but both???
>
> Thanks
>
> ET
>
> --
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
>
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Notes after 5.2 release

[Andrew]

01.12.2015 17:36, Erich Titl пишет:
>
>
> Am 01.12.2015 um 16:08 schrieb Andrew:
>> Hi
>>
>> 01.12.2015 16:20, Erich Titl пишет:
>>> Hi Andrew
>>>>
>>>>>
>>>>> And SoC network drivers also may be compiled in kernel, not
>>>>>> as modules to save some space. Rest of modules (like additional USB
>>>>>> network adapters, iptables modules and so on) will be compiled as
>>>>>> modules.
>>>>>
>>>>> I suggest to build a new modules.sqfs with the kernel directory level
>>>>> removed and permanently mounted to /lib/modules/kernel. This way we
>>>>> can avoid to have to copy the modules to /lib/modules completely. We
>>>>> just need to run depmod once the squashfs is mounted, then module
>>>>> loading can be done from the squashfs directly and if user specific
>>>>> modules are needed they can either be on an OverlayFS or be 
>>>>> written to
>>>>> a subdirectory of /lib/modules.
>>>>>
>>>> Permanent squashfs mounting IMHO isn't a good idea - this will require
>>>> permanent underlying device mounting. This is OK when we use mtdblock
>>>> which contains squashfs - but device's flash size usually 4-8 MB, so
>>>> there'll be no free place for modules.sqfs on it. Rest of files 
>>>> will be
>>>> loaded from USB flash, or even from network.
>>>
>>> Ahh, you don't like the underlying FS be mounted to access the
>>> squashfs file. We could always use a raw partition for this purpose.
>> In any case - we can't remove USB flash, this may cause kernel panic.
>
> That is true, but not my issue here.
>
>>
>>>>
>>>> This may be done as option - but IMHO it'll be useful only in some 
>>>> rare
>>>> cases. Because main feature of LEAF - it doesn't require HDD/flash
>>>> storage that is always mounted.
>>>
>>> True, but we could still do that, as /lib/modules is not really needed
>>> once the system is running, except for the rare case when you need to
>>> load another module. We could mount modules.sqfs, load the modules
>>> from there and then just unmount it without copying the module to ram.
>>> There would be no modules cluttering valuable ram disk. For the
>>> occasional loading of modules we could build a wrapper for modprobe.
>>>
>> Yes, delayed unmounting (for ex., by S99umount) may be better solution.
>
> You still need something for loading a specific module after system 
> boot. Of course, educating the user may help :-)
>
Yes. But this will be optional behavior.

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Notes after 5.2 release

[Andrew]

Hi

01.12.2015 16:20, Erich Titl пишет:
> Hi Andrew
>>
>>>
>>> And SoC network drivers also may be compiled in kernel, not
>>>> as modules to save some space. Rest of modules (like additional USB
>>>> network adapters, iptables modules and so on) will be compiled as
>>>> modules.
>>>
>>> I suggest to build a new modules.sqfs with the kernel directory level
>>> removed and permanently mounted to /lib/modules/kernel. This way we
>>> can avoid to have to copy the modules to /lib/modules completely. We
>>> just need to run depmod once the squashfs is mounted, then module
>>> loading can be done from the squashfs directly and if user specific
>>> modules are needed they can either be on an OverlayFS or be written to
>>> a subdirectory of /lib/modules.
>>>
>> Permanent squashfs mounting IMHO isn't a good idea - this will require
>> permanent underlying device mounting. This is OK when we use mtdblock
>> which contains squashfs - but device's flash size usually 4-8 MB, so
>> there'll be no free place for modules.sqfs on it. Rest of files will be
>> loaded from USB flash, or even from network.
>
> Ahh, you don't like the underlying FS be mounted to access the 
> squashfs file. We could always use a raw partition for this purpose.
In any case - we can't remove USB flash, this may cause kernel panic.

>>
>> This may be done as option - but IMHO it'll be useful only in some rare
>> cases. Because main feature of LEAF - it doesn't require HDD/flash
>> storage that is always mounted.
>
> True, but we could still do that, as /lib/modules is not really needed 
> once the system is running, except for the rare case when you need to 
> load another module. We could mount modules.sqfs, load the modules 
> from there and then just unmount it without copying the module to ram. 
> There would be no modules cluttering valuable ram disk. For the 
> occasional loading of modules we could build a wrapper for modprobe.
>
Yes, delayed unmounting (for ex., by S99umount) may be better solution.

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Notes after 5.2 release

[Andrew]

30.11.2015 23:44, Erich Titl пишет:
> Hi Andrew
>
> Am 30.11.2015 um 14:16 schrieb Andrew:
>> 30.11.2015 13:41, Erich Titl пишет:
>>> Am 30.11.2015 um 10:44 schrieb Andrew:
>>>> 30.11.2015 11:11, Erich Titl пишет:
>>>>> Hi Andrew
>>>>>
>>>>> Am 22.09.2015 um 20:02 schrieb Andrew:
>>>>>> Hi.
>>>>>>
>>>>>> Another important target IMHO - merge all important stuff
>>>>>> (root.lrp/etc.lrp/config.lrp/other packages that are 100% present in
>>>>>> LEAF box) into initrd.
>>>>> Don't do that, initrd is overloaded as it is now,
>>>> Why you think that using separate packages for that files are better
>>>> than placing them into initrd? Or you know LEAF usecases when, for 
>>>> ex.,
>>>> root.lrp with all it's dependencies wasn't loaded?
>
> That is fine, if you load it from a single .lrp, initrd is IMHO the 
> wrong place.
Why? What difference between single big .lrp, and placing all into 
initrd? IMHO there's only one trouble - with current environment we 
can't just run 'apkg -u initrd.lrp', but 1) basic things aren't updated 
too frequently and 2) this is solveable.
>
>>> I am just afraid of overloading initrd, I need to package it with
>>> initmod, because grub does not support multple initrd files.
>>> ..
>> I think that 850kb instead of 550kb isn't a big difference.
>>
>
> What do you consider moving from root.lrp to initd? Why not make a big 
> root.lrp which contains everything for a basic system and leave initrd 
> tiny?
This will be a RAM waste, esp. on devices with 32M RAM

>
> and it's deps. Because on embedded platforms with small amount
>>>> of RAM and available MTD device (that is always connected to SoC) 
>>>> it'll
>>>> be preferrable to use squashfs initrd that is always mounted (+ mount
>>>> overlayfs on top of it) rather than copy all stuff from it to 
>>>> valuable RAM.
>
> Yes, but unless you can access the medium containing the squashfs that 
> won't work.
>
On embedded platform, mtdblock driver will be compiled in kernel - so 
we'll have access.

>>> If we can place initrd on squashfs this is certainly better. The
>>> question is here, can we low_level load the squashfs initrd, so we can
>>> load the storage and network drivers from there?
>>>
>>> cheers
>>>
>>> ET
>>>
>> For embedded platforms, kernel should contain all boot-required modules
>> compiled in.
>
> Totally agreed, this may mean we have a number of kernels for various 
> platforms.
Yes, of course. Each SoC (or even each hardware platform) will require 
it's own kernel - like OpenWRT does. And there's no solution to create 
single kernel that will boot on SoCs from different vendor. Too big 
difference in chips. And even different SoCs families will require 
different kernel patches.

>
> And SoC network drivers also may be compiled in kernel, not
>> as modules to save some space. Rest of modules (like additional USB
>> network adapters, iptables modules and so on) will be compiled as 
>> modules.
>
> I suggest to build a new modules.sqfs with the kernel directory level 
> removed and permanently mounted to /lib/modules/kernel. This way we 
> can avoid to have to copy the modules to /lib/modules completely. We 
> just need to run depmod once the squashfs is mounted, then module 
> loading can be done from the squashfs directly and if user specific 
> modules are needed they can either be on an OverlayFS or be written to 
> a subdirectory of /lib/modules.
>
Permanent squashfs mounting IMHO isn't a good idea - this will require 
permanent underlying device mounting. This is OK when we use mtdblock 
which contains squashfs - but device's flash size usually 4-8 MB, so 
there'll be no free place for modules.sqfs on it. Rest of files will be 
loaded from USB flash, or even from network.

This may be done as option - but IMHO it'll be useful only in some rare 
cases. Because main feature of LEAF - it doesn't require HDD/flash 
storage that is always mounted. Else you may took? for ex., debian, 
install it on flash, mount it's root as r/o on boot and use it...

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Notes after 5.2 release

[Andrew]

30.11.2015 13:41, Erich Titl пишет:
> Am 30.11.2015 um 10:44 schrieb Andrew:
>> 30.11.2015 11:11, Erich Titl пишет:
>>> Hi Andrew
>>>
>>> Am 22.09.2015 um 20:02 schrieb Andrew:
>>>> Hi.
>>>>
>>>> Another important target IMHO - merge all important stuff
>>>> (root.lrp/etc.lrp/config.lrp/other packages that are 100% present in
>>>> LEAF box) into initrd.
>>> Don't do that, initrd is overloaded as it is now,
>> Why you think that using separate packages for that files are better
>> than placing them into initrd? Or you know LEAF usecases when, for ex.,
>> root.lrp with all it's dependencies wasn't loaded?
> I am just afraid of overloading initrd, I need to package it with
> initmod, because grub does not support multple initrd files.
> ..
I think that 850kb instead of 550kb isn't a big difference.
>>> cheers
>>>
>>> ET
>>>
>> Yes, I know that. And this is one of reasons why I want to make solid
>> initrd that will contain all basic stuff that is currently placed in
>> root.lrp and it's deps. Because on embedded platforms with small amount
>> of RAM and available MTD device (that is always connected to SoC) it'll
>> be preferrable to use squashfs initrd that is always mounted (+ mount
>> overlayfs on top of it) rather than copy all stuff from it to valuable RAM.
> If we can place initrd on squashfs this is certainly better. The
> question is here, can we low_level load the squashfs initrd, so we can
> load the storage and network drivers from there?
>
> cheers
>
> ET
>
For embedded platforms, kernel should contain all boot-required modules 
compiled in. And SoC network drivers also may be compiled in kernel, not 
as modules to save some space. Rest of modules (like additional USB 
network adapters, iptables modules and so on) will be compiled as modules.

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Notes after 5.2 release

[Andrew]

30.11.2015 11:11, Erich Titl пишет:
> Hi Andrew
>
> Am 22.09.2015 um 20:02 schrieb Andrew:
>> Hi.
>>
>> Another important target IMHO - merge all important stuff
>> (root.lrp/etc.lrp/config.lrp/other packages that are 100% present in
>> LEAF box) into initrd.
> Don't do that, initrd is overloaded as it is now,
Why you think that using separate packages for that files are better 
than placing them into initrd? Or you know LEAF usecases when, for ex., 
root.lrp with all it's dependencies wasn't loaded?

>   especially with
> initmod, which is heavily overloaded and contains stuff it should not
> (if it is needed at all). For example, not every LEAF box needs traffic
> shaping modules, neither are iptables modules necessary in _all_ LEAF
> boxes. In the past these were optional for a reason.
These modules aren't present in initmod at all. Initmod just contains 
modules that are required for successful booting on any platform 
(PATA/SATA/USB drivers, file systems drivers).

> Please keep in mind that syslinux is not the _only_ boot loader and
> possibly not the best neither, used on LEAF boxes.
>
> cheers
>
> ET
>
Yes, I know that. And this is one of reasons why I want to make solid 
initrd that will contain all basic stuff that is currently placed in 
root.lrp and it's deps. Because on embedded platforms with small amount 
of RAM and available MTD device (that is always connected to SoC) it'll 
be preferrable to use squashfs initrd that is always mounted (+ mount 
overlayfs on top of it) rather than copy all stuff from it to valuable RAM.

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

30.11.2015 10:59, Erich Titl пишет:
> Hi Andrew
>
> Am 30.11.2015 um 00:19 schrieb Andrew:
>> Hi.
>>
>> I just renamed kernel configs corresponding to kernel minor version, not
>> kernel release (in this case - *-4.1.13-* to *-4.1-*).
>>
>> Storing kernel revision in config name IMHO is useless; kernels usually
>> doesn't provide any new config variables in fresh bugfix releases (I
>> can't remember such cases), but kernel update adds useless configs
>> renaming actions.
> Is there a difference in the generated image names?
No. Only kernel configs were renamed.

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

Hi.

I just renamed kernel configs corresponding to kernel minor version, not 
kernel release (in this case - *-4.1.13-* to *-4.1-*).

Storing kernel revision in config name IMHO is useless; kernels usually 
doesn't provide any new config variables in fresh bugfix releases (I 
can't remember such cases), but kernel update adds useless configs 
renaming actions.

30.11.2015 00:23, Erich Titl пишет:
> Hi Andrew
>
> What exactly will this change and why is it necessary?
>
> Thanks
>
> ET
>
>  Weitergeleitete Nachricht 
> Betreff:  [leaf:bering-uclibc] New commit by Andrew Denisenko
> Datum:Sun, 29 Nov 2015 22:20:56 +
> Von:  LEAF Linux Embedded Appliance Framework Git repository
> 
> Antwort an:   LEAF Linux Embedded Appliance Framework Git repository
> 
> An:   LEAF Linux Embedded Appliance Framework Git repository
> 
>
>
>
>  Branch: master
>
> linux: use branch name instead of release name for kernel configs
>
> By Andrew Denisenko on 11/29/2015 22:19
> *View Changes*
> <http://sourceforge.net/p/leaf/bering-uclibc/ci/21287b803c46518f1be6589eb7c3fd8de7f958d6/>
>
> 
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/leaf/bering-uclibc/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>
>
>
>
> --
>
> ___
> 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] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

What files do you mean?
You can check what is changed during merge by 'git diff  

22.11.2015 13:41, Erich Titl пишет:
> Am 22.11.2015 um 11:23 schrieb Andrew:
>> Hi.
>>
>> Merge just touches files which contains fixes.
> Logical, but what about files that are newer?
>
> 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] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

Hi.

Merge just touches files which contains fixes.

21.11.2015 17:29, Erich Titl пишет:
> Am 21.11.2015 um 08:56 schrieb Andrew:
>> Hi.
>>
>> I've added some minor fixes to maint-5.1 branch (for ex.,
>> usbhid-ups-related hiddev nodes privileges), and then merge it to maint
> Ah, and these fixes did not make it to maint before. Is there no risk of
> carrying unwanted backport changes this way? Would a cherry picked
> change not be the more intuitive way?
>
> 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] Fwd: [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

Hi.

I've added some minor fixes to maint-5.1 branch (for ex., 
usbhid-ups-related hiddev nodes privileges), and then merge it to maint

21.11.2015 00:40, Erich Titl пишет:
> Hi Andrew
>
> Just for curiosity, what does this achieve? I don't understand the logic
> in this.
>
> cheers
>
> ET
>
>
>  Weitergeleitete Nachricht 
> Betreff:  [leaf:bering-uclibc] New commit by Andrew Denisenko
> Datum:Fri, 20 Nov 2015 21:25:21 +
> Von:  LEAF Linux Embedded Appliance Framework Git repository
> 
> Antwort an:   LEAF Linux Embedded Appliance Framework Git repository
> 
> An:   LEAF Linux Embedded Appliance Framework Git repository
> 
>
>
>
>  Branch: maint
>
> Merge branch 'maint-5.1' into maint
>
> By Andrew Denisenko on 11/20/2015 21:25
> *View Changes*
> <http://sourceforge.net/p/leaf/bering-uclibc/ci/8d5c3fe9d941afdd541b01c4f151a51db30bb24e/>
>
> 
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/leaf/bering-uclibc/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>
>
>
>
> --
>
> ___
> 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] ipt-ratelimit fails to build

[Andrew]

Hi.

Right, thanks. I missed it. Fixed.

17.10.2015 11:52, kp kirchdoerfer пишет:
> Hi Andrew;
>
> your commit improved build, but still it fails
>
> i486-unknown-linux-uclibc-gcc -Os -march=i486 -mtune=pentiumpro -
> I/opt/buildtool-maint/staging/i486-unknown-linux-uclibc/usr/include -
> I/opt/buildtool-maint/build/i486-unknown-linux-uclibc/iptables/usr/include -O2
> -Wall -Wunused -fPIC -o libxt_ratelimit_sh.o -c libxt_ratelimit.c
> i486-unknown-linux-uclibc-gcc -Os -march=i486 -mtune=pentiumpro -
> I/opt/buildtool-maint/staging/i486-unknown-linux-uclibc/usr/include -
> I/opt/buildtool-maint/build/i486-unknown-linux-uclibc/iptables/usr/include -
> shared -o libxt_ratelimit.so libxt_ratelimit_sh.o
> install -D libxt_ratelimit.so /libxt_ratelimit.so
> install: file  /libxt_ratelimit.so" cannot be created No Permisson
> make[1]: *** [linstall] Error 1
>
> The install target (/) is wrong.
> kp
>
>
> Am Mittwoch, 14. Oktober 2015, 21:56:24 schrieb Andrew:
>> Hi.
>>
>> Hm, strange. Ok, I'll re-check it.
>>
>> 14.10.2015 21:02, kp kirchdoerfer пишет:
>>> Hi Andrew;
>>>
>>> rebuilding from scratch fails with an error
>>>
>>> libxt_ratelimit.c:28:21: fatal error: xtables.h: file not found
>>>
>>>#include 
>>>
>>> A problem in kernel configs?
>>>
>>> Can you pls doublecheck?
>>>
>>> ths kp
>>>
>>> --
>>> 
>>>
>>> ___
>>> 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
>
> --
>
> ___
> 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 should not track conf/buildtool.conf globally

[Andrew]

Hi.

Use buildtool.local instead.

15.10.2015 00:38, Erich Titl пишет:
> Hi Folks
>
> stupid question...
>
> How do you avoid the following
>
> mega@leafbuilder:~/leaf/devel/bering-uclibc$ git status
> Auf Branch maint
> Ihr Branch ist auf dem selben Stand wie 'origin/maint'.
>
> Änderungen, die nicht zum Commit vorgemerkt sind:
>(benutzen Sie "git add ..." um die Änderungen zum Commit
> vorzumerken)
>(benutzen Sie "git checkout -- ..." um die Änderungen im
> Arbeitsverzeichnis zu verwerfen)
>
>  geändert:   conf/buildtool.conf
>
> I just modified the packager name :-(
>
> 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] ipt-ratelimit fails to build

[Andrew]

Hi.

Hm, strange. Ok, I'll re-check it.

14.10.2015 21:02, kp kirchdoerfer пишет:
> Hi Andrew;
>
> rebuilding from scratch fails with an error
>
> libxt_ratelimit.c:28:21: fatal error: xtables.h: file not found
>   #include 
>
> A problem in kernel configs?
>
> Can you pls doublecheck?
>
> ths kp
>
> --
>
> ___
> 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] Fwd: [leaf:packages] New commit by kapeka

[Andrew]

28.09.2015 20:08, Erich Titl пишет:
> Am 28.09.2015 um 17:48 schrieb kp kirchdoerfer:
>> Hello Erich;
>>
>> Am Sonntag, 27. September 2015, 13:55:34 schrieb Erich Titl:
>>> Hi KP
>>> I checked the contents of the 5_2 directory this morning using
>>> build_upgrade
>>>
>>> running build_upgrade with parameters 5.2.x 5_2
>> while this is fine for testing, we'll need more work for a comprehensive
>> solution within the build process.
>> As I said before, some of the packages are committed from packages directory,
>> the kernel from build dir and some finally from the images. This requires a 
>> lot
>> of manual intervention and should be improved.
>> Ideas welcome.
> Well, I did not want to interfere with the current set up although I
> _believe_ it is incoprehensibly complicated. That is why I wrote a tool
> to juggle the content to match a more conventional aproach.
>
> I am not familiar with the tools you use to build the images but stuff
> like that should be completely automatic. I would use a makefile, but
> then I am old fashioned. One thing I would _not_ do is write my own file
> management.
>
> - After a full build and packages build all the packages for each
> release should be in the packages directory and can just be copied
I think that we should copy just packages with different 
versions/release numbers.

--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Notes after 5.2 release

[Andrew]

Hi.

Another important target IMHO - merge all important stuff 
(root.lrp/etc.lrp/config.lrp/other packages that are 100% present in 
LEAF box) into initrd. And try to add support for squashfs initrd + r/w 
tmpfs via overlayfs over top of it (which will be useful for embedded 
devices with mtd flash memory).

22.09.2015 19:27, kp kirchdoerfer пишет:
> For upcoming master it's a good time now to collect ideas.
>
> Just a few that comes in my mind : gcc update, update uclibc to ulibc-ng or
> musl, improve building for different architectures by decoupling kernel
> versions, improvments for build enviroment (e.g. a command like cleanall.sh
> but without deleting the build of repo/toolchain)
>
> kp
>


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] [leaf:bering-uclibc] New commit by Andrew Denisenko

[Andrew]

No, it's build-time dependency.

kmodules package provides sqfs file with modules (+ moddb). So it should 
depends on all packages that provides kernel modules.

06.09.2015 13:59, Erich Titl пишет:
> Hi Andrew
>
> Am 05.09.2015 um 23:26 schrieb LEAF Linux Embedded Appliance Framework 
> Git repository:
>>
>> Branch: master
>>
>> kmodules: depends on accel-ppp due to IPoE driver
>
> Does this imply that kmodules always tries to install accel-ppp?
>
> cheers
>
> Erich
>
>
>
>
> --
>
>
> ___
> 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] 2 new commits to Bering-uClibc

[Andrew]

22.08.2015 22:32, kp kirchdoerfer пишет:
> Am Freitag, 21. August 2015, 22:09:48 schrieb Erich Titl:
>> Hi Andrew
>>
>> Am 21.08.2015 um 16:17 schrieb Andrew:
>>> 21.08.2015 16:29, Erich Titl пишет:
>> ..
>>
>>>> Upgrade does this automagically, maybe not in _all_ circumstances but
>>>> I tested it with a variety of drivers. And then, in reality you only
>>>> need a driver for storage and a driver for uplink. But yes, I see the
>>>> complexity of the problem but I don't see how limiting moddb backup
>>>> can improve this.
>>> Limiting doesn't help. modules.sqfs - helps to solve this.
>> We obviously have different preferences. I don't like autoprobing on
>> each and every boot and you do, so be it. I can easily delete modules.sqfs.
>>
>> cheers
>>
>> ET
> Yes, there are different preferences, and Erich said it'll be easy to remove
> modules.sqfs and use of moddb.lrp though it'll reuire the new config option in
> leaf.cfg.
>
> Let's keep it that way until we'll find a better/more accpeted solution.
>
> This raises a new question - is there a need for 2.3MB moddb.lrp anymore?
> Or can we rework the logic to shrink moddb?
>
> kp
If modules.sqfs is present - moddb isn't needed at all. But for some 
platforms moddb.sqfs may not fit on flash...

--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] 2 new commits to Bering-uClibc

[Andrew]

21.08.2015 16:29, Erich Titl пишет:
> Hi Andrew
>
> Am 21.08.2015 um 11:21 schrieb Andrew:
>> 21.08.2015 12:05, Erich Titl пишет:
>>> Hi
>>>
>>> Am 21.08.2015 um 10:53 schrieb Andrew:...
>>>>>
>>>>> Why keep that thing, it is redundant and needs code to read it.
>>>>>
>>>> Just to reduce moddb size if it'll be needed for somebody. There are
>>>> just some lines of code for handling it.
>>>
>>> Could you specify why someone might need this and where the positive
>>> effect is if he needs modules.sqfs instead?
>>>
>> I said earlier - for custom kernel modules case.
>
> Pretty rare case, but OK
>
>>> To mee it looks like you would need the fully blown modules.sqfs plus
>>> a reduced moddb instead of a slightly bigger moddb an _no_ 
>>> modules.sqfs.
>> moddb causes an one big trouble on kernel update - it should contain all
>> important kernel modules. Including tens of NIC drivers and tens of
>> wireless devices drivers. So, if you have, for ex., Emulex NIC on remote
>> box (which drver isn't included into moddb) - you'll have a headache on
>> remote upgrade; you'll need a physical access to server for running
>> modules autodetection or you should prepare moddb manually - ad module
>> and all its deps. And there's no good solution for this.
>
> Upgrade does this automagically, maybe not in _all_ circumstances but 
> I tested it with a variety of drivers. And then, in reality you only 
> need a driver for storage and a driver for uplink. But yes, I see the 
> complexity of the problem but I don't see how limiting moddb backup 
> can improve this.
>
Limiting doesn't help. modules.sqfs - helps to solve this.

> 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] 2 new commits to Bering-uClibc

[Andrew]

21.08.2015 12:05, Erich Titl пишет:
> Hi
>
> Am 21.08.2015 um 10:53 schrieb Andrew:...
>>>
>>> Why keep that thing, it is redundant and needs code to read it.
>>>
>> Just to reduce moddb size if it'll be needed for somebody. There are
>> just some lines of code for handling it.
>
> Could you specify why someone might need this and where the positive 
> effect is if he needs modules.sqfs instead?
>
I said earlier - for custom kernel modules case.
> To mee it looks like you would need the fully blown modules.sqfs plus 
> a reduced moddb instead of a slightly bigger moddb an _no_ modules.sqfs.
moddb causes an one big trouble on kernel update - it should contain all 
important kernel modules. Including tens of NIC drivers and tens of 
wireless devices drivers. So, if you have, for ex., Emulex NIC on remote 
box (which drver isn't included into moddb) - you'll have a headache on 
remote upgrade; you'll need a physical access to server for running 
modules autodetection or you should prepare moddb manually - ad module 
and all its deps. And there's no good solution for this.

>
> Then... even very innocent looking small code may contain errors :-)
>
> 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] 2 new commits to Bering-uClibc

[Andrew]

21.08.2015 11:14, Erich Titl пишет:
> Hi Andrew
>
> Am 20.08.2015 um 20:25 schrieb Andrew:
>> 20.08.2015 20:40, kp kirchdoerfer пишет:
> ...
>
>>
>> We also may change defaults for UPDATE_MODDB - set it ti true instead of
>> false.
>>
>
> Why keep that thing, it is redundant and needs code to read it.
>
Just to reduce moddb size if it'll be needed for somebody. There are 
just some lines of code for handling it.

> 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] 2 new commits to Bering-uClibc

[Andrew]

20.08.2015 21:47, kp kirchdoerfer пишет:
> Am Donnerstag, 20. August 2015, 21:25:36 schrieb Andrew:
>> 20.08.2015 20:40, kp kirchdoerfer пишет:
>>> HI all;
>>>
>>> maybe we can make a step backwards in this discussion and can think about
>>> my proposal to reduce the pain:
>>>
>>> "The whole pb started here AFAIK:
>>> "Modules that are copied manually, should be saved. Modules that are
>>> loaded from squashfs aren't added to moddb.tgz to reduce it's size."
>>>
>>>
>>> Now we can argue that a user who has enough space for leaving modules.sqfs
>>> on his boot media, will have enough left for a bigger moddb.lrp than
>>> necessary (except those booting from iso image, who can't remove
>>> modules.sqfs).
>>>
>>> There is a case to remove modules.sqfs even beyond space, to speed up boot
>>> time, so autodetection stops immediately due to "missing modules.sqfs".
>>>
>>> So if we go back and never write anything to /var/lib/lrpkg/sqfs.modules
>>> we
>>> can get rid of the changes to update moddb properly, addinga config option
>>> to leaf.cfg  etc...
>>> Andrew,  will there be any other issues related to such a change?"
>> Just slower boot (we should need to unpack 2MB of modules instead of
>> some kb).
> True if the user saves modules and does not delete modules.sqfs.
> IMHO loading from modules.sqfs is  slower than saving modules and delete
> modules.sqfs.
> But if someone is not aware of boot time, there is no need to save modules at
> all.
> The pro would be, that we don't need a new config option.
Somebody may want to use his own precompiled kernel module and don't 
want to waste disk space (for ex., we are still using IDE DOM modules 
32-128M).
In any case, extra config option is better than missed option :)

>> We also may change defaults for UPDATE_MODDB - set it ti true instead of
>> false.
> This is the default right now.
>
> kp
>
>>> kp
>>>
>>> Am Mittwoch, 19. August 2015, 17:28:28 schrieb Andrew:
>>>> 19.08.2015 17:24, Erich Titl пишет:
>>>>> Hi Andrew
>>>>>
>>>>> Am 19.08.2015 um 16:21 schrieb Andrew:
>>>>>> 19.08.2015 17:13, Erich Titl пишет:
>>>>>>> Hi Andrew
>>>>>>>
>>>>>>> Am 19.08.2015 um 16:11 schrieb Andrew:
>>>>>>>> 19.08.2015 17:09, Erich Titl пишет:
>>>>>>>>> Hi Andrew
>>>>> ...
>>>>>
>>>>>>> Yew and IMHO those modules should be replaced by the ones from either
>>>>>>> moddb or autoprobing.
>>>>>> Why them should be duplicated in moddb? What sense of this?
>>>>> Because they got replaced by a version which may be different.
>>>> 1) they are loaded mostly at boot
>>>> 2) there's no alternative USB & so on drivers (non-kernel), and driver
>>>> for other kernel version will not be loaded.
>>>>
>>>>> As I said, stuff in initmod is _temporary_ to me, just for system
>>>>> boot. If I could, I would even replace the kernel on the fly :-) There
>>>>> is no need to have a recent kernel just to fetch sofware on storage,
>>>>> but YMMV
>
> --
>
> ___
> 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] 2 new commits to Bering-uClibc

[Andrew]

20.08.2015 20:40, kp kirchdoerfer пишет:
> HI all;
>
> maybe we can make a step backwards in this discussion and can think about my
> proposal to reduce the pain:
>
> "The whole pb started here AFAIK:
> "Modules that are copied manually, should be saved. Modules that are
> loaded from squashfs aren't added to moddb.tgz to reduce it's size."
>
>
> Now we can argue that a user who has enough space for leaving modules.sqfs on
> his boot media, will have enough left for a bigger moddb.lrp than necessary
> (except those booting from iso image, who can't remove modules.sqfs).
>   
> There is a case to remove modules.sqfs even beyond space, to speed up boot
> time, so autodetection stops immediately due to "missing modules.sqfs".
>
> So if we go back and never write anything to /var/lib/lrpkg/sqfs.modules we
> can get rid of the changes to update moddb properly, addinga config option to
> leaf.cfg  etc...
> Andrew,  will there be any other issues related to such a change?"
Just slower boot (we should need to unpack 2MB of modules instead of 
some kb).

We also may change defaults for UPDATE_MODDB - set it ti true instead of 
false.

> kp
>
> Am Mittwoch, 19. August 2015, 17:28:28 schrieb Andrew:
>> 19.08.2015 17:24, Erich Titl пишет:
>>> Hi Andrew
>>>
>>> Am 19.08.2015 um 16:21 schrieb Andrew:
>>>> 19.08.2015 17:13, Erich Titl пишет:
>>>>> Hi Andrew
>>>>>
>>>>> Am 19.08.2015 um 16:11 schrieb Andrew:
>>>>>> 19.08.2015 17:09, Erich Titl пишет:
>>>>>>> Hi Andrew
>>> ...
>>>
>>>>> Yew and IMHO those modules should be replaced by the ones from either
>>>>> moddb or autoprobing.
>>>> Why them should be duplicated in moddb? What sense of this?
>>> Because they got replaced by a version which may be different.
>> 1) they are loaded mostly at boot
>> 2) there's no alternative USB & so on drivers (non-kernel), and driver
>> for other kernel version will not be loaded.
>>
>>> As I said, stuff in initmod is _temporary_ to me, just for system
>>> boot. If I could, I would even replace the kernel on the fly :-) There
>>> is no need to have a recent kernel just to fetch sofware on storage,
>>> but YMMV
>>>
>>> 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
>
> --
>
> ___
> 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] 2 new commits to Bering-uClibc

[Andrew]

19.08.2015 17:24, Erich Titl пишет:
> Hi Andrew
>
> Am 19.08.2015 um 16:21 schrieb Andrew:
>> 19.08.2015 17:13, Erich Titl пишет:
>>> Hi Andrew
>>>
>>> Am 19.08.2015 um 16:11 schrieb Andrew:
>>>> 19.08.2015 17:09, Erich Titl пишет:
>>>>> Hi Andrew
>>>>>
> ...
>
>>>
>>> Yew and IMHO those modules should be replaced by the ones from either
>>> moddb or autoprobing.
>>>
>> Why them should be duplicated in moddb? What sense of this?
>
> Because they got replaced by a version which may be different.
1) they are loaded mostly at boot
2) there's no alternative USB & so on drivers (non-kernel), and driver 
for other kernel version will not be loaded.

> As I said, stuff in initmod is _temporary_ to me, just for system 
> boot. If I could, I would even replace the kernel on the fly :-) There 
> is no need to have a recent kernel just to fetch sofware on storage, 
> but YMMV
>
> 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] 2 new commits to Bering-uClibc

[Andrew]

19.08.2015 17:13, Erich Titl пишет:
> Hi Andrew
>
> Am 19.08.2015 um 16:11 schrieb Andrew:
>> 19.08.2015 17:09, Erich Titl пишет:
>>> Hi Andrew
>>>
>>> Am 19.08.2015 um 16:06 schrieb Andrew:
>>>> 19.08.2015 16:55, Erich Titl пишет:
>>>>> Hi Andrew
>>>>>
>>>>> Am 19.08.2015 um 13:25 schrieb Andrew:
>>>>>> 19.08.2015 12:23, Erich Titl пишет:
>>>>>>> Hi Andrew
>>>>>>>
>>>>>>> Am 19.08.2015 um 11:16 schrieb Andrew:
>>>>>>> ...
>>>>>>>
>>>>>>>>>>
>>>>>>>>>> /var/lib/lrpkg/modules.sqfs
>>>>>>>>>
>>>>>>>>> What is this file for? If it is used to tell which modules to 
>>>>>>>>> fetch
>>>>>>>>> from where then the whole point of autodetection is questionable?
>>>>>>>>>
>>>>>>>> /var/lib/lrpkg/*.modules provides list of modules that are loaded
>>>>>>>> from
>>>>>>>> LRP (for ex., initmod.modules) so should be omitted when moddb is
>>>>>>>> created.
>>>>>>>
>>>>>>> Who does create and maintain this file, to tell you the truth, the
>>>>>>> less lists we need to maintain the better.
>>>>>> It's created automatically - by buildtool (if specified 'module' 
>>>>>> type
>>>>>> for file) or, for sqfs, by init or hwdetect.
>>>>>
>>>>> How does buildtool know what the end user wants?
>>>> Kernel modules that are provided via .lrp packages (in our case -
>>>> initmod)
>>>
>>> I agree, I would even remove them from /lib/modules when loading moddb
>>> and/or autoprobing. To me stuff in initmod is temporary for booting.
>>>
>> USB modules are also there. And inserting/removing for ex., USB flash
>> needs available modules.
>
> Yew and IMHO those modules should be replaced by the ones from either 
> moddb or autoprobing.
>
Why them should be duplicated in moddb? What sense of this?

> 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] 2 new commits to Bering-uClibc

[Andrew]

19.08.2015 17:09, Erich Titl пишет:
> Hi Andrew
>
> Am 19.08.2015 um 16:06 schrieb Andrew:
>> 19.08.2015 16:55, Erich Titl пишет:
>>> Hi Andrew
>>>
>>> Am 19.08.2015 um 13:25 schrieb Andrew:
>>>> 19.08.2015 12:23, Erich Titl пишет:
>>>>> Hi Andrew
>>>>>
>>>>> Am 19.08.2015 um 11:16 schrieb Andrew:
>>>>> ...
>>>>>
>>>>>>>>
>>>>>>>> /var/lib/lrpkg/modules.sqfs
>>>>>>>
>>>>>>> What is this file for? If it is used to tell which modules to fetch
>>>>>>> from where then the whole point of autodetection is questionable?
>>>>>>>
>>>>>> /var/lib/lrpkg/*.modules provides list of modules that are loaded 
>>>>>> from
>>>>>> LRP (for ex., initmod.modules) so should be omitted when moddb is
>>>>>> created.
>>>>>
>>>>> Who does create and maintain this file, to tell you the truth, the
>>>>> less lists we need to maintain the better.
>>>> It's created automatically - by buildtool (if specified 'module' type
>>>> for file) or, for sqfs, by init or hwdetect.
>>>
>>> How does buildtool know what the end user wants?
>> Kernel modules that are provided via .lrp packages (in our case -
>> initmod)
>
> I agree, I would even remove them from /lib/modules when loading moddb 
> and/or autoprobing. To me stuff in initmod is temporary for booting.
>
USB modules are also there. And inserting/removing for ex., USB flash 
needs available modules.

> 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] 2 new commits to Bering-uClibc

[Andrew]

19.08.2015 16:55, Erich Titl пишет:
> Hi Andrew
>
> Am 19.08.2015 um 13:25 schrieb Andrew:
>> 19.08.2015 12:23, Erich Titl пишет:
>>> Hi Andrew
>>>
>>> Am 19.08.2015 um 11:16 schrieb Andrew:
>>> ...
>>>
>>>>>>
>>>>>> /var/lib/lrpkg/modules.sqfs
>>>>>
>>>>> What is this file for? If it is used to tell which modules to fetch
>>>>> from where then the whole point of autodetection is questionable?
>>>>>
>>>> /var/lib/lrpkg/*.modules provides list of modules that are loaded from
>>>> LRP (for ex., initmod.modules) so should be omitted when moddb is
>>>> created.
>>>
>>> Who does create and maintain this file, to tell you the truth, the
>>> less lists we need to maintain the better.
>> It's created automatically - by buildtool (if specified 'module' type
>> for file) or, for sqfs, by init or hwdetect.
>
> How does buildtool know what the end user wants?
Kernel modules that are provided via .lrp packages (in our case - 
initmod) shouldn't be saved to moddb. They'll be in /etc/modules in any 
case.

>
> 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] 2 new commits to Bering-uClibc

[Andrew]

19.08.2015 12:23, Erich Titl пишет:
> Hi Andrew
>
> Am 19.08.2015 um 11:16 schrieb Andrew:
> ...
>
>>>>
>>>> /var/lib/lrpkg/modules.sqfs
>>>
>>> What is this file for? If it is used to tell which modules to fetch
>>> from where then the whole point of autodetection is questionable?
>>>
>> /var/lib/lrpkg/*.modules provides list of modules that are loaded from
>> LRP (for ex., initmod.modules) so should be omitted when moddb is 
>> created.
>
> Who does create and maintain this file, to tell you the truth, the 
> less lists we need to maintain the better.
It's created automatically - by buildtool (if specified 'module' type 
for file) or, for sqfs, by init or hwdetect.

>
> Basically I understand the modules in initmod (or initrd) as temporary 
> just enabling the system to access storage and possibly network 
> resources for the _real_ modules. This is why I would like to see 
> initmod shrink to an absolute minimum.
>
> 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] 2 new commits to Bering-uClibc

[Andrew]

18.08.2015 23:19, Erich Titl пишет:
> Hi KP
>
> Am 18.08.2015 um 19:19 schrieb kp kirchdoerfer:
>> Am Montag, 17. August 2015, 21:35:07 schrieb Erich Titl:
>>> Am 17.08.2015 um 17:57 schrieb kp kirchdoerfer:
 Hi Erich;

> ...
>
>>> sqfs is a read only filesystem
>>
>> I know.
>> But as I wrote
>>
>> "T he whole pb started here AFAIK:
>>   "Modules that are copied manually, should be saved. Modules that are
>>   loaded from squashfs aren't added to moddb.tgz to reduce it's size.""
>>
>> Not saving modules loaded from sqfs is accomplished by adding those to
>>
>> /var/lib/lrpkg/modules.sqfs
>
> What is this file for? If it is used to tell which modules to fetch 
> from where then the whole point of autodetection is questionable?
>
/var/lib/lrpkg/*.modules provides list of modules that are loaded from 
LRP (for ex., initmod.modules) so should be omitted when moddb is created.
> Unless there is a good reason for this file, which I don't understand, 
> get rid of it.
>
> 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] Fwd: [leaf:bering-uclibc] 2 new commits to Bering-uClibc

[Andrew]

If no option UPDATE_MODDB is in leaf.cfg nor in kernel cmdline -
behavior is same as earlier (modules that were probed from squash aren't
stored in moddb.

16.08.2015 18:42, Erich Titl пишет:
>
> Gr.
>
> So we have to update leaf.cfg, what a shame.
> It should be automatic.
>
> cheers
>
> ET
>
>  Weitergeleitete Nachricht 
> Betreff: [leaf:bering-uclibc] 2 new commits to Bering-uClibc
> Datum: Sun, 16 Aug 2015 15:06:49 +
> Von: LEAF Linux Embedded Appliance Framework Git repository
> 
> Antwort an: LEAF Linux Embedded Appliance Framework Git repository
> 
> An: LEAF Linux Embedded Appliance Framework Git repository
> 
>
>
>
> Branch: master
>
> add possible values for UPDATE_MODDB
>
> By kapeka on 08/16/2015 14:24
> *View Changes*
> 
>
>
> 
>
> add UPDATE_MODDB option
>
> with a short explanation, pls check
>
> By kapeka on 08/16/2015 14:22
> *View Changes*
> 
>
>
> 
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/leaf/bering-uclibc/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>
>
>
>
>
>
> --
>
>
> ___
> 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] 5.2-trunk seems to be unstable.

[Andrew]

16.08.2015 14:13, Erich Titl пишет:
> Hi Andrew
>
> Am 16.08.2015 um 13:10 schrieb Andrew:
>> 16.08.2015 13:30, Erich Titl пишет:
> 
>
>>>
>>> Or maybe a bug in accel-ppp?
>>>
>> Userland tools shouldn't cause kernel errors - so it's kernel bug.
>
> I don't know how one can accelerate ppp without plugging into the 
> kernel interface, maybe with ioctl calls. Whatever, if it only happens 
> with accel-ppp I would be reluctant to put it on the kernel only :-(
>
Accel-ppp is just PPTP/PPPoE/L2TP/IPoE BRAS server, like rp-pppoe but 
with more extra features (something like BSD mpd). For PPTP/L2TP/PPPoE 
it doesnt use any 3rd-party modules, for IPoE (ISG-like) it uses kernel 
module for creating pseudo-interfaces but this isn't my case.

> cheers
>
> Erich
>
>
>
>
> --
>
>
> ___
> 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] 5.2-trunk seems to be unstable.

[Andrew]

16.08.2015 13:30, Erich Titl пишет:
> Hi Andrew
>
> Am 16.08.2015 um 12:25 schrieb Andrew:
>> Hi.
>>
>> 16.08.2015 13:08, Erich Titl пишет:
>>> Hi Andrew
>>>
>>> Am 15.08.2015 um 17:50 schrieb Andrew:
>>>> After month of uptime I've got crash again. It seems that crash caused
>>>> by shaper removing from ppp interface before it's deletion, which 
>>>> causes
>>>> race condition.
>>>
>>> Why does this cause a race condition? You should be able to remove a
>>> shaper without the system crashing.
>>>
>> Interface is shutted down and destroyed, and before this - shaper qdiscs
>> were deleted by script.
>
> Appears logical
>
> This isn't required, in any case on ip-up we
>> also tried to delete root/ingress qdisc before creating new shaper 
>> classes.
>
> Mhhh I don't recall the samantics, but why should we delete the 
> root/ingress qdisc for a single inerface?
>
I mean PPP interface. It'll be safer to clean qdisc before creating a 
new one - it will not hurt anything if there's no qdisc atached, and it 
will clean attached earlier qdisc if it's present (for ex., if accel-ppp 
interface caching is used).

>>
>> I think that either accel-ppp doesn't wait for ip-down script
>> termination before deleting interface, or kernel cleans structures
>> asynchronously without locks - so in some cases kernel tries to remove
>> shaper twice simultaneously, that causes bug.
>>> Did you get a response from kernel.org?
>>>
>> No, still no response. Here is bug:
>> https://bugzilla.kernel.org/show_bug.cgi?id=100971
>>>>
>>>> I removed shaper delete from scripts, and I think that this'll fix 
>>>> bug.
>>>
>>> No it just avoids it.
>> In any case, alternative - wait for fix in upstream - isn't a good idea
>> (no response for month).
>> Other accel-ppp user said that he has no troubles with it - he has no
>> shaper cleanup on shutdown.
>
> Or maybe a bug in accel-ppp?
>
Userland tools shouldn't cause kernel errors - so it's kernel bug.
> cheers
>
> ET


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel