| 00:16:13 | sjhill | andersee: works! thx |
| 13:49:27 | sjhill | andersee: hi |
| 13:49:29 | andersee | sjhill: morning |
| 13:49:39 | sjhill | sorry to bother you |
| 13:49:43 | andersee | sjhill: The idea is, each malloc can provide its own memalign |
| 13:50:11 | andersee | sjhill: Then valloc is shared, and built on top of whatever memalign is currently present |
| 13:50:17 | andersee | sjhill: no problem |
| 13:50:29 | andersee | sjhill: That is why I get paid the big bucks. ;-) |
| 13:50:41 | sjhill | heh |
| 13:51:25 | andersee | sjhill: make sense? |
| 13:51:35 | sjhill | oh yes |
| 13:52:09 | andersee | Ideally, we would have just one memalign, but I suspect that will be hard... |
| 13:52:27 | sjhill | 'malloc-930716 doesn't have 'memalign'....should i not be using that? |
| 13:52:40 | sjhill | what i mean is, currently my Config uses 93701 |
| 13:53:23 | andersee | malloc-930716 does have a memalign -- its hiding in the Attic |
| 13:53:42 | andersee | I killed it, in the hope of getting a common one |
| 13:54:10 | sjhill | i shall reincarnate it then |
| 13:54:18 | sjhill | speaks incantation |
| 13:54:56 | andersee | remember to stir the goat blood only 3 times... |
| 13:55:05 | sjhill | ahh, right... :) |
| 14:01:06 | sjhill | on a very positive note, it looks like all my LTP patches were approved |
| 14:01:42 | sjhill | next we can look at uclibc vs. glibc performance somewhat |
| 14:05:29 | andersee | Very nice |
| 14:05:55 | andersee | I saw your msg (yesterday?) re almost working sans valloc |
| 14:06:05 | sjhill | yup |
| 14:06:32 | andersee | I'm very interested in seeing how we do, and seeing what (if anything) fails |
| 14:14:39 | sjhill | this is a fricking nightmare |
| 14:15:09 | sjhill | i've brought back memalign.c free.c and things still won't compile...all kinds of undefined heap variables |
| 14:17:06 | sjhill | andersee: i'm wait out of my element on this |
| 14:17:15 | sjhill | i have no fricking clue what i'm doing |
| 14:19:55 | sjhill | i don't have time for this, i'm just going to set my Config to use 'malloc' instead |
| 14:20:02 | sjhill | scre 930716 |
| 14:20:04 | sjhill | w |
| 14:22:16 | andersee | sjhill: why free? |
| 14:22:38 | andersee | will look at it |
| 14:25:08 | sjhill | i appreciate it, memory allocation algorithms scare me...a lot |
| 14:31:55 | sjhill | disappears for a bit |
| 14:31:56 | sjhill | bbl |
| 14:43:26 | sjhill | andersee: ok, i haven't left yet |
| 14:43:45 | sjhill | andersee: why is 'bits/ipc.h' only defined for alpha,mips,powerpc,sparc? |
| 14:45:26 | sjhill | it could be made common, as the files are pretty much identical |
| 14:46:05 | sjhill | i've got 3 undefined members from IPC related structures |
| 14:46:14 | sjhill | oh well, now i'm leaving |
| 17:53:31 | sjhill | mjn3: around? |
| 17:55:12 | mjn3 | sjhill: yeah... fighting trying to crosscompile X for the Zaurus... and not having much luck. :-( |
| 17:55:19 | sjhill | ewww |
| 17:55:32 | sjhill | mjn3: have you looked at 'ipc.h' and friends much? |
| 17:56:57 | mjn3 | a little. it was one of the things that was failing in the perl tests... erik rewrote that stuff to use the kernel headers right before the 0.9.15 release |
| 17:57:21 | sjhill | hmmm, stuff isn't quite right i'm afraid |
| 17:57:47 | mjn3 | not entirely unsurprising i suppose... how is it failing? |
| 17:59:08 | sjhill | in 'struct ipc_perm' in my kernel headers, i have: |
| 17:59:14 | sjhill | struct ipc_perm |
| 17:59:14 | sjhill | { |
| 17:59:14 | sjhill | __key_t __key; /* Key. */ |
| 17:59:14 | sjhill | __uid_t uid; /* Owner's user ID. */ |
| 17:59:14 | sjhill | __gid_t gid; /* Owner's group ID. */ |
| 17:59:14 | sjhill | __uid_t cuid; /* Creator's user ID. */ |
| 17:59:17 | sjhill | __gid_t cgid; /* Creator's group ID. */ |
| 17:59:20 | sjhill | unsigned short int mode; /* Read/write permission. */ |
| 17:59:22 | sjhill | unsigned short int __pad1; |
| 17:59:24 | sjhill | unsigned short int __seq; /* Sequence number. */ |
| 17:59:26 | sjhill | unsigned short int __pad2; |
| 17:59:28 | sjhill | unsigned long int __unused1; |
| 17:59:30 | sjhill | unsigned long int __unused2; |
| 17:59:32 | sjhill | }; |
| 18:01:21 | sjhill | in the uClibc 'libc/sysdeps/linux/common/bits/ipc.h' we have: |
| 18:01:28 | sjhill | { |
| 18:01:28 | sjhill | __kernel_key_t key; |
| 18:01:28 | sjhill | __kernel_uid_t uid; |
| 18:01:29 | sjhill | __kernel_gid_t gid; |
| 18:01:29 | sjhill | __kernel_uid_t cuid; |
| 18:01:29 | sjhill | __kernel_gid_t cgid; |
| 18:01:31 | sjhill | __kernel_mode_t mode; |
| 18:01:33 | sjhill | unsigned short seq; |
| 18:01:35 | sjhill | }; |
| 18:01:45 | sjhill | LTP won't compile because it wants the first structure definition |
| 18:02:04 | sjhill | but it appears, the uCblic 'ipc.h' is getting priority |
| 18:02:27 | sjhill | perhaps 'ipc.h' should be removed from uClibc i think |
| 18:03:40 | mjn3 | when you say in your kernel headers, do you mean the mips headers? |
| 18:04:17 | sjhill | i testing under x86 currently (because it's quicker)...but yes, the x86 kernel headers pointed to by the 'Config' file |
| 18:06:49 | mjn3 | well, when erik changed things, he supposedly changed them to match the kernel struct defs for each arch. on the other hand, glibc uses the same struct def on all archs and translates by copying individual struct members... what is LTP doing that depends on the struct layout? |
| 18:07:47 | sjhill | #ifdef _LINUX_ |
| 18:07:47 | sjhill | printf ("seq %d\n", buf.msg_perm.__seq); |
| 18:07:47 | sjhill | printf ("key 0x%x\n", buf.msg_perm.__key); |
| 18:07:47 | sjhill | #else |
| 18:07:48 | sjhill | printf ("seq %d\n", buf.msg_perm.seq); |
| 18:07:48 | sjhill | printf ("key %\n", buf.msg_perm.key); |
| 18:07:52 | sjhill | #endif |
| 18:07:54 | sjhill | |
| 18:08:10 | sjhill | the __seq,__key members don't exist |
| 18:10:14 | mjn3 | ahh... ok. give me a couple of minutes to look at things. |
| 18:10:34 | sjhill | i can hack it to work, but probably not nicely |
| 18:12:00 | sjhill | mjn3: actually, it hink just 'libc/sysdeps/linux/common/bits/ipc.h' needs to be changed |
| 18:41:01 | mjn3 | sjhill: sorry... just got off the phone. you're probably right. i just wanted to check and see if SUSv3 said anything about the members of struct ipc_perm |
| 18:42:32 | sjhill | k, i've already fixed the two header files so that things work |
| 18:42:40 | sjhill | i haven't checked them in yet |
| 18:44:29 | mjn3 | seq and key aren't mentioned by SUSv3 as members of struct ipc_perm so i don't see any reason not to commit your changes. key should probably be prefixed as well in common/bits/ipc.h |
| 18:45:26 | mjn3 | is babbling... forget that last sentence. ;-) |
| 18:45:30 | sjhill | i only changed files in 'common/bits'...the architecture specific files are correct, but since i'm doing x86 and there were not ipc.h files |
| 18:45:41 | mjn3 | right |
| 18:45:42 | sjhill | i just changed the common bits |
| 18:45:56 | sjhill | cool, i'll check them in shortly...thx for your comments |
| 18:46:03 | mjn3 | sure. |
| 19:38:44 | andersee | sjhill: memalign is back |
| 19:39:01 | andersee | sjhill: care to test and be sure I got it right? |
| 19:39:26 | sjhill | andersee: sure |
| 19:42:40 | sjhill | is very pleased how things have been progressing lately |
| 19:42:56 | andersee | :-) |
| 19:46:34 | sjhill | LTP flawlessly compiles against uClibc....valloc w/malloc-930716 works also...excellent! |
| 19:46:52 | sjhill | all of my patches to LTP were accepted also and will be in the next LTP release |
| 19:46:58 | sjhill | yippee! |
| 19:47:29 | sjhill | all that was for x86, now to do mips |
| 19:47:43 | sjhill | thx andersee |
| 19:51:59 | sjhill | *sigh* looks like i have a fair amount of work to get mips working |
| 19:55:44 | andersee | sjhill: cool. :) |
| 19:56:11 | andersee | sjhill: about it all working (not about there being lots of work for mips) |
| 19:58:14 | sjhill | andersee: cool, the only failure was undefined 'syscall' for mips |
| 20:01:59 | andersee | sjhill: very cool. |
| 20:02:11 | andersee | sjhill: And syscall() can be fairly easily implemented. |
| 20:16:17 | sjhill | andersee: does 'syscall' always take 5 args? |
| 20:16:37 | andersee | syscall takes as many args as are appropriate |
| 20:16:52 | andersee | Could be 7 or 8 on some arches |
| 20:16:56 | sjhill | smacks head on desk |
| 20:17:03 | andersee | Could be no args depending on the syscall |
| 20:17:04 | sjhill | ok, time for some research |
| 20:18:05 | sjhill | so this '__uClibc_syscall.S' is just a placeholder you made, correct? |
| 20:18:13 | sjhill | i remember you telling me that MIPS was a bit confusing |
| 20:20:50 | sjhill | oh wonderful, glibc has an elegant implementation of syscall for mips |
| 20:20:54 | sjhill | tries it |
| 20:24:41 | andersee | sjhill: the __uClibc_syscall.S is designed for a special unified syscall thing that I've mostly killed by implementing syscalls better |
| 20:29:55 | sjhill | is uberhacker |
| 20:30:28 | andersee | hehe |
| 20:30:32 | andersee | So it works? |
| 20:30:44 | sjhill | it compiles, which is good enough for starts :) |
| 20:32:40 | sjhill | booting mips board |
| 20:43:41 | sjhill | kick ass |
| 20:43:50 | sjhill | 'syscall' works on mips |
| 20:50:27 | sjhill | andersee: everything is checked in and working |
| 20:50:34 | sjhill | what an awesome day |
| 20:52:27 | andersee | :-) |
| 20:53:08 | andersee | I give your boss permission to give you the rest of the day off. :) |
| 20:53:10 | sjhill | tomorrow, 'lmbench' is next and then torture testing |
| 20:53:18 | sjhill | heh |
| 21:45:40 | andersee | is away: I'm busy |