Re: [leaf-devel] Bering uClibc with Kernel 2.6
On Friday 14 March 2008 21:20:52 Martin Hejl wrote: Hi John, this is a little depressing. After spending years (and tons of emails) discussing the need for a kernel 2.6 version of LEAF, there has been no response on this list on the topic. Sorry, Martin, I only read the list as a newsgroup, every week or so. No problem. I just started to doubt the value of the time spent (and not mainly by me - Dirk and Eric put in as much, if not more, time as I have). It's not about ego (hence my line about not looking for a good job, well done response), it's simply about finding out if one is wasting one's time. I don't gain anything if people use the new branch (or Bering uClibc, or any other LEAF branch), so if I'm working on something that nobody is really interested in, I guess I'd better stop wasting my time and do something more productive. If there is interest, and people will use it (and some will contribute), it's much easier to justify the time spent. To me, that's really all it comes down to. Martin; I think your and your colleagues efforts aren't waisted: firewall# apkg -l initrd26 root 4.0 Rev 0 uClibc 0.9.28 config 0.6 Rev 8 uClibc 0.9.28 etc 4.0 Rev 0 uClibc 0.9.28 modules 2.6.x Rev 0 uClibc 0.9.28 iptables 1.4.0 Rev 0 uClibc 0.9.28 ppp 2.4.4 Rev 3 uClibc 0.9.28 pppoe 2.4.4 Rev 2 uClibc 0.9.28 keyboard 1.1 Rev 2 uClibc 0.9.28 shorwall 3.4.7 Rev 1 uClibc 0.9.28 ulogd 1.24 Rev 6 uClibc 0.9.28 dnsmasq 2.40 Rev 1 uClibc 0.9.28 dropbear 0.50 Rev 3 uClibc 0.9.28 mhttpd 1.19 Rev 6 uClibc 0.9.28 openntpd 3.9p1 Rev 3 uClibc 0.9.28 webconf 1.1.3 Rev 3 uClibc 0.9.28 configdb moddb firewall# uname -a Linux firewall 2.6.24.2 #1 Sun Feb 17 14:31:32 CET 2008 i586 unknown firewall# ping leaf.sourceforge.net PING leaf.sourceforge.net (66.35.250.209): 56 data bytes 64 bytes from 66.35.250.209: seq=0 ttl=53 time=220.237 ms 64 bytes from 66.35.250.209: seq=1 ttl=53 time=250.771 ms This is a lot more, than I expected from the first alpha version! I had to add two more netfilter modules to get shorewall running (xt_limit, xt_TCPMSS), but anything else was out of the box. So you provided a good base to develop a 2.6 versin further to production quality. kp - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
On Saturday 08 March 2008 13:30:04 Erich Titl wrote: Hi Martin Martin Hejl wrote, at 07.03.2008 21:56: Hi all, this is a little depressing. After spending years (and tons of emails) discussing the need for a kernel 2.6 version of LEAF, there has been no response on this list on the topic. Is somebody actually interested in continued work on that image (and has just not had an issue with it what I've posted last Saturday), or did I scare off people with my too verbose email, or is there just no interest, as long as somebody provides the drivers for the hardware people need? Actually playing with e1000 for 2.4 reset me a little lately. Definitely I am convinced that if LEAF wants to go on strongly we need to be on par with other project which do similar work, e.g. 2.6 is a must. And for all your effort which point into the future here it is _WELL DONE_ One of my concerns in the 2.6 branch will be IPSEC, as now we need to use the native stack. It appears that with using the native stack IPSEC will be an application like any other, so we may have now the benefit of using Strongswan's IKEv2 implementation :-) Anyway, I need to probably get two buidltool branches, how are you people doing this? Erich; I'm having two pathes buildtool and buildtool26 (well, I do have some more as testbeds for building older stuff as well, but doesn't matter here), whenever I change to the one, which the ld-uClibc loader doesn't point to, I'll be asked by buildtool.pl if I want to create a proper symlink, responding with Y and giving the root password is all I have to do. Arne and Martin did a pretty good job to make it as simple as possible for a poor man to run more than one build environment at a time. kp - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
On Fri, 07 Mar 2008 21:56:17 +0100 Martin Hejl [EMAIL PROTECTED] wrote: this is a little depressing. After spending years (and tons of emails) discussing the need for a kernel 2.6 version of LEAF, there has been no response on this list on the topic. Sorry, Martin, I only read the list as a newsgroup, every week or so. Maybe having a branch that supports 2.6 kernel isn't all that important after all, despite the fact that the topic has been coming up every now and then since 2005 (possibly earlier than that, but 2005 was the earliest I could find doing a quick search of the archives). It's important to me because LEAF still seems by far the simplest small, easily customizable distribution for running Shorewall; and the latest Shorewall-4 with the excellent shorewall-perl compiler handles IPsec only in the new kernel 2.6 style with nf-policy-match support. Without really understanding the leadership structure of the project I had assumed from a mailing list archive reading it was futile to work on a kernel 2.6 branch; you seem to have proved otherwise, so perhaps I will find the time to collaborate. Like Charles, I am facing the prospect of upgrading to a much larger and more complex distribution, although I have been more interested in Alpine Linux than an actual mounted-disk-filesystem Debian install. -- John Keith Hohm [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
Hi John, this is a little depressing. After spending years (and tons of emails) discussing the need for a kernel 2.6 version of LEAF, there has been no response on this list on the topic. Sorry, Martin, I only read the list as a newsgroup, every week or so. No problem. I just started to doubt the value of the time spent (and not mainly by me - Dirk and Eric put in as much, if not more, time as I have). It's not about ego (hence my line about not looking for a good job, well done response), it's simply about finding out if one is wasting one's time. I don't gain anything if people use the new branch (or Bering uClibc, or any other LEAF branch), so if I'm working on something that nobody is really interested in, I guess I'd better stop wasting my time and do something more productive. If there is interest, and people will use it (and some will contribute), it's much easier to justify the time spent. To me, that's really all it comes down to. It's important to me because LEAF still seems by far the simplest small, easily customizable distribution for running Shorewall; and the latest Shorewall-4 with the excellent shorewall-perl compiler handles IPsec only in the new kernel 2.6 style with nf-policy-match support. Well, there's an new issue, I guess. Somebody will have to build a perl.lrp package that provides everything shorewall-perl needs. I guess size isn't much of an issue (I doubt that anybody who knows what they're talking about is going to expect a 2.6 kernel, a useful set of tools plus perl to fit onto one floppy). But since I have no experience whatsoever with that part of shorewall (I got by just fine with the part of shorewall provided with Bering uClibc), I'm afraid somebody else will have to provide that set of tools. I can help with the buildtool stuff, so I'm sure it can be done as a collaborative effort - but I doubt I'll find the time or energy to provide that all by myself (that's mainly what the paragraph about focusing on the core features, on things that those who build the packages need themselves and can actually test themselves, was all about in my first email in this thread). Without really understanding the leadership structure of the project I don't think there's much of a leadership structure. Everybody is free to contribute, or to create a branch of their own if they want to do something different from what everybody else is doing. At least, that's the way I understood the evolutionary development model that Mike proposed - and I like the idea. It just didn't seem to really work too well in the past (since it seemed it always came down to a small group of people doing the development). But this _could_ change now, with a new branch that uses the (IHMO) solid base of Bering uClibc, uses the same build toolchain (so people who know how to build packages for Bering uClibc, can build packages for the new branch without having to re-learn anything). That was mainly the reason for my frustration - we provided a working image, the devel toolchain is the same as for the current stable release, so not getting any feeback was a bit disappointing. Maybe I sent the email too soon - but maybe the email served as a wakeup call as well, getting more people out of the let's see how that progresses mode (one that I often fall into myself...). I had assumed from a mailing list archive reading it was futile to work on a kernel 2.6 branch; you seem to have proved otherwise, so perhaps I will find the time to collaborate. Well, maybe that wasn't made very clear (or, more likely, it never really was clear to any of the participants of the discussion at the time - it's hard to say anything for sure before one has tried it. And then, the 2.6 kernel has changed over the last 2+ years, since the discussion first came up). To me, it always seemed impossible to continue to support floppies with kernel 2.6. That still holds true - at this point, it doesn't look like it's doable. I would still like to find a way to boot from floppy, but at this point, it doesn't look like it will happen. But using a 2.6 kernel booting from something with more storage is surely possible (obviously, by now), it just meant a considerable amount of work, and at the time the discussion first came up, it just didn't seem reasonable to spend that time, given the marginal benefit a 2.6 kernel would have meant. For me, the reason to start working on that was first of all, because I wanted to see if it could be done (to get past the gee, wouldn't it be nice if... stage), and maybe more importantly, because I have a few PC Engines ALIX boxes lying around here that I feel would benefit from a 2.6 kernel (if and how much they'll benefit from it remains to be seen - I've not had time to actually work on that part yet). I would be very happy to see LEAF to get a broader developer base, with people working on all kinds of things, rather than just waiting for the the core developers to provide something (I never liked
Re: [leaf-devel] Bering uClibc with Kernel 2.6
On Mon, Mar 10, 2008 at 4:58 PM, Martin Hejl [EMAIL PROTECTED] wrote: oops - sorry Hi Nicol, make that Hi David I wasn't trying to make any point; just sharing my experiences that (1) tinygentoo image was easy to work with for creating uclibc-linked this and that (2) with a 2.6 you can embed your whole file system into the kernel and boot and go just from the kernel -- no file system at all -- that way you don't have to pivot-root from the initrd -- just stay there. I'm sort of fishing for stories about why that might be a bad idea, beyond that 1: it varies from standard practice and 2: the initramfs is not backed by swap, as normal shmfs is (I guess I'm also sharing that the existing build environment had too high a learning barrier; that the gcc.lrp package did not appear to exist on the .iso; and that a build environment lrp might be a good idea; that altogether I found Bering to be organized well) Also you seem to have misconstrued my size matters to mean something different from what I intended. No harm, no foul. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
Hi David, (2) with a 2.6 you can embed your whole file system into the kernel and boot and go just from the kernel -- no file system at all -- that way you don't have to pivot-root from the initrd -- just stay there. That's not correct. Indeed you can make a choice to include the initramfs (not initrd) into the kernel, but it has no technical advantage besides having only a kernel instead of a kernel and an initramfs.cpio. The reason to have both options has to do with GPL and including non-GPLed modules. Besides it's easier to have a seperate kernel and initramfs if you want to support multiple boot devices and also keep size down. In both cases you have to do a switch_root (not pivot_root which was the case with kernel 2.4) to free the initramfs and start init. So you always have a file system, ramfs, even if you embed the whole system in the kernel and you have to do a switch_root to give init the control and do some other housekeeping. Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
Hi David, I'm sort of fishing for stories about why that might be a bad idea, beyond that 1: it varies from standard practice and 2: the initramfs is not backed by swap, as normal shmfs is Well, one downside of this approach is that you cannot control the size of the root-fs by a variable in leaf.cfg, as we can do now. Boxes that have a lot of packages loaded need a bigger root fs, old boxes with little RAM need a smaller one. It seems difficult to me to decide which root-fs size works for everybody. (I guess I'm also sharing that the existing build environment had too high a learning barrier; I guess it does - but I'm afraid the one's who have written it or have used it for several years are not the perfect candidates for writing easy to understand docs that explain things to people new to the build environment. It surely has its rough edges - but it does what it needs to do most of the time. that the gcc.lrp package did not appear to exist on the .iso; Yup, that's correct. and that a build environment lrp might be a good idea; I disagree - but if somebody builds a gcc.lrp, it can be put into the contrib area, and people can decide for themselves if they need it or not. Also you seem to have misconstrued my size matters to mean something different from what I intended. It appears that I have No harm, no foul. That's good. Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
Hi David, (2) with a 2.6 you can embed your whole file system into the kernel and boot and go just from the kernel -- no file system at all -- that way you don't have to pivot-root from the initrd -- just stay there. I'm sort of fishing for stories about why that might be a bad idea, beyond that 1: it varies from standard practice and 2: the initramfs is not backed by swap, as normal shmfs is An added note: Like Martin explained it has to do with system memory. It is theoretical possible to use the initramfs ramfs as root filesystem, but it has a big drawback. In the initramfs we create three dynamic tmpfs (a superset of ramfs) for root, tmp and log with an upper memory limit set, which can be defined in leaf.cfg. This means that, when correctly set, that growing files (like logfiles) can't crash the system if the total size is beyond the physical memory size of the system, because of the upper limit. This isn't possible with the simple initramfs fs. Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
On Fri, Mar 7, 2008 at 3:56 PM, Martin Hejl [EMAIL PROTECTED] wrote: Hi all, this is a little depressing. After spending years (and tons of emails) discussing the need for a kernel 2.6 version of LEAF, there has been no response on this list on the topic. Is somebody actually interested in continued work on that image (and has just not had an issue with it what I've posted last Saturday), or did I scare off people with my too verbose email, or is there just no interest, as long as somebody provides the drivers for the hardware people need? I had no trouble running the 3.1 release candidate with a static 2.6 kernel; also I found the tinygentoo embedded stage 3 environment to be useful for compiling things to run there. Size is an issue. But if you're booting isolinux instead of fd, you can cram all you want (like, the whole root.lrp and etc.lrp packages) into an initrd and just keep it as the root isntead of all that pivoting and remounting. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erich Titl wrote: | Actually playing with e1000 for 2.4 reset me a little lately. Definitely | I am convinced that if LEAF wants to go on strongly we need to be on par | with other project which do similar work, e.g. 2.6 is a must. | | And for all your effort which point into the future here it is _WELL DONE_ I agree! Besides driver issues, another reason to migrate to a 2.6 kernel is support for IPV6, which will become vastly more important in the years to come, particularly outside the US, where the IPV4 address pool is already beginning to be exhausted. | One of my concerns in the 2.6 branch will be IPSEC, as now we need to | use the native stack. It appears that with using the native stack IPSEC | will be an application like any other, so we may have now the benefit of | using Strongswan's IKEv2 implementation :-) I can likely assist with the IPSec stuff. I have migrated a few sites from leaf-based firewalls to minimal debian installs, using the new IPSec tools (racoon and racoon-tool, in my case). I have a few more sites that still run leaf and will need to be upgraded soon. A 2.6 kernel based release with modern IPSec would allow me to avoid migrating to debian (and rotating HDDs). I don't yet have any real-world experience with IPV6, other than the dropped IPV6 packets seen by anyone running a firewall...the nasties have taken to using IPV6 tunneling to try and circumvent firewall rules, as many routers block IPV4 traffic but have separate (and frequently non-existent or less maintained) rule sets for IPV6. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1VUXLywbqEHdNFwRAi/sAJ0d/ZHMKLXR+ryRRT9v4GhXUw5rDQCg/TsQ 0SuTICfWv3CevIn3uCF8qQQ= =jG9Q -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
Hi Nicol, thanks for your feedback, I had no trouble running the 3.1 release candidate with a static 2.6 kernel; Well, but doesn't a static kernel (I assume you mean that everything you needed was compiled into the kernel statically, rather than as a module) pretty much stand against everything that LEAF seems to stand for (which as far as I'm concerned, is being modular, making sure that people can use it to suit their needs, without having to set up their own build environment)? also I found the tinygentoo embedded stage 3 environment to be useful for compiling things to run there. Well, what's wrong with the build environment we already have (see http://leaf.sourceforge.net/doc/buc-buildtool.html )? If what's wrong with it is that it requires a separate box, and one cannot compile things on the box the packages are to be deployed on - that's by design, I'm not going to build a toolchain on an ElanSC520, which still is a very good box for most home users). Maybe it simply comes down to me not being a gentoo user, and not subscribing to the ideas that seem to be important for people who use that distribution (which is fine with me, as long as I'm allowed to have a different point of view). Size is an issue. But if you're booting isolinux instead of fd, you can cram all you want (like, the whole root.lrp and etc.lrp packages) into an initrd and just keep it as the root isntead of all that pivoting and remounting. I must be missing something. Last time I checked, isolinux was for booting from El Torito (i.e CD-ROM) images. If one is booting from CD-ROM, what difference does the extra size for a 2.6 kernel make? I guess a 2.6 kernel plus initrd should fit nicely onto a 2.88MB image, so booting off a CD is not going to be an issue. But I fail to see how a big monolithic initrd will help in any way, if one is already booting off a media that has plenty of space available. And I'm rather unsure how one would boot off a compact flash, using isolinux (and all the boxes I have to support boot off CF, and they have neither a floppy, nor a CD-ROM - so unless I misunderstood what isolinux could do, I fail to see how isolinux could help with booting an embedded box with LEAF. So far (to me) embedded with LEAF means boxes like the Soekris or PC-Engines boxes, possibly even the Nexcom boxes - even though they're not exactly embedded, being 19 inch rack mounts...). Maybe we're just using completely different hardware, which might explain the different focus (or maybe, I'm just missing your point - it wouldn't be the first time that I totally misunderstand something). But if I didn't totally misunderstand the point you're trying to make, I'll have to disagree - to me (even though my opinion only counts for the stuff that I do, and everybody else is free to hold a different opinion, and work on things I wouldn't be working on) LEAF is about creating a platform. The platform should serve as a decent and secure home/home-office firewall out of the box, but it shouldn't require too much work to turn it into something else. To me, that means the distro should be modular. To some (or so it appears to me) modularity seems to be a bad compromise, and optimization for the box that will be running the code is very important. To me, optimization is good, after one has identified a bottleneck. But optimizing just for the sake of optimization seems to be a waste of time to me. I guess those two schools of thought are not easily combined, so it sounds like a gentoo style branch might be called for, to suit the needs of some. If there are people willing to put in the work required, and those people are willing to share their results, I'm sure that will happen, and I'm also sure there will be users who will happily use that branch. After all, it seems very well in line with Mike's idea of an evolutionary development model, where different ideas compete with each other, and hopefully, the one that suits the user's needs best will prevail. Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
oops - sorry Hi Nicol, make that Hi David sorry about that Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
Hi Paul, thanks for your feedback With that experience, my question would be, what significant benefits does the 2.6 kernel provide to a minimalist system? For me, the main reason was new drivers. It appears that more and more things are only added to the 2.6 kernel, and not to the 2.4 line. Sooner or later, it will be difficult to get network adapters to work that haven't been around for ages. I'm still interested in a firewall I can run from a write-protected floppy, always have been. It seems the 2.6 kernel is larger, which is a disadvantage. In that case, the branch with 2.6 kernel will not be for you - I don't see a way to get a working image with 2.6 kernel onto a floppy (and even with a two floppy setup it still seems very tight, since one needs a kernel plus initrd on the first floppy). But sooner or later, floppy support will have to go anyway - since there won't be any new systems that are shipped with a floppy. For embedded systems, floppies have been dead for quite a while, and it seems that these days, even standard desktops no longer come with a floppy. Don't get me wrong - I didn't like having to admit that we had to drop floppy support (and if we find a way to continue floppies, we will - simply because it will give us the extra incentive to keep things small and avoid any kind of bloat). I haven't used real floppies with leaf boxes in ages (I _have_ used it in VMs, but simply because the floppy images where available and easy to boot from), and I haven't looked back. I don't miss the unreliability of floppies (especially superformatted floppies) one bit. Losing the ability to write protect the boot media is a bummer, but if that's absolutely needed, one can create a CD to boot from, and use that instead of floppies (granted, not as simple and convenient as moving the write-protect thingie in a floppy, but still, a usable alternative). But I'm not trying to convert you to moving away from floppies - if they work for you and you don't have any issues with that setup, by all means, stick with it, until your requirements change. I wouldn't argue that, for instance, the new locking dispatching aren't improvements, but do they remedy real problems for a LEAF implementation? Surely not, as far as I'm concerned. It seems one branch of hardware development is making small, motorless systems that would make nice LEAF applicances, so we might need support for them in new kernels. An example for that would be the ALIX box from PC-Engines. There doesn't appear to be a watchdog driver in either kernel version yet, but at least I've found a patch for kernel 2.6 It seems that Low power computing is getting popular with chip manufacturers these days, so I guess we'll see more and more single chip systems, that have a lot of the needed stuff on chip (like the AMD Geode LX800 with its random number generator, crypto support, watchdog). I doubt that support for these new systems will be added to the 2.4 kernel. Another thing I'm interested in with kernel 2.6 (once it matures) is the Open Source Atheros wifi driver. Again, I doubt that will make it into kernel 2.4. The 2.4 kernel brought us stateful packet inspection, and that was a very GOOD thing. I'm just unaware of a NEED for the 2.6 kernel at present. I don't think there is a NEED for 2.6 kernel in leaf right now. But there will be at some point (the point when modern hardware will hardly be supported anymore - just like with 2.2 Kernel today. I doubt you would be able to get any of the current Gigabit cards to work with a 2.2 kernel - but I must admit, I haven't tried it). So before things get too bad on the driver front, it seems smart to start working on something that will give us a perspective for the next 5+ years (just like Bering did with switching to kernel 2.4, when many people said that 2.2 could do all they needed, IPTables was too complicated and IPChains did just fine and so on). I guess in short, there is no dying need to switch to kernel 2.6 right now. There might be a few years from today. And if we only start working on that when there's a dying need, I'm afraid the project will be dead before we're finished (since either users will have moved away due to the lack of support for their hardware, or they'll have moved away since the quickly hacked together 2.6 version is not as stable as Bering/Bering uClibc). So, even though we don't desperately need 2.6 kernel right now, it would be a bad choice to (IMHO) to just sit there and be happy that all we need to do today can be done with kernel 2.4 Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
Hi Erich, And for all your effort which point into the future here it is _WELL DONE_ ;-) One of my concerns in the 2.6 branch will be IPSEC, as now we need to use the native stack. It appears that with using the native stack IPSEC will be an application like any other, so we may have now the benefit of using Strongswan's IKEv2 implementation :-) I'll take your word for it - I've only briefly played with IPSEC a long time ago, and I've been very happy that I could do everything I need with OpenVPN. Anyway, I need to probably get two buidltool branches, how are you people doing this? If you mean 2 build environments (one for Bering uClibc, one for whatever it's name will be), yes, I have two separate setups (happens automatically, since the two are stored separately in CVS). Not terribly nice if one is switching between the two (since one always has to remember to have /lib/ld-uClibc.so.0 point to the right buildenv, but other than that (and the extra space this needs), it's no big deal to me. Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
Hi all, this is a little depressing. After spending years (and tons of emails) discussing the need for a kernel 2.6 version of LEAF, there has been no response on this list on the topic. Is somebody actually interested in continued work on that image (and has just not had an issue with it what I've posted last Saturday), or did I scare off people with my too verbose email, or is there just no interest, as long as somebody provides the drivers for the hardware people need? I didn't expect a storm of activity - but I (perhaps foolishly) expected some sort of response. I'm not looking for a good job, well done response - but some sort of feedback that somebody is actually giving the latest developments a try would be helpful. Without any kind of feedback whatsoever, it's very hard to justify spending one's spare time on something nobody will use anyway. Maybe LEAF is a victim of the fact that it works so well, and as long as somebody helps getting the latest network drivers to work, all is well as far as the LEAF developers are concerned. By the way thank you Erich for spending your time on that, I truly appreciate your involvement in getting those drivers to work (and despite the fact that it may sound like it, I do not mean that cynically - I actually appreciate the work you've been doing). And by all means, I don't mean to discount the people who have contributed to the LEAF project in the recent past - I'm just a little surprised that there has been no response of any kind on this list about what seems to have been asked for so many times in the part. Maybe having a branch that supports 2.6 kernel isn't all that important after all, despite the fact that the topic has been coming up every now and then since 2005 (possibly earlier than that, but 2005 was the earliest I could find doing a quick search of the archives). Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
Hi Mike, I didn't expect a storm of activity - but I (perhaps foolishly) expected some sort of response. I'm not looking for a good job, well done response - but some sort of feedback that somebody is actually giving the latest developments a try would be helpful. Without any kind of feedback whatsoever, it's very hard to justify spending one's spare time on something nobody will use anyway. My comments on the new branch name were pending project name change, so I'll provide them now... Since LEAF is now a Framework, how about using wood types for branches? Douglas Fir - a bare bones frame Rosewood - polished but not necessarily robust Ceder - infection resistant etc. My comment on the lack of response was not really geared towards the naming issue. Sure, if we find a catchy name, that's great - but if nobody uses it, and nobody contributes, what difference does it make? To me, Open Source projects have always been about different people from all walks of life and all kinds of backgrounds contributing to the project. I don't see that with LEAF at the moment (and I'm not discounting the people who have contributed in the past, and continue to contribute - but if a project has to rely on a handful of people, what happens when a few of those people decides he/she doesn't have the spare time anymore?) Some of this is likely my fault. Since my accident, I haven't devoted as much time to LEAF as I did in the past. :-( Maybe - but most likely not. You not being able to put in as many hours as you did in the past has nothing to do with the fact that this project never had a broad developer base. As long as I remember (and I've been been around for a while), it's always been about individuals making the difference. Dave in the beginning, then Matthew with Matterhorn and Eiger (I also remember something called Kilimanjaro - but I don't remember who created that), if I recall correctly, then Charles with Eigerstein and Dachstein, then Jaques and Erik with Bering, then Eric, kp and Luis with Bering uClibc (forgive me if I remembered something incorrectly or if I forgot somebody - I'm going by memory here, so there will undoubtedly be inaccuracies). I guess the back in the days of Koon Wong's package archive, and Rick's c0wz site, we had what might me called a broad community - but looking back, even that was mainly driven by a few individuals. I'm not sure what I'm trying to say - maybe that unless we manage to build up more manpower, we'll always run into trouble when one of the core developers decides it's time to move on and do something else (and IMHO, there's nothing wrong with people seeking new challenges or just getting bored with doing the same thing all the time - most of us have to do tedious work during our days work, so I don't blame anybody for not being willing to do the same kind of work for an extended period of time in their spare time as well). I hope to update our website in the next couple of months. Maybe that will help invigorate community participation. Maybe it will - but I doubt that the people who are mostly attracted by a shiny webpage are what the project needs right now. Keeping the webpage up to date is a worthy goal - but I don't think that the lack of a re-furbished webpage is holding the project back (getting the LEAF documentation set to build as a PDF again might help - but honestly, I doubt it would make a difference with the issues we're (or maybe mainly I am) discussing). It's not about lack of visibility or lack of documentation - to me, it's about lack of participation, and people tending to consume and expect their needs met, rather than actively contributing. And again, by no means do I mean to discount all the people who have (including you) actively contributed in all kinds of ways. It just seems to me there are not enough people like that to keep things going. Or maybe it's just one of those Fridays, and I'm too pessimistic. Martin -- You think that's tough? Try herding cats! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Bering uClibc with Kernel 2.6
Hi everybody, for the last few weeks, Dirk Gfroerer, Eric Spakman and myself have been working on getting kernel 2.6 to work with Bering-uClibc. By now, we have things working enough that we feel it's fit to be shown to the other leaf developers out there. It is by no means ready, probably not even functional at this point, but we have a kernel, an initrd and a quemu image that boots. I've checked all the changes into CVS - to check it out from CVS, do the following: leaf project members: export CVS_RSH=ssh cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf \ co src/The_UnNamed_One everybody else: cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot/leaf login cvs -z3 -d :pserver:[EMAIL PROTECTED]:/cvsroot/leaf \ co src/The_UnNamed_One Things to do first after checkout: in src/bering-uclibc/buildtool/make/MasterInclude.mk : HOSTCC should pointing to a gcc 3.x compiler. The buildenv will not build with gcc 4.0 Building the buildenv and packages is the same as for Bering uclibc. It has been tested on RHEL 3/4 and CentOS 4 If you want to test it, you can find a qemu image plus kernel and initrd at: http://sourceforge.net/project/showfiles.php?group_id=13751package_id=265425 To run this image in qemu, download and extract the tarball (it contains the image, kernel and initrd) and then start quemu like this: qemu -hda root.img --initrd initrd.lrp --kernel linux \ --append init= rw LEAFCFG=/dev/hda1:msdos (for some reason, qemu hangs when started just with qemu -hda hd.img after loading the kernel and initrd) To access the contents of the image, follow these steps: # /sbin/fdisk -lu root.img This should produce output similar to this: You must set cylinders. You can do this from the extra functions menu. Disk hd.img: 0 MB, 0 bytes 8 heads, 32 sectors/track, 0 cylinders, total 0 sectors Units = sectors of 1 * 512 = 512 bytes ---^ Device Boot Start End Blocks Id System hd.img1 * 32 125439 62704b W95 FAT32 ^ the underlined numbers are relevant if you want to mount the image (since it's an image of a whole HD, not just of a partition) So, to mount, you then do: # mount -o loop,offset=$(( 32 * 512 )) hd.img /mnt/loop (replace 32 and 512 with the corresponding numbers from /sbin/fdisk -lu root.img , should they be different on your system). About the changes we made: * kernel 2.6.24.2 * initrd is now using initramfs * udev (busybox calls it mdev) support * updated versions of busybox, iptables, iproute2 Where to go from here: This obviously still needs a lot of work, and even more testing. We'll be happy to receive feedback here on leaf-devel about things that work and don't work, but please refrain from asking us to build package XY, add support for modules currently unsupported or something like that at this point. Currently, the focus is on getting the base image working - everything else will come at a later point. Due to things we have learned from the 2.x and 3.x releases of Bering uClibc, we are going to significantly cut down the number of packages maintained by the core Bering uClibc team. Packages can be added, provided that somebody is willing to be the maintainer of that package. The reason for this is that it has become almost impossible for a handful of people to maintain the 158 packages we are currently offering for Bering uClibc 3.x (some of which we can't even test, since we don't have the hardware or the software setup to test them). In the end, this will mean that the contrib section will probably become quite a bit bigger, while the number of core packages will be smaller. And hopefully, it will also mean that number of developers increases at least a bit, so the workload gets spread out a bit more than in the past. We're still looking for a name for this branch (we don't really want to call it Bering uClibc 4.0 - with dropping floppy support, and changing how the packages are maintained, it's probably better give it a new name) - so if you have ideas, we're be happy to hear them. We've been looking for something short (not a mouthful), somewhat relating to Bering (as in straits, canals, dams or something like that) But in the end, if it sounds good, and doesn't cause cultural problems (many names that sound great in German just don't work for an international community), I guess we can agree on that. Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
