Thank you very much for the suggestions! I was wondering if the order and
numbering mattered, now I know. :-) I'll retweak and repost.
Jason
The place where you made your stand never mattered.
Only that you were there... And still on your feet.
On Wed, 19 Jan 2005, Blaisorblade wrote:
On Saturday 15 January 2005 18:32, Jason Clark wrote:
In case anyone is interested, here is the cpucap and cpuutil patches I was
talking about. They apply, but Im really not sure about the behaviour
and dont have the ability to test on a 2.6.6 kernel until Monday.
BTW, this is the first time I have worked with porting forward a kernel
patch, so be gentle.
CPUutil patch against the june 9th cpuutil release
--- util/Makefile 2004-06-09 08:12:16.000000000 -0500
+++ zutil/Makefile 2005-01-15 17:45:06.000000000 -0600
@@ -4,10 +4,6 @@
FLAGS=-Wall -O3
2.6:
- sed -e 's/NRSETCPUCAP/274/g' <cap.in > cap.c
- make cap
-
-2.6.6:
sed -e 's/NRSETCPUCAP/283/g' <cap.in >cap.c
make cap
It seems ok... NRSETCPUCAP the same thing as __NR_cpucap, i.e. is probably the
index in the syscall table for sys_cpucap... but you need probably to modify
the patch below, and update this number. See the explaination below. In
short, it will likely become 285 (instead of 283).
cpucap patch against the June 9th cpucap release for linux 2.6.9
I.e. this is the whole cpucap patch, in your forward port, correct?
--- linux-2.6.9/arch/i386/kernel/entry.S 2004-11-16 00:50:04.000000000
-0600 +++ linux-2.6.9x/arch/i386/kernel/entry.S 2005-01-15
17:16:22.000000000 -0600 @@ -902,6 +902,7 @@ ENTRY(sys_call_table)
.long sys_mq_timedreceive /* 280 */
The "280" means "This is entry no.280".
.long sys_mq_notify
.long sys_mq_getsetattr
+ .long sys_cpucap /* cpucap */
So sys_cpucap is at entry 283.
.long sys_ni_syscall /* reserved for kexec */
.long sys_waitid
--- linux-2.6.9/include/asm-i386/unistd.h 2004-10-18 16:54:37.000000000
-0500 +++ linux-2.6.9x/include/asm-i386/unistd.h 2005-01-15
17:17:44.000000000 -0600 @@ -288,10 +288,11 @@
#define __NR_mq_timedreceive (__NR_mq_open+3)
#define __NR_mq_notify (__NR_mq_open+4)
#define __NR_mq_getsetattr (__NR_mq_open+5)
-#define __NR_sys_kexec_load 283
-#define __NR_waitid 284
+#define __NR_cpucap 283
+#define __NR_sys_kexec_load 284
+#define __NR_waitid 285
-#define NR_syscalls 285
+#define NR_syscalls 286
/* user-visible error numbers are in the range -1 - -124: see
<asm-i386/errno.h> */
Ok, here (and consequently in the above two pieces) we have a problem - You
should not put cpucap before other syscalls, because code using waitid will
fail because it calls it as syscall no. 283 and actually calls cpucap(). You
need to put cpucap as 285th entry, i.e. below those two syscalls you update.
Maybe, since waitid is a recently added syscall (I'm not sure of this at all)
you won't actually run into software using it, but since you're claiming odd
behaviour this could be the cause.
For the rest of the code, I don't have suggestions to give...
--
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
