Re: [leaf-devel] Future packaging
Am Montag, 14. Oktober 2013, 18:55:27 schrieb Erich Titl: > on 14.10.2013 17:24, KP Kirchdörfer wrote: > > Am Montag, 14. Oktober 2013, 00:19:52 schrieb Erich Titl: > >> on 12.10.2013 19:43, KP Kirchdörfer wrote: > >>> Hi Erich; > >>> > >>> Am Mittwoch, 9. Oktober 2013, 10:32:02 schrieb Erich Titl: > HI Folks > > I have fought a bit with my new 5.01 installation on a WRAP and I am > still wrestling to get it up and running the way I want. > > I have a few requests for future packaging > > - Could we refrain from placing the modules in a flat directory, it > makes the modules directory horribly unreadable and I don't see any > benefit.> > >>> > >>> And what is your proposal? > >> > >> Keep the structure as is after compiling > >> > >>> Currently it does have the benefit that it works to add modules without > >>> thinking where to add (scp to /lib/modules is good enough), that > >>> hardware > >>> detection knows where to place modules and backing up modules is also > >>> easy. > >> > >> Mhhh... ist that dependent on the tree structure? > > > > Detection works with the tree structure in the modules tarball, but > > storing > > the modules will be affetced. > > > > If that is changed I think we do need to rework and test > > buildpacket.pl > > apkg (for saving modules in moddb) > > I am using it with a tree structure, works fine Good; I wasn't even aware that this approach works. > > hardware detection (see above) > > No idea how it was implemented. > > > loading modules from modules.conf > > M I thought that worked, but it is easy to test. > > > and test if packages like shorewall work... > > Shorewall does not even start on my site as some perl modules are > missing. But that is another story. > > > So this will be IMHO a huge task. > > Maybe, maybe not. Ok, once yo'll get a working toolchain, you can branch master and work on a tree-structured /lib/modules. If you make the branhc accessible we can test it. > >>> So if one wants change to the modules directory layout, some things need > >>> to be considered - and I do not see a real benefit to invest that amount > >>> of work. BTW What exactly is your pb with "readibility"? > > do a ls -l in /lib/modules and tall me if you see a*xxx without > scrolling. The Linux kernel developers use a structure, my server uses a > structure, why doesn't LEAF? For historical reasons and manpower? > > Understand. But the amount of unneeded modules is not related to a flat or > > tree structure. Either way you'll have to find a way to find and remove > > them, and it will not be easier with a tree structure. > > Sure, I can remove whole directories. True. > > David explained in the wiki, how to modify initmod (and initrd if you > > want) > > from within a LEAF box. This also should work on your build machine. > > I know how to do it, I do it with every recent release. It's just work. > > - Could we make a version with minimal modules in initmod? You may > think > this is unpractical, but for myself I found that in initmod there is no > natsemi driver so most of the modules there are not needed. Whatever > you > choose It will be the wrong choice most of the time, but it is > overloading small platforms. > > ... > > > ok, but then how can we distribute that changes? > > Currently we have toolchains for an architecture (i386, > > x86_64,arm-versatile) and "subarchs" (in the case of i386: i686 i486 > > geode). > > For each toolchain and it's subarchs we create seperate images. One of > > these is called GEODE, and while this one is closely related to the PC > > Engines Alix box, it is a bit more generic - it provides modules that > > aren't needed to run LEAF Bering-uClibc on an Alix board. > > We could probably easily do that by adding more targets in the > buildtool.conf files for initrd. initrd is agnostic of kernel versions, I guess you mean initmod? But again, any idea how we can distribute it? > > So far it's a clear way. Don't know how a "to tool to create a specfic > > initmod" can lead to something distributable? > > > > > > Isn't such a tool only handy, if someone is able to use git, the > > toolchain, > > buildtool etc? > > I don't think it needs any access to the toolchain. We build all the > modules anyway, it only needs a way to combine them. > > > If so, I think it would be easier to read Davids wiki chapter and to play > > with pxeboot - at least for the very first boot and installtion on a CF. > It would be a way, but how can you be sure your box is accessible after > a pxeboot if the nat driver is missing and the serial line is dead > because of a forgotten commented entry in /etc/inittab? This is the > _reality_ right now with the serial distribution. You can't be shure. If I make an error, I'll to figure it and have to reboot via pxeboot. > - I may be horribly old fashioned, but how many of you are really using >
Re: [leaf-devel] Future packaging
on 14.10.2013 17:24, KP Kirchdörfer wrote: > Am Montag, 14. Oktober 2013, 00:19:52 schrieb Erich Titl: >> on 12.10.2013 19:43, KP Kirchdörfer wrote: >>> Hi Erich; >>> >>> Am Mittwoch, 9. Oktober 2013, 10:32:02 schrieb Erich Titl: HI Folks I have fought a bit with my new 5.01 installation on a WRAP and I am still wrestling to get it up and running the way I want. I have a few requests for future packaging - Could we refrain from placing the modules in a flat directory, it makes the modules directory horribly unreadable and I don't see any benefit.> >>> And what is your proposal? >> >> Keep the structure as is after compiling >> >>> Currently it does have the benefit that it works to add modules without >>> thinking where to add (scp to /lib/modules is good enough), that hardware >>> detection knows where to place modules and backing up modules is also >>> easy. >> >> Mhhh... ist that dependent on the tree structure? > > Detection works with the tree structure in the modules tarball, but storing > the modules will be affetced. > > If that is changed I think we do need to rework and test > buildpacket.pl > apkg (for saving modules in moddb) I am using it with a tree structure, works fine > hardware detection (see above) No idea how it was implemented. > loading modules from modules.conf M I thought that worked, but it is easy to test. > > and test if packages like shorewall work... Shorewall does not even start on my site as some perl modules are missing. But that is another story. > > So this will be IMHO a huge task. Maybe, maybe not. > > >>> So if one wants change to the modules directory layout, some things need >>> to be considered - and I do not see a real benefit to invest that amount >>> of work. BTW What exactly is your pb with "readibility"? do a ls -l in /lib/modules and tall me if you see a*xxx without scrolling. The Linux kernel developers use a structure, my server uses a structure, why doesn't LEAF? > > Understand. But the amount of unneeded modules is not related to a flat or > tree > structure. Either way you'll have to find a way to find and remove them, and > it > will not be easier with a tree structure. Sure, I can remove whole directories. > > David explained in the wiki, how to modify initmod (and initrd if you want) > from within a LEAF box. This also should work on your build machine. I know how to do it, I do it with every recent release. It's just work. > - Could we make a version with minimal modules in initmod? You may think this is unpractical, but for myself I found that in initmod there is no natsemi driver so most of the modules there are not needed. Whatever you choose It will be the wrong choice most of the time, but it is overloading small platforms. ... > > > ok, but then how can we distribute that changes? > Currently we have toolchains for an architecture (i386, x86_64,arm-versatile) > and "subarchs" (in the case of i386: i686 i486 geode). > For each toolchain and it's subarchs we create seperate images. One of these > is called GEODE, and while this one is closely related to the PC Engines Alix > box, it is a bit more generic - it provides modules that aren't needed to run > LEAF Bering-uClibc on an Alix board. We could probably easily do that by adding more targets in the buildtool.conf files for initrd. > > So far it's a clear way. Don't know how a "to tool to create a specfic > initmod" > can lead to something distributable? > > Isn't such a tool only handy, if someone is able to use git, the toolchain, > buildtool etc? I don't think it needs any access to the toolchain. We build all the modules anyway, it only needs a way to combine them. > If so, I think it would be easier to read Davids wiki chapter and to play > with > pxeboot - at least for the very first boot and installtion on a CF. > It would be a way, but how can you be sure your box is accessible after a pxeboot if the nat driver is missing and the serial line is dead because of a forgotten commented entry in /etc/inittab? This is the _reality_ right now with the serial distribution. - I may be horribly old fashioned, but how many of you are really using IPv6. Despite all the ballyhoo it is still not widely used (in Europe) and IMHO it should be an option. The future may prove me wrong. >>> ... > > At the beginning I had a tunnel to EricH, who did most of the work for 2.0, > later I started use sixxs.net until today. Until now it may sound academic as > well, since I haven't seen any IPv6-only site yet and it's still a tunnel > via > IPv4. > But if I'd not be too lazy to deal with VDSL (need a new modem, and a cheap > one that fit my needs is not easy to find, but thats something for another > thread), I'd have a dual stack right now from my Telco. > OK, my ISP is not offering IPV6 and will probably not in the next decade. I have hear
Re: [leaf-devel] Future packaging
Am Montag, 14. Oktober 2013, 00:19:52 schrieb Erich Titl: > on 12.10.2013 19:43, KP Kirchdörfer wrote: > > Hi Erich; > > > > Am Mittwoch, 9. Oktober 2013, 10:32:02 schrieb Erich Titl: > >> HI Folks > >> > >> I have fought a bit with my new 5.01 installation on a WRAP and I am > >> still wrestling to get it up and running the way I want. > >> > >> I have a few requests for future packaging > >> > >> - Could we refrain from placing the modules in a flat directory, it > >> makes the modules directory horribly unreadable and I don't see any > >> benefit.> > > And what is your proposal? > > Keep the structure as is after compiling > > > Currently it does have the benefit that it works to add modules without > > thinking where to add (scp to /lib/modules is good enough), that hardware > > detection knows where to place modules and backing up modules is also > > easy. > > Mhhh... ist that dependent on the tree structure? Detection works with the tree structure in the modules tarball, but storing the modules will be affetced. If that is changed I think we do need to rework and test buildpacket.pl apkg (for saving modules in moddb) hardware detection (see above) loading modules from modules.conf and test if packages like shorewall work... So this will be IMHO a huge task. > > So if one wants change to the modules directory layout, some things need > > to be considered - and I do not see a real benefit to invest that amount > > of work. BTW What exactly is your pb with "readibility"? > > Multiple pages of unneeded modules Understand. But the amount of unneeded modules is not related to a flat or tree structure. Either way you'll have to find a way to find and remove them, and it will not be easier with a tree structure. David explained in the wiki, how to modify initmod (and initrd if you want) from within a LEAF box. This also should work on your build machine. (http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_5.x_-_User_Guide_-_Advanced_Topics_-_Modifying_initrd.lrp) > >> - Could we make a version with minimal modules in initmod? You may think > >> this is unpractical, but for myself I found that in initmod there is no > >> natsemi driver so most of the modules there are not needed. Whatever you > >> choose It will be the wrong choice most of the time, but it is > >> overloading small platforms. > >> > >> - It might be practical to provide a small tool to build a customized > >> initmod from the modules tarball. Autodetection is a fine idea if you > >> have memory to spare. The upside of all the distros which are targeting > >> a single platform is that they can and do customize their kernel and > >> thus can live with a very small footprint. > >> > >> - I suggest to add a few pseudo targets to the build process, which do > >> not require a recompile of the kernel but a rearrangement of initrd and > >> initmod ... like WRAP, ALIX, hopefully soon something like TP-xxx. > > > > I might be wrong, but to summarize the answer to three notes above, I's > > suggest you may have a look how we provide a i486/i686/geode-based > > versions > > from the same toolchain. > > I will, as soon as I get the #@%&$£ toolchain running. The prerequisites > are a royal pain in the butt. > > > I do agree with you that the default initmod is bloated, I see modules in > > the geode version, which are usually not needed. > > > > Therefor it might be a solution to add a new target (wrap) in addition to > > i486/i686/geode and to improve the default initmod creation to remove/add > > what's needed for a variant. > > I tried that a year ago, but was stopped by the multiple platform move > then. Calling a platform GEODE does not assert that we are using the > correct NIC driver and Andrew war right, it does not need another > platform. It needs a tool to create a specific initrd. ok, but then how can we distribute that changes? Currently we have toolchains for an architecture (i386, x86_64,arm-versatile) and "subarchs" (in the case of i386: i686 i486 geode). For each toolchain and it's subarchs we create seperate images. One of these is called GEODE, and while this one is closely related to the PC Engines Alix box, it is a bit more generic - it provides modules that aren't needed to run LEAF Bering-uClibc on an Alix board. So far it's a clear way. Don't know how a "to tool to create a specfic initmod" can lead to something distributable? Isn't such a tool only handy, if someone is able to use git, the toolchain, buildtool etc? If so, I think it would be easier to read Davids wiki chapter and to play with pxeboot - at least for the very first boot and installtion on a CF. > >> - I may be horribly old fashioned, but how many of you are really using > >> IPv6. Despite all the ballyhoo it is still not widely used (in Europe) > >> and IMHO it should be an option. The future may prove me wrong. > > > > While IPv6 generated a lot of noise before, it's adoption seems to be > >
Re: [leaf-devel] Future packaging
on 12.10.2013 19:43, KP Kirchdörfer wrote: > Hi Erich; > > Am Mittwoch, 9. Oktober 2013, 10:32:02 schrieb Erich Titl: >> HI Folks >> >> I have fought a bit with my new 5.01 installation on a WRAP and I am >> still wrestling to get it up and running the way I want. >> >> I have a few requests for future packaging >> >> - Could we refrain from placing the modules in a flat directory, it >> makes the modules directory horribly unreadable and I don't see any benefit. > > And what is your proposal? Keep the structure as is after compiling > > Currently it does have the benefit that it works to add modules without > thinking where to add (scp to /lib/modules is good enough), that hardware > detection knows where to place modules and backing up modules is also easy. Mhhh... ist that dependent on the tree structure? > > So if one wants change to the modules directory layout, some things need to > be > considered - and I do not see a real benefit to invest that amount of work. > BTW What exactly is your pb with "readibility"? Multiple pages of unneeded modules > >> - Could we make a version with minimal modules in initmod? You may think >> this is unpractical, but for myself I found that in initmod there is no >> natsemi driver so most of the modules there are not needed. Whatever you >> choose It will be the wrong choice most of the time, but it is >> overloading small platforms. >> >> - It might be practical to provide a small tool to build a customized >> initmod from the modules tarball. Autodetection is a fine idea if you >> have memory to spare. The upside of all the distros which are targeting >> a single platform is that they can and do customize their kernel and >> thus can live with a very small footprint. >> >> - I suggest to add a few pseudo targets to the build process, which do >> not require a recompile of the kernel but a rearrangement of initrd and >> initmod ... like WRAP, ALIX, hopefully soon something like TP-xxx. > > I might be wrong, but to summarize the answer to three notes above, I's > suggest you may have a look how we provide a i486/i686/geode-based versions > from the same toolchain. I will, as soon as I get the #@%&$£ toolchain running. The prerequisites are a royal pain in the butt. > > I do agree with you that the default initmod is bloated, I see modules in the > geode version, which are usually not needed. > > Therefor it might be a solution to add a new target (wrap) in addition to > i486/i686/geode and to improve the default initmod creation to remove/add > what's needed for a variant. I tried that a year ago, but was stopped by the multiple platform move then. Calling a platform GEODE does not assert that we are using the correct NIC driver and Andrew war right, it does not need another platform. It needs a tool to create a specific initrd. > > >> - I may be horribly old fashioned, but how many of you are really using >> IPv6. Despite all the ballyhoo it is still not widely used (in Europe) >> and IMHO it should be an option. The future may prove me wrong. > > While IPv6 generated a lot of noise before, it's adoption seems to be more > or > less seamless. I've read that some ISP/Telcos started to enable IPv6 for new > accounts without further notice. > We've added and enabled IPv6 support about ten years ago with Bering-uClibc > 2.0 - why should we make it an option just at the time, our work bears it > fruits? I'd rather like to make it as useful as possible. Again, it is something that diverts me, but then. I have not had a chance to talk to any IPv6 platform at all and I _assume_ no one else outside of academia and possibly some specialized ISP in switzerland has had that chance. How do you guys talk to IPv6? cheers Erich smime.p7s Description: S/MIME Cryptographic Signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Future packaging
Hi Erich; Am Mittwoch, 9. Oktober 2013, 10:32:02 schrieb Erich Titl: > HI Folks > > I have fought a bit with my new 5.01 installation on a WRAP and I am > still wrestling to get it up and running the way I want. > > I have a few requests for future packaging > > - Could we refrain from placing the modules in a flat directory, it > makes the modules directory horribly unreadable and I don't see any benefit. And what is your proposal? Currently it does have the benefit that it works to add modules without thinking where to add (scp to /lib/modules is good enough), that hardware detection knows where to place modules and backing up modules is also easy. So if one wants change to the modules directory layout, some things need to be considered - and I do not see a real benefit to invest that amount of work. BTW What exactly is your pb with "readibility"? > - Could we make a version with minimal modules in initmod? You may think > this is unpractical, but for myself I found that in initmod there is no > natsemi driver so most of the modules there are not needed. Whatever you > choose It will be the wrong choice most of the time, but it is > overloading small platforms. > > - It might be practical to provide a small tool to build a customized > initmod from the modules tarball. Autodetection is a fine idea if you > have memory to spare. The upside of all the distros which are targeting > a single platform is that they can and do customize their kernel and > thus can live with a very small footprint. > > - I suggest to add a few pseudo targets to the build process, which do > not require a recompile of the kernel but a rearrangement of initrd and > initmod ... like WRAP, ALIX, hopefully soon something like TP-xxx. I might be wrong, but to summarize the answer to three notes above, I's suggest you may have a look how we provide a i486/i686/geode-based versions from the same toolchain. I do agree with you that the default initmod is bloated, I see modules in the geode version, which are usually not needed. Therefor it might be a solution to add a new target (wrap) in addition to i486/i686/geode and to improve the default initmod creation to remove/add what's needed for a variant. > - I may be horribly old fashioned, but how many of you are really using > IPv6. Despite all the ballyhoo it is still not widely used (in Europe) > and IMHO it should be an option. The future may prove me wrong. While IPv6 generated a lot of noise before, it's adoption seems to be more or less seamless. I've read that some ISP/Telcos started to enable IPv6 for new accounts without further notice. We've added and enabled IPv6 support about ten years ago with Bering-uClibc 2.0 - why should we make it an option just at the time, our work bears it fruits? I'd rather like to make it as useful as possible. kp -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
