I did start off trying to compile the 188.8.131.52 kernel, however the lzma patch and one of Lloyd's Multitech patches failed. As dogone said, the temptation is to put one's hand into the lolly jar, but in this case I got stopped right at the start. I then decided to back off from the bleeding edge.
This kernel has the patches as before: loglevel, squashfs, unionfs, aufs, lzma and multitech-gprs (in total, 10 patches).
All source files uploaded to Ted Dog's repo:
I have not yet compiled the SCSI and IDE kernels. I first want to bring out 4.1alpha6 and make sure that the kernel is basically ok, then I will compile the other variants. Temptestuous also will have to recompile the extra modules that he created for the 184.108.40.206 kernel -- thanks for your patience on that, tempestuous.
Comments:Posted on 11 Aug 2008, 21:33 by tempestuous
Yeah, it's quite straightforward to compile those drivers again for 220.127.116.11.
I presume you may want to include at least some of those drivers in the 4.1 final release? The only ones I would recommend against are the ones which compete with, or overwrite, drivers already in Puppy.
I can provide the links to the various driver sources, or maybe just upload the sources myself - either to putrix or cb88's Sourceforge repository?
Regarding the 2.6.26 kernel; it's not unrealistic to predict that at least half of the new third-party modules under discussion here would fail to compile against this new kernel.
Posted on 11 Aug 2008, 21:51 by BarryK
do you have ftp access to puptrix.org? if so, upload them direct to there would probably be best.
Just upload whatever you think should be added to what I have already compiled, as you say, ones that won't clash. It's no problem for then, I can download them, compile and include them with the others.
Posted on 11 Aug 2008, 22:35 by Raffy
upload to sf
Uploading sources to sf.net will be OK - it is really intended for this purpose.
A kernel build for UMPCs will be good - they are becoming a large niche of single-processor mobile PCs.
Posted on 12 Aug 2008, 23:43 by tempestuous
new driver sources
Barry I haven't had a reply from Ted Dog about access to puptrix, and I find the Sourceforge repository confusing. So I have uploaded the new driver sources to Raffy's site as one large tarball.
Maybe you can copy this over to puptrix.
Raffy, later I will clean out some of the redundant stuff at your site.
I created a text file with notes about each source package. Of particular importance:
- The RT2860 and RT2870 sources need a configuration file modified to enable WPA support with the "wext" -D parameter in wpa_supplicant. This is important, as complaints on the forum are bound to result otherwise.
- Still on the subject of WPA support; wag-profiles.sh needs to be updated to accommodate the new wifi drivers. Specifically, the following modules need to be defined at line 134 as compatible with the "wext" parameter:
- The 4 new wifi drivers and 2 new ethernet drivers will need to be added to /etc/networkmodules.
Posted on 13 Aug 2008, 7:15 by BarryK
thanks, I'm uploading them to puptrix right now.
I'll have a go at compiling them very soon.
As Raffy has requested, I also want to go through the entire kernel and modules compiling exercise again, with a "conservative" build.
One thing that surprised me, I downloaded about half a dozen '.config' files for the 2.6.24/25 kernel, all configured for SMP, to get some ideas what other distros are choosing, but none of them had "tickless" enabled. That surprised me -- is there some problem with tickless? Anyway, I decided why not do a "conservative" kernel with all older settings -- tickless disabled, uniprocessor, old IDE drivers ...and anything else we can think of. I will have to go through the exercise of recompiling all the 3rd party drivers. Then put this into Unleashed as an alternative choice.
If anyone has a thought about something else to enable/disable in the conservative kernel, let me know. I'll probably do it tonight, about 10 hours from now.
Posted on 13 Aug 2008, 17:13 by tempestuous
Yes, tickless is usually considered somewhat cutting-edge. I seem to recall that it's a prerequisite setting for a preemptive kernel.
I had always thought of Puppy's kernel as being neither conservative, nor cutting-edge, but "moderate". Now that we have discovered the "nosmp" trick, I'm surprised that a separate conservative kernel is
necessary. Can low-tech PC's not work OK just by booting with "nosmp"? My 10 year old Pentium2-350 is perfectly happy with the 18.104.22.168 kernel without any special boot options.
And if there is to be a separate conservative kernel, it raises the question about whether the non-conservative kernel might become freed up to move more towards true cutting-edge? By "cutting-edge" I
mean SMP + HyperThreading + Multicore + tickless + high timer frequency + full pre-emption.
Posted on 14 Aug 2008, 7:51 by dogone
I think the dual Puppy release idea is a good one in general. It provides for those who want/need a less "risky" release or one for cranky hardware while allowing those who wish to, to push the envelope. A "conservative" co-release also takes pressure off of Barry, permitting him to experiment with new ideas and newer technology without risk of loosing the ship.
I don't think we want anything to hold Barry and friends back. I say, adopt the dual release strategy and give our leader some leash! Given the freedom, Puppy will ultimately grow faster and stronger.