Driver for DPT/Adaptec I20 SCSI RAID adapters (DPT SmartRAID V/VI, Adaptec 2100S/3x00S)
ReiserFS knfsd patch for 2.4.4
ReiserFS quota patch for 2.4.3 (that's right, 2.4.3. I had to hammer that patch in manually; that's what I want tested the most)
Instructions for patching:
Have a plain-vanilla 2.4.4 tree ready. Anything but plain vanilla may work, it may not.
Switch to the directory for this tree and do "zcat <path-to-patch.gz> | patch -p1" (for the .gz file) or "bzcat <path-to-patch.bz2> | patch -p1" (for the .bz2 file). Check for "FAILED" messages, they are bad (obviously).
If you use a separate kgcc compiler (i.e. RedHat 7.x), modify the top-level Makefile accordingly. I can post details on how to do this if you need help; it's a one-line change.
Compile the kernel to your taste. In particular, I want to test out knfsd and quotas on ReiserFS, so enable that stuff.
Boot off the kernel, cross your fingers, and say a little prayer...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You may also want to send this to the people at kernel.org; just a thought. :) Also, we need to follow the LSB. We also really need to decide what we want to put into this distro. Oh, and before I forget...I'll be posting some answers I got to the question I put out about the distro.
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Both are still made to patch against a plain-vanilla 2.4.4 source tree.
What's new in this patch:
Slight tweak to the aicasm Makefile, to get it to compile properly against my current Berkeley DB configuration. You may need it, you may not.
Btw, can anyone dig up proposed or ratified standards on the configuration of the Berkeley DB headers? I checked http://www.linuxbase.org/ and came up with a big heap of nothing. As near as I can tell, software expects the db_185.h header to be /usr/include/db1/db.h, but that's about all I can figure out atm.
Oh, and the people at sleepycat.org have earned my undying wrath. At this point, it would be very tempting to hunt down the founder of that project and staple his testicles to my desk as a trophy. Thanks for listening. ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I might, I don't know. It depends on how much I can do to it in the way of patching. I was barely able to get all the patches hammered on to 2.4.4--reiserfs patches in particular had to be applied manually. I would have included xfs support as well, but the xfs code proves to be beyond my abilities to hammer in manually.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any changes to the kernel -- even patching -- should be sent back to the people at kernel.org; also...we are as I stated using the 2.4.* kernels for Maximum Linux, though we will go slower with the 2.4.* updates to the kernel.
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've posted patches for a heavily modded 2.4.4 kernel at http://kelledin.tripod.com/maxlinux/linux-2.4.4-1.patch.bz2 and http://kelledin.tripod.com/maxlinux/linux-2.4.4-1.patch.gz At this point, I need people to start testing it. Be warned that with the mods I've made to it, it may very well chew up your filesystem and spit it out.
What's new in this kernel:
Driver for DPT/Adaptec I20 SCSI RAID adapters (DPT SmartRAID V/VI, Adaptec 2100S/3x00S)
ReiserFS knfsd patch for 2.4.4
ReiserFS quota patch for 2.4.3 (that's right, 2.4.3. I had to hammer that patch in manually; that's what I want tested the most)
Instructions for patching:
Have a plain-vanilla 2.4.4 tree ready. Anything but plain vanilla may work, it may not.
Switch to the directory for this tree and do "zcat <path-to-patch.gz> | patch -p1" (for the .gz file) or "bzcat <path-to-patch.bz2> | patch -p1" (for the .bz2 file). Check for "FAILED" messages, they are bad (obviously).
If you use a separate kgcc compiler (i.e. RedHat 7.x), modify the top-level Makefile accordingly. I can post details on how to do this if you need help; it's a one-line change.
Compile the kernel to your taste. In particular, I want to test out knfsd and quotas on ReiserFS, so enable that stuff.
Boot off the kernel, cross your fingers, and say a little prayer...
You may also want to send this to the people at kernel.org; just a thought. :) Also, we need to follow the LSB. We also really need to decide what we want to put into this distro. Oh, and before I forget...I'll be posting some answers I got to the question I put out about the distro.
Michael
Well, there's already a new patch out. Check http://kelledin.tripod.com/maxlinux/linux-2.4.4-2.patch.bz2 or http://kelledin.tripod.com/maxlinux-2.4.4-2.patch.gz
Both are still made to patch against a plain-vanilla 2.4.4 source tree.
What's new in this patch:
Slight tweak to the aicasm Makefile, to get it to compile properly against my current Berkeley DB configuration. You may need it, you may not.
Btw, can anyone dig up proposed or ratified standards on the configuration of the Berkeley DB headers? I checked http://www.linuxbase.org/ and came up with a big heap of nothing. As near as I can tell, software expects the db_185.h header to be /usr/include/db1/db.h, but that's about all I can figure out atm.
Oh, and the people at sleepycat.org have earned my undying wrath. At this point, it would be very tempting to hunt down the founder of that project and staple his testicles to my desk as a trophy. Thanks for listening. ;)
Whoops, that's sleepycat.com. No big deal, unless someone already took it upon themselves to destroy sleepycat.org to avenge my lost sleep.
Do you plan to include version 2.4.5 in the upcoming release?
I might, I don't know. It depends on how much I can do to it in the way of patching. I was barely able to get all the patches hammered on to 2.4.4--reiserfs patches in particular had to be applied manually. I would have included xfs support as well, but the xfs code proves to be beyond my abilities to hammer in manually.
Any changes to the kernel -- even patching -- should be sent back to the people at kernel.org; also...we are as I stated using the 2.4.* kernels for Maximum Linux, though we will go slower with the 2.4.* updates to the kernel.
Michael
Cool, I can do that. As a thought, we should probably also send it to kernelhq.org; they keep a lot of "unofficial" patches there.
Any particular address it should be sent to, or should I just post it to the kernel mailing list?
D'oh--that should be linuxhq.com. (Come on, Kell, wake up!)
GRRRrrrrr!!! I have new kernel patches (for 2.4.5) and cannot upload them to tripod =( Apparently tripod can't upload anything so large!
Anyone know how we can get stuff onto SourceForge's FTP space?
Oh, and the changes this patch makes to the the stock kernel:
XFS support
ReiserFS fixed-umount + quota + knfsd support
DPT/Adaptec I2O SCSI RAID driver
Most of these you've already seen before. The nice thing is, I didn't have to shoe-horn anything! All patches went in fine with only a little fuzz.