![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to DIFFS.TXT CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GPL Stacker compression] / dmsdos / patches|
Return to DIFFS.TXT CVS log | Up to [GPL Stacker compression] / dmsdos / patches |
1.1 root 1:
2: The list of CVF-FAT diffs is actually some lines below.
3:
4: Some notes about applying patches
5: ---------------------------------
6:
7: This section is for people not familiar with kernel patches. Feel free to
8: skip it if you are an experienced patch hacker :)
9:
10: Well, as always be careful with diffs. Nobody knows whether they always
11: apply correctly. Praise yourself lucky if you see errors on the screen -
12: then at least you know that the patch failed. :)
13:
14: However, I've seen patches applying without errors, but changing code at
15: the wrong place, even creating syntactically correct but senseless
16: and not well working code. (For example, this happens for a small part of
17: the patches if you use the plain 2.0.33 diff here for a fat32 patched
18: 2.0.33 kernel or a 2.1.76 kernel. Argh. It's almost impossible to find
19: and repair such an error if you haven't written the code yourself.)
20:
21: From the patch manual:
22:
23: Patch usually produces the correct results, even when it
24: has to do a lot of guessing. However, the results are
25: guaranteed to be correct only when the patch is applied to
26: exactly the same version of the file that the patch was
27: generated from.
28:
29: So do at least the usual security steps. It's best to get a fresh kernel
30: from the net (*not* upgrading by patches). But sometimes you need patches.
31: Ensure:
32:
33: A. Before applying a patch:
34:
35: 1. Copy your complete kernel sources to another place, and operate
36: only on this test copy, e.g.
37:
38: cp -a /usr/src/linux-x.y.z /usr/src/linux-x.y.z-test
39: cd /usr/src/linux-x.y.z-test
40:
41: 2. Remove all patch related files in the kernel sources, e.g.
42:
43: find . -name "*.orig" -exec rm {} \;
44: find . -name "*.rej" -exec rm {} \;
45:
46: B. Apply the patches you need. Order is important.
47:
48: 1. Look at the first lines of the diff. There's very likely a complete
49: path in the filenames. If it begins with "linux..." you need the
50: option -p1, if it begins with "/usr/src/linux..." you need -p4 or
51: -p0 (you'll see). If the option is wrong or the number behind -p is
52: wrong, patch will display a prompt like "file to patch?" and wait
53: for your answer, which should be CTRL-C in that case :-). Okay:
54:
55: patch -p1 < your-favorite-diff
56:
57: 2. After applying each patch, watch for reject files, e.g.
58:
59: find . -name "*.rej" -print
60:
61: If there are any, then the patch failed. You must repair it manually
62: now or you can give up completely. If you dare to repair it, take
63: a look at the *.rej files and try to find out what should have been
64: changed in the sources but couldn't be changed for some reasons.
65:
66: Just note, you *cannot* continue if any "*.rej" file is present and
67: the problem is not fixed manually. You will have messed up kernel
68: sources that won't work or won't even compile.
69:
70: 3. After applying the patch and eventually fixing problems manually
71: remove all patch related files in the kernel sources, e.g.
72:
73: find . -name "*.orig" -exec rm {} \;
74: find . -name "*.rej" -exec rm {} \;
75:
76: 4. Then apply the next patch (if you need), and so on.
77:
78: C. Recompile the kernel from scratch. Don't install it yet. Watch for
79: errors and warnings that were not present before:
80:
81: make mrproper (this is not always needed, but if problems arise
82: without it, try again starting here)
83: make config (this is also not always needed)
84: make dep
85: make clean
86: make zImage
87: make modules
88:
89: Okay, if everything succeeded, you might want to give it a try.
90: It's best to use a boot disk for the first test ('make zdisk'), but
91: if your configuration is highly modular this won't be enough,
92: so you might not have another choice than doing 'make zlilo' and
93: 'make modules_install'.
94:
95: Be sure to have a rescue boot and root floppy (a simple boot disk is
96: not always sufficient). I know most people are lazy and ignore this
97: until "it" happens. I've been lazy too :-) Also be sure to have
98: your old kernel and your old modules handy (if you only operated on
99: your test copy of the kernel, as I recommended above, you have them
100: still somewhere in the original source tree).
101:
102:
103: Good luck and happy hacking. :)
104:
105:
106: ----------------------------------------------------------------------------
107:
108: List of CVF-FAT related diffs
109: -----------------------------
110:
111: cvf.diff-2.0.33
112:
113: This is a diff was generated against a cyrix-patched 2.0.33 kernel (I need
114: cyrix support, so don't ask me to leave it out). This shouldn't matter as
115: the cyrix patches don't affect filesystem code. So just don't wonder why
116: the paths in that patch include the name 'cyrix-patched'. Of course, the
117: diff does not contain the cyrix patches itself :)
118:
119: This diff has been tested thoroughly and found to work with a plain 2.0.33
120: kernel.
121:
122: If you are using the uvfat patches, uvfat will not work correctly on CVFs
123: (it cannot since some wrappers must be patched in). You must additionally
124: apply the cvf-uvfat.diff-2.0.33 patch.
125:
126: This patch does not work for fat32 support. Try the next one instead :)
127: This patch also fails for Linux 2.0.34 and newer. Try the next one in this
128: case.
129:
130: cvf.diff-2.0.33+fat32-0.2.8
131: cvf.diff-2.0.34 (link to same file)
132:
133: This diff was generated against a cyrix-patched and fat32-patched 2.0.33
134: kernel. It works also with a 2.0.33 kernel that is only fat32-patched.
135: The fat32 version used is 0.2.8.
136:
137: Please don't misunderstand. This diff does *not* include fat32 support
138: itself. It only works against a kernel that has already been patched for
139: fat32 support.
140:
141: This patch has also been tested against the new 2.0.34, 2.0.35 and 2.0.36
142: kernels and found to work without problems :)
143:
144: cvf-uvfat.diff-2.0.33
145:
146: This diff changes the uvfat filesystem so it works properly on CVFs.
147: Changes are minimal. This diff does not contain the uvfat patches itself.
148:
149: What uvfat is? Look:
150: uvfat : umsdos == vfat : msdos
151: Search the net for more information. There's a uvfat homepage:
152: http://lab1.psy.univie.ac.at/~michael/uvfat.html
153:
154: This diff must be applied *after* the uvfat patch and *after* the
155: cvf.diff-2.0.33 patch (or cvf.diff-2.0.33+fat32-0.2.8 - depending on what
156: you need). Note that the uvfat patches caused a reject file when I tried
157: (fs/Makefile.rej), so be sure to check. The problem was because there was
158: autofs added in Linux 2.0.31, and plain uvfat is against kernel 2.0.28.
159: Just add the text uvfat to the list in Makefile, and it works. As far as
160: I know, there's no uvfat update for newer (2.1.xx with xx>80) kernels.
161:
162: Okay, step by step, this is what I have done, and it worked for me:
163:
164: 1. Get linux 2.0.33 sources and unpack.
165: 2. Patch in linux-2.0.28-uvfat-0.1.diff.
166: 3. Repair the rejected file fs/Makefile.
167: 4. Patch in cvf.diff-2.0.33.
168: 5. Patch in this patch.
169:
170: kerneld-autoload.diff
171:
172: This diff has been removed because it is obsolete. Use the updated cvf.c
173: files instead (see file cvf.c.README).
174:
175: in-kernel-2.0.35.diff
176:
177: This diff can be used to compile dmsdos as a fix part of the kernel.
178: It hangs dmsdos into some of the kernel initialization files. If you want
179: to compile dmsdos as a fix part of the kernel, apply this patch, then
180: create a directory linux/fs/dmsdos, copy the dmsdos sources from src into
181: that directory, replace the Makefile with 'Makefile.kernel', and create a
182: link 'dmsdos-config.h' pointing to the generic kernel config include file
183: 'linux/include/linux/config.h' If you want a working help subsystem just
184: append the dmsdos Configure.help file to that one in the kernel. All of
185: that should be done automatically by the script 'in-kernel.sh' so just take
186: a look at it for details :) The script additionally avoids copying
187: unnecessary files.
188:
189: NOTE: This patch may not work for kernels other than 2.0.35. But changes
190: are small and easy to understand. I expect that patching the fs/Makefile
191: fails just in the same way as it fails for the UVFAT patches :) Fix that
192: by manually adding the word 'dmsdos' to the subdirectory list in that
193: file.
194:
195: msdos-rmdir-bugfix.diff
196:
197: This is indeed an excerpt from Alan Cox' pre-2.0.36 patches. It fixes
198: the msdos rmdir bug that can cause filesystem corruption in a msdos
199: filesystem (and therefore also in a compressed msdos filesystem).
200: Affected kernels are 2.0.34 and 2.0.35 and all earlier kernels that have
201: been patched for FAT32 support version 0.2.8. The bug is fixed in 2.0.36.
202:
203: The diff just adds two missing braces to the msdos fs source code ...
204:
205: I do not know whether 2.1.xx kernels are affected too. Maybe you take a
206: look at what where the diff adds the two missing braces and verify that
207: they are there in your kernel sources :)
208:
209: In 2.2.x kernels this bug is not present.
210:
211: fat-truncate-bugfix.diff
212:
213: There's a design flaw somewhere in the kernel or in the FAT driver (I
214: really cannot say where) that can write to a disk though the device is
215: mounted read-only. It is triggered at least by damaged directory entries
216: on a FAT partition. Such damaged directory entries are a rare condition,
217: but the dmsdos driver may leave them around when finding another problem
218: and setting the filesystem to read-only mode. This bug can destroy any
219: FAT based filesystem that has damaged directory entries.
220:
221: The bug is at least present in kernels up to 2.0.36 from the 2.0 series
222: and in all kernels in the 2.1 series. Also it is in 2.2.x up to 2.2.2. For
223: newer kernels I don't know. As always with bugfixes: take a look at the
224: diff and the kernel sources ... :)
225:
226: This bug has not yet been fixed in official kernels (kernel 2.2.2).
227:
228: vfat-brelse-bugfix.diff
229:
230: There is a serious bug in the vfat driver (calls to brelse instead of
231: fat_brelse) that makes the system corrupt internal filesystem buffer
232: lists. (The bug bypasses the CVF-FAT interface and also causes problems
233: with filesystems that use a non-512 byte sector size [very rare condition
234: today].) It has only been reported to affect 2.2.x kernels, but late 2.1.x
235: kernels may have this bug too. Check the source code. As of kernel 2.2.2,
236: it has not yet been fixed in official kernels.
237:
238: The bug is not present in 2.0.x kernels.
239:
240: linux-2.2.13-dmsdos.patch-1
241:
242: Simple fix to fat_add_cluster1 to return non-NULL pointer to
243: first buffer-head of newly allocated cluster.
244:
245: linux-2.3.30-pre6-dmsdos.patch-1
246:
247: Many changes needed to enable basic DMSDOS functionality
248: without MMAP support for 2.3.30-pre6
249: It contains
250: - simple fix to fat_extend_dir to return non-NULL
251: pointer to first buffer-head of newly allocated cluster
252: - fixes to fat read super - cvf_format must be set before
253: cvf_mount is called.
254: - cvf struct type fixes
255:
256:
257: --------------------------------------------------------------------------
258:
259: Well, are there other useful extensions for the fat based filesystems
260: that should be checked whether they work with CVF-FAT ? Just let me know.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.