--1421910094-445988011-934063993=:24414
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.10.9908072314541.24414@ps.cus.umist.ac.uk>
Hi Peter.
I've now analysed the code, and the enclosed patch does a large part
of what is necessary for the kernel loaders to support kernels over
1023k in size, but it doesn't do all of it. I'd like your comments on
the patch so far, and also on what's left to do.
First, whilst the patch to build.c that you suggested will allow the
kernel to compile ok with `make bzImage`, the resulting kernel will be
unstable and most probably will not work at all.
The reason for this is that the current kernel loader uses the value
of a 16-bit unsigned int in the boot sector as the number of 16-byte
paragraphs of kernel source to load, thus only supporting kernels of
not more than 0xFFFF0 (1,048,560) bytes in size. Worse still, the
value stored in this word is the lower 16 bits of the calculated
value, so if the kernel was, say, 0x107630 (1,078,832) bytes ( in
size, the stored value would be 0x00763 paragraphs, or about 30k !!!
The first hunk of the enclosed patch defines a new 32-bit size field
using four of the previously unused bytes in the boot sector, and
defines this to store the actual kernel size, still measured in 16
byte paragraphs. This field can therefore handle kernels up to 64
Terabytes in size, and it should be a few days before we can produce
kernels that big 8-)))
The second hunk implements all the tweaks to build.c that are needed
for it to correctly fill in this field. As defined, it will record the
correct value in the old field for kernels that are small enough, and
will record 65,535 paragraphs in the old field for kernels that are
too large to be recorded therein.
Note that it IS safe to apply these two hunks to the current kernel,
as the ONLY result will be to actually define the extra field as
mentioned above, and to fill it in when compiling. The resulting
patched kernel will not actually use that field, and the current
1,023k limit will still apply.
The work still to be done is to the actual assembly code in the helper
routine in setup.S along with a small tweak to the code in bootsect.S
but I haven't yet had time to work that part of it out, and I would
definately appreciate your comments thereon. Here's my thoughts,
assuming the above patches have been applied:
1. I would start by applying the following patch to bootsect.S:
Q> @@ -273,8 +273,8 @@
Q> #else
Q> mov ax,es
Q> sub ax,#SYSSEG
Q> -#endif
Q> cmp ax,syssize ! have we loaded all yet?
Q> +#endif
Q> jbe ok1_read
Q> ret
Q> ok1_read:
This has the effect of changing the return value of the helper
function in setup.S such that instead of returning the amount
transferred in AX, it returns with the flags set according to
the results of the relevant comparison, and lets the helper
routine decide exactly how to do the comparison with the actual
kernel size.
To ensure that the rest of the outside routine still works, it
will return with AX holding the smaller of the total number of
paragraphs to go and 65535, ie, it will only hold a value smaller
than 65535 when there are less than 65535 paragraphs still to go.
2. Once this change is finished, the kernel will make absolutely no
use of the old size field, but will depend entirely on the new
size field. This will prevent any problems that might be caused
by code that tweaks the old size field for any reason.
Comments?
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
--1421910094-445988011-934063993=:24414
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="big-bz.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9908072313130.24414@ps.cus.umist.ac.uk>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="big-bz.diff"
LS0tIGxpbnV4LTIuMi4xMC9hcmNoL2kzODYvYm9vdC9ib290c2VjdC5TfglX
ZWQgSnVuIDI0IDIyOjMwOjA4IDE5OTgNCisrKyBsaW51eC0yLjIuMTAvYXJj
aC9pMzg2L2Jvb3QvYm9vdHNlY3QuUwlTYXQgQXVnICA3IDIyOjMyOjAwIDE5
OTkNCkBAIC00NDQsOSArNDQ0LDEyIEBADQogbXNnMToNCiAJLmJ5dGUgMTMs
MTANCiAJLmFzY2lpICJMb2FkaW5nIg0KIA0KLS5vcmcgNDk3DQorLm9yZyA0
OTMNCitrZXJuZWxfc2l6ZToNCisJLndvcmQgMA0KKwkud29yZCAwDQogc2V0
dXBfc2VjdHM6DQogCS5ieXRlIFNFVFVQU0VDUw0KIHJvb3RfZmxhZ3M6DQog
CS53b3JkIENPTkZJR19ST09UX1JET05MWQ0KLS0tIGxpbnV4LTIuMi4xMC9h
cmNoL2kzODYvYm9vdC9idWlsZC5jfglTdW4gT2N0IDI1IDIyOjE2OjIxIDE5
OTgNCisrKyBsaW51eC0yLjIuMTAvYXJjaC9pMzg2L2Jvb3QvYnVpbGQuYwlT
YXQgQXVnICA3IDIyOjM1OjU1IDE5OTkNCkBAIC0xNjgsNyArMTY4LDcgQEAN
CiAJc3ogPSBzYi5zdF9zaXplOw0KIAlmcHJpbnRmIChzdGRlcnIsICJTeXN0
ZW0gaXMgJWQga0JcbiIsIHN6LzEwMjQpOw0KIAlzeXNfc2l6ZSA9IChzeiAr
IDE1KSAvIDE2Ow0KLQlpZiAoc3lzX3NpemUgPiAoaXNfYmlnX2tlcm5lbCA/
IDB4ZmZmZiA6IERFRl9TWVNTSVpFKSkNCisJaWYgKHN5c19zaXplID4gKGlz
X2JpZ19rZXJuZWwgPyAweGVmZmZmMCA6IERFRl9TWVNTSVpFKSkNCiAJCWRp
ZSgiU3lzdGVtIGlzIHRvbyBiaWcuIFRyeSB1c2luZyAlc21vZHVsZXMuIiwN
CiAJCQlpc19iaWdfa2VybmVsID8gIiIgOiAiYnpJbWFnZSBvciAiKTsNCiAJ
d2hpbGUgKHN6ID4gMCkgew0KQEAgLTE4NywxNyArMTg3LDI1IEBADQogCX0N
CiAJY2xvc2UoZmQpOw0KIA0KKwkvKiBXcml0ZSBzaXplcyB0byB0aGUgYm9v
dCBzZWN0b3IgKi8NCisNCi0JaWYgKGxzZWVrKDEsIDQ5NywgU0VFS19TRVQp
ICE9IDQ5NykJCSAgICAvKiBXcml0ZSBzaXplcyB0byB0aGUgYm9vdCBzZWN0
b3IgKi8NCisJaWYgKGxzZWVrKDEsIDQ5MywgU0VFS19TRVQpICE9IDQ5MykN
CgkJZGllKCJPdXRwdXQ6IHNlZWsgZmFpbGVkIik7DQotCWJ1ZlswXSA9IHNl
dHVwX3NlY3RvcnM7DQotCWlmICh3cml0ZSgxLCBidWYsIDEpICE9IDEpDQot
CQlkaWUoIldyaXRlIG9mIHNldHVwIHNlY3RvciBjb3VudCBmYWlsZWQiKTsN
Ci0JaWYgKGxzZWVrKDEsIDUwMCwgU0VFS19TRVQpICE9IDUwMCkNCi0JCWRp
ZSgiT3V0cHV0OiBzZWVrIGZhaWxlZCIpOw0KIAlidWZbMF0gPSAoc3lzX3Np
emUgJiAweGZmKTsNCiAJYnVmWzFdID0gKChzeXNfc2l6ZSA+PiA4KSAmIDB4
ZmYpOw0KKwlidWZbMl0gPSAoKHN5c19zaXplID4+IDE2KSAmIDB4ZmYpOw0K
KwlidWZbM10gPSAoKHN5c19zaXplID4+IDI0KSAmIDB4ZmYpOw0KKwlidWZb
NF0gPSBzZXR1cF9zZWN0b3JzOw0KKwlpZiAod3JpdGUoMSwgYnVmLCA1KSAh
PSA1KQ0KKwkJZGllKCJXcml0ZSBvZiBleHRlbmRlZCBpbWFnZSBzaXplIGFu
ZCBzZXR1cCBzZWN0b3IgY291bnQgZmFpbGVkIik7DQorCWlmIChsc2Vlaygx
LCA1MDAsIFNFRUtfU0VUKSAhPSA1MDApDQorCQlkaWUoIk91dHB1dDogc2Vl
ayBmYWlsZWQiKTsNCisJaWYgKHN5c19zaXplID4gNjU1MzUpDQorCQlidWZb
MF0gPSBidWZbMV0gPSAweGZmOw0KIAlpZiAod3JpdGUoMSwgYnVmLCAyKSAh
PSAyKQ0KLQkJZGllKCJXcml0ZSBvZiBpbWFnZSBsZW5ndGggZmFpbGVkIik7
DQorCQlkaWUoIldyaXRlIG9mIGNvbXBhdGliaWxpdHkgaW1hZ2UgbGVuZ3Ro
IGZhaWxlZCIpOw0KKw0KKwkvKiBFdmVyeXRoaW5nIGlzIE9LICovDQogDQot
CXJldHVybiAwOwkJCQkJICAgIC8qIEV2ZXJ5dGhpbmcgaXMgT0sgKi8NCisJ
cmV0dXJuIDA7DQogfQ0K
--1421910094-445988011-934063993=:24414--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/