--- Day changed

--- Log opened Thu Jul 31 00:00:02 2003
00:10 -!- Reaper [~cluge@gateway-1237.mvista.com] has joined #uml
00:15 -!- solarce [solarce@64.246.42.94] has joined #uml
00:25 < solarce> Is there a skas patch against 2.4.21?
00:36 < desaster> the host-skas3.patch applies to 2.4.21 fine
00:36 < mistik1> sure does
00:39 < solarce> nice
00:39 < solarce> looking to do some swsusp testing with uml, then do lfs, in hopes it will round out my knowledge of how linux works :)
01:01 -!- ticallion [~ticallion@213.175.160.119] has joined #uml
01:02 < ticallion> howdy boys
01:03 < ticallion> man... been tryina free up one gig all night, finally made it, tryina install RHL under uml, anybody familiar with that .ru mini-howto?!
01:08 < arthur> i have 2.6.0-test2 booting, but  eth0=tuntap,tap1,,208.197.252.203 dosent work,
01:08 < arthur> no error
01:09 < arthur> works fine on 2.4.20
01:09 < arthur> on 2.6 the packets dont make it out
01:11 < Lathiat> hrm
01:11 < Lathiat> is there a patch on the uml site?
01:17  * Lathiat attempt sto debian package a 2.6.0-test2 UML
01:29 -!- ticallion [~ticallion@213.175.160.119] has quit [Quit: lat0r]
01:42 < arthur> cahnnel pole: has anyone sucessfulley used 2.6.0-test2 UML?
02:59 -!- snide [~snide@80.13.55.143] has joined #uml
02:59 < snide> hi
03:38 < G2_> hi
03:52 < BB> morning
03:59 < Lathiat> arthur: aparently just the network device wasn tworking right
03:59 < Lathiat> i was trying to debian package it earlier
04:00 < Lathiat> but i get a compile time error
04:08 < arthur> inorder to compile i had to change the type on one unused symbol
04:09 < arthur> and had to disable loadable modules
04:09 < arthur> and scsi, MTD
05:15 -!- MikeH [~mike@62.56.3.181] has quit [Ping timeout: 490 seconds]
06:32 -!- MikeH [~mike@62.56.2.207] has joined #uml
06:51 -!- mike_ [~mike@82.68.69.94] has joined #uml
06:51 -!- MikeH [~mike@62.56.2.207] has quit [Ping timeout: 488 seconds]
07:24 -!- Lathiat_ [~Lathiat@thump.bur.st] has joined #uml
07:25 -!- Lathiat [~Lathiat@2001:388:7094:4080::7] has quit [Remote host closed the connection]
07:25 -!- Lathiat [~Lathiat@2001:388:7094:4080::7] has joined #uml
07:26 -!- Lathiat_ [~Lathiat@thump.bur.st] has quit [Client Quit]
08:09 < Jon> hello
08:22 < Jon> catchar.o: unresolved symbol __generic_copy_to_user
08:22 < Jon> where can I read about getting the uml kernel / source tree to export the correct symbols, so I can use uml for kernel development?
08:31 < Jon> if such a symbol is not exported by the UML kernel, is a recompile of UML required?
08:31  * Jon cries
08:31 -!- G2_ [~G2@193.195.148.66] has quit [Quit: Client exiting]
08:32  * Lathiat comforts Jon
08:32 < Lathiat> sure you got the right headers includeD?
08:32 < Lathiat> for uml as opposed to x86 or somethign
08:34 < Jon> yeah
08:35 < Jon> 2.4.20 + um6 
08:36 < Lathiat> email the mailing list
08:36 < Jon> it appears I cannot link against the patched source tree for modules however
08:36 < Jon> because the asm portion is broken
08:36 < Jon> yeah I think I may have to
08:36 < Jon> thanks
08:42 < Jon> I'm scouring the mailing list archives now, but there's so many heh
08:43 -!- coredumb [~Click@202.159.4.160] has joined #uml
08:49 -!- coredumb [~Click@202.159.4.160] has quit []
09:00 -!- Jax [~computer_@148.100.220.72] has joined #uml
09:01 -!- Jon [~jon@imhotep.hursley.ibm.com] has quit [Read error: Connection reset by peer]
09:16 -!- mike_ [~mike@82.68.69.94] has quit [Remote host closed the connection]
09:20 -!- MikeH [~mike@82.68.69.94] has joined #uml
09:21 -!- jdike [~jdike@129.170.249.251] has joined #uml
09:25 < green> Hi Jeff!
09:27 < jdike> Hey Oleg
09:27 < jdike> green: your trip back was OK?
09:29 < green> it seems 2.6.0-test2 conversion for uml is trivial, just need to add 2 more files - asm/local.h and asm/sections.h
09:29 < jdike> green: pretty much
09:29 < green> Yes, the trip was fine. The plane have not even crashed ;)
09:30 < jdike> green: a couple people can't build it for reasons I don't understand
09:30 < green> really? Hm, builds just fine for me
09:30 < jdike> green: not crashing is always a good sign :-)
09:30 < green> yup ;)
09:30 < attriel> where do i get the BK kernel tree?  I've been using the ftp.kernel.org:/pub/linux/kernel/v2.6/linux-2.6.0-test2.tar.bz2 source
09:31 < jdike> green: me too, but a couple people have seen 'unknown size for __kernel_vsyscall' or something similar
09:31 < green> attriel: bk://linux.bkbits.net/linux-2.5
09:31 < green> jdike: Ah, hm. Bill saw it, as I remember
09:31 < jdike> and attriel is the other person who's seeing that
09:31 < green> jdike: perhaps we need to get their .config
09:31 < attriel> er, what do I need to browse a bk:// ?
09:32 < green> attriel: you can do bk clone from there (you need bitkeeper installation of course)
09:32 < attriel> ah
09:32 < jdike> green: yeah, except I think they're not doing anything odd
09:33 < green> jdike: Well, but the easiest way to verify is to get their .config and try to build with it, no?
09:33 < jdike> green: yup
09:33 < attriel> want I should fire off my .config to one of you?
09:34 < jdike> attriel: did you already post it?
09:35 < attriel> don't think so
09:35 < attriel> bill posted his though, and I tried his as well and got the same errors
09:35 < jdike> green: the one thing I did try was turning off SMP since I hadn't built a UP 2.5 kernel in a while
09:35 < jdike> green: it still built fine
09:35 < jdike> attriel: OK, I'll try Bill's config
09:36 < green> jdike: I mostly build UP kernels, though. But I ocasionally do SMP builds too
09:36 < attriel> bill was doing uniproc i was doing SMP 
09:37 < jdike> attriel: are you building from a kernel tarball or BK?
09:37 < attriel> i was using the kernel tar
09:38 < attriel> now i'm downloading the bitkeeper binary to give it a shot :o
09:40 -!- MikeH [~mike@82.68.69.94] has quit [Ping timeout: 488 seconds]
09:42 < green> jdike: seems they are getting asm-i385/elf.h being included somehow
09:43 -!- MikeH [~mike@82.68.69.94] has joined #uml
09:43 < jdike> green: I totally have't looked at it yet
09:44 < jdike> green: just built it a couple of times to make sure I didn't botch the patch
09:46 < green> I just looked and elf.h in asm-i386 is the only place where extern void __kernel_vsyscall is mentioned
09:47 < green> so it seems to be it
09:47 < green> only it is not included into anything in case of um build. At least not in my tree
09:48 < snide> btw, is there an official position for the UML kernel headers ? 
09:49 < snide> i mean, in order to be able to build vanilla modules with only a  -I/lib/modules/`uname -r`/build/include
09:50 < jdike> snide: you mean external modules?
09:50 < snide> jdike: *precisely*
09:50 < jdike> snide: there's a make trick for that, I really need to add that to the docs
09:51 < snide> jdike: i saw a patch floating around on uml-devel
09:51 < jdike> snide: what does your module use for a cc line?
09:51 < snide> jdike: i also saw ur answer to it, involving more a multiple -I 
09:52 < snide> jdike: for now it uses : -I$(KERNELDIR)/include -I$(KERNELDIR)/arch/um/include -I$(KERNELDIR)/arch/um/kernel/skas/include -I$(KERNELDIR)/arch/um/kernel/tt/include
09:52 < jdike> snide: no, that's stupidity
09:52 < snide> jdike: thx ;-)
09:52 < jdike> snide: what did it use before you mangled it?
09:52 < jdike> snide: any time :-)
09:53 < Lathiat> are there any patches to throw at 2.6.0-test21?
09:53 < snide> jdike: -I$(KERNELDIR)/include
09:53 < Lathiat> -1
09:53 < jdike> snide: the whole cc line, not just the includes?
09:53 < snide> jdike: CC ? hmmm... CFLAGS u mean
09:53 < green> Lathiat: just apply 2.6.0-test1-um to 2.6.0-test2 and add two files to include/asm-um ;)
09:53 < snide> jdike: CC=gcc-2.95
09:54 < green> Lathiat: files to add are local.h and sections.h, the content is #include <asm/arch/filename>
09:54 < snide> jdike: CFLAGS=-D__KERNEL__ -DMODULE -O2 -Wall -I$(KERNELDIR)/include
09:54 < jdike> green: I did release a test2 patch :-)
09:54 < Lathiat> ok
09:54 < Lathiat> ill make a patch for that
09:54 < green> jdike: really? I missed that
09:54 < Lathiat> ahh
09:54 < Lathiat> right
09:54 < Lathiat> ill download that then :P
09:55 < Lathiat> url to save me from putting effort in?:P
09:55 < green> jdike: well, I hope you will be able to propagate something to Linus soon ;)
09:55 < Lathiat> linus is such a bastard about accepting kernel changes isnt he
09:55 < snide> jdike: actually, i don't really mind.. since it's my own module here... so i can put just what i want inside (and right now, it's a lot of trial and error...)
09:55 < Lathiat> i mean its not like he has tonnes to run after :P
09:57 < jdike> snide: use this for your CFLAGS definition:
09:58 < jdike> CFLAGS=$(shell cd $(KERNELDIR) ; make script 'SCRIPT=@echo $(CFLAGS)' ARCH=um)
09:58  * green noticed how big divergence with official um tree I have now, not good...
09:58 < jdike> snide: (not sure about the ';', but that should be fixable)
09:59 < green> jeff: Is this "http://jdike.stearns.org:5000/uml-2.5" bk repo contains you current uml tree?
09:59 < green> (with eeverything in)
09:59 < jdike> green: I merged a bunch of your changes a while back, have you been adding more?
09:59 < jdike> green: yeah, that's everything
09:59 < snide> jdike: uuhh... 'shell' ;-(
09:59 < green> I do not know, I need to merge your stuff in and see if I have anything left
10:00 < jdike> snide: what's the problem with that?
10:00 < snide> jdike: to be honest... i don't really like the ARCH=um stuff ;-)
10:01 < snide> jdike: actually, if i'm inside UML, it should be already defined ?
10:01 < green> no
10:01 < jdike> snide: remove the ARCH=um from that and it will build a i386 module
10:02 < snide> jdike: yup.. actually, the main prob is that 'uname -m' inside UML gives a beautiful i686 ;-)
10:03 < jdike> snide: it's supposed to
10:03 < snide> jdike: hmmm... perhaps it's actually not a bug but a *feature* ;-)))
10:03 < jdike> snide: various config scripts break if they run uname and see something unexpected
10:04 < snide> jdike: yeah... but actually, it's u who opened the pandore box with a new architecture inside ;-)
10:04 < jdike> snide: heh, yup
10:04 < jdike> snide: uname actually did say uml at one point, but people complained about it
10:04 < snide> jdike: i do understand thought... guess i have to cope with that
10:05  * green pokes at IBM hoping they'd give me some free PPC boxes ;)
10:05 < snide> jdike: hmm... a launch time option ? [ time for dirty patching... ]
10:06 < jdike> snide: I think that if you are building a UML module, then you shouldn't have a problem with ARCH=um
10:07 < snide> jdike: actually, i just use UML for kernel module devel ;-p
10:08 < Lathiat> will make allmodconfig ARCH=um work?
10:08 < Lathiat> and be usable?
10:08 < Lathiat> i knwo it works but i dunno if its result is usable :)
10:08 < jdike> Lathiat: modules don't work in 2.5 yet
10:08 < Lathiat> oh i see
10:08 < Lathiat> i need to static everythign
10:08 < jdike> Lathiat: so you can build them, but you can't load them
10:09 < Lathiat> just in UML or in 2.6 generally?
10:09 < Lathiat> *5
10:09 < attriel> heck, i can't seem to get them to load in the standard 2.6, at this point; not sure if maybe they're just instantaneously unloading or not loading at all :o
10:09 < jdike> Lathiat: UML
10:09 < Lathiat> whys it broken?
10:09 < Lathiat> hard to fix or just salck? :)
10:09 < jdike> Lathiat: slack
10:09  * Lathiat beats jdike with a C compiuler
10:10 < snide> Lathiat: beware... 3.x series are quite fat nowadays...
10:11 < Lathiat> gcc -o arch/um/util/mk_task_user.o -c arch/um/util/mk_task_user.c
10:11 < Lathiat>   CC      arch/um/util/mk_task_kern.o
10:11 < Lathiat> In file included from include/asm/system-generic.h:4,
10:11 < Lathiat>  
10:11 < snide> Lathiat: it could even hurt...
10:11 < Lathiat>                  from arch/um/util/mk_task_kern.c:1:
10:11 < Lathiat> include/asm/arch/system.h:7: asm/cpufeature.h: No such file or directory
10:11 < Lathiat> m
10:11 < Lathiat> any ideas?
10:12 < snide> Lathiat: cp & ln are your best friends ?
10:12 < Lathiat> well im not quite sure what it wants from where
10:12 < Lathiat> care to enlighten me?
10:12 < jdike> Lathiat: it wants a patch
10:13 < Lathiat> oh right :P
10:13 < Lathiat> a test2 patch? ;)
10:13  * Lathiat goes and fetches one
10:13 < green> attriel: what compiler are you using
10:13 < green> ?
10:19 < attriel> gcc-3.2.2 off he top of my head
10:20 -!- MikeH [~mike@82.68.69.94] has quit [Read error: Connection reset by peer]
10:20 < attriel> and glibc 231
10:20 < green> hm.
10:21 < green> another theory was wrong ;)
10:21 < green> jdike: If only you do not put returned value into parenthesis... ;)
10:22 < jdike> green: heh
10:22 < jdike> green: that's what I'm used to
10:23 < green> yes, I see. Now I am merging all of your irq_t return stuff with mine, though. Oh well.
10:25 -!- MikeH [~mike@82.68.69.89] has joined #uml
10:28 < attriel> once it finishes getting the bk of linux-2.5 ... i apply the uml-2.6.0-test2-1 patch to it?
10:28 < green> yup
10:28 < green> the result should be the same, though
10:28 < Lathiat> arch/um/sys-i386/module.c: In function `apply_relocate':
10:28 < Lathiat> arch/um/sys-i386/module.c:79: `R_386_32' undeclared (first use in this function)
10:28 < Lathiat> a
10:31  * green done with bk resolve stuff, let's see how it will builds
10:32 < Lathiat> any ideas?
10:35 < snide> jdike: actually, ur CFLAGS line doesn't work... make dies with a make: *** Recursive variable `CFLAGS' references itself (eventually).  Stop.
10:35 < snide> jdike: did i do something wrong ?
10:36 < jdike> snide: add another $ to the CFLAGS inside the $(shell ...)
10:37 < snide> jdike: ah ? like SCRIPT=@echo $$(CFLAGS) ?
10:37 < snide> jdike: works ;-)
10:38 < Lathiat> no one wants to help poor old lathiat?
10:38  * Lathiat sulkjs
10:38 < green> jdike: Why have you made the show_stack() to be empty?
10:38  * Lathiat tries an allyesconfig
10:38 < jdike> green: I was in a hurry and didn't feel like figuring out what should go in it
10:38 < snide> jdike: but my vim has a hard time coloring the Makefile ;-))
10:39 < Lathiat> haha
10:39 < jdike> Lathiat: disable module support
10:39 < green> jdike: here is my proposed variant:
10:39 < green> void show_stack(struct task_struct *tsk, unsigned long * stack)
10:39 < green> {
10:39 < green>         if ( tsk )
10:39 < green>                 show_trace_task(tsk);
10:39 < green>         else
10:39 < green>                 show_trace(stack);
10:39 < green> }
10:39 < jdike> snide: use a real editor then
10:39 < snide> jdike: *grins* :)
10:40  * Lathiat grins at jdike
10:49 < green> Aha!
10:49 < green> arch/um/kernel/um_arch.c:51: error: storage size of `__kernel_vsyscall' isn't known
10:49 < attriel> yah, that error :p
10:49 -!- Z-Wing [zedders@81.5.136.50] has joined #uml
10:51 < jdike> green: how'd you make that happen?
10:51 < green> ok, it seems one just cannot create a real variable of "void" type which is not that surprising actually ;)
10:51 < green> I just merged your tree into mine and tried to compile it.
10:52 < jdike> green: but the patch builds fine
10:52 < green> not for me ;)
10:52 < jdike> green: and it's generated from the BK tree
10:52 < jdike> green: it did an hour ago
10:53 < attriel> i just grabbed the bk tree and about to apply the patch, i'll see what i et this time
10:53 < attriel> if my machine hasn't hung up on me ...
10:53 < green> green@angband:~> cat test1.c
10:53 < green> void somevar;
10:53 < green> int main(void)
10:53 < green> {
10:53 < green> }
10:53 < green> green@angband:~> gcc -o out test1.c
10:53 < green> test1.c:1: error: storage size of `somevar' isn't known
10:53 < green> so may be it just depends on gcc version? or may be not. Anyway...
10:54 < attriel> i swear i've seen void vars before, though :/  
10:54 < green> attriel: are you sure those were not void pointers?
10:54 < jdike> green: Well, here's what's in my test tree in um_arch.c
10:54 < jdike> void __kernel_vsyscall;
10:55 < jdike> green: and here's what the build says about it
10:55 < jdike>   CC      arch/um/kernel/um_arch.o
10:55 < green> green@angband:~> /usr/local/gcc295/bin/gcc -o out test1.c
10:55 < green> green@angband:~>
10:55 < green> hm, so gcc 2.95 compiles such a code just fine
10:55 < attriel> coulda been green :/
10:55 < green> but gcc-3.3 is not.
10:56 < snide> green: even with -Wall ?
10:56 < jdike> green: ah, I'm using 2.95
10:56 < attriel> OK, apparently that command didn't actually work ... what command do I use to get the checkout from bk?  i tried bk clone but now I have to check everything out manually? all however many files?
10:56 < green> jdike: that's it.
10:57 < green> attriel: do "bk -r co" inside of a repository
10:57 < attriel> ooh
10:57 < jdike> green: have you built that show_stack?
10:57 < green> snide: Even what with -Wall ?
10:57 < green> jdike: Yup. That version of show stack is what I use in my tree since in was introduced in mainline kernel
10:57 < snide> green: no matter ;-) [ was about void compilations ;-) ]
10:57 < attriel> hey, thanks green, thats way more efficient than doing it manually :o
10:58 < green> attriel: there was a "kernel bk howto" somewhere that details these little basic things ;)
10:58 < attriel> i should dig that up then :)  I've never used bk before :o
10:58 < attriel> (if it wasn't blindingly obviuos)
10:58 < green> jdike: I thought you use RH8 which is bundled with gcc3 of some sort, no?
10:59 < snide> green: he has a CC=gcc-2.95 line maybe ;-)
11:01 < jdike> green: I do, I reinstalled 2.95 because the RH8 gcc was causing trouble of some sort
11:01 < jdike> green: don't remember what, offhand
11:01 < jdike> green: so I have PATH=/usr/local/bin:$PATHT
11:03 < green> ah
11:04 < green> yeah, gcc 2.95 is really fast at compiles.
11:06 < jdike> OK, that's easily fixed, it'll be in the next patch
11:06 < jdike> green: I also added your show_stack()
11:06 < green> what do you plan to convert that "void" thing into?
11:07 < attriel> void is usually the s ame size as "unsigned int" isn't it ?
11:07 < jdike> attriel: just make it a void * in both um_arch.c and include/asm/archparam-i386.h
11:08 < jdike> green: void *
11:08 < green> jdike: good, the same thing I already did ;)
11:08 < jdike> green: vsyscalls aren't implemented, so it doesn't matter what it is
11:08 < green> yup
11:08 < green> arch/um/drivers/ubd_kern.c:319: warning: implicit declaration of function `ubd_is_dir'
11:08 < green> arch/um/drivers/ubd_kern.c:320: error: structure has no member named `is_dir'
11:08 < green> hm...
11:08 < green> well, everything broke on sync, just as usual.
11:08 < attriel> OK; i changed it to unsignedl ong yesterday, so i won't worry about fixing that :o
11:08 < jdike> green: you have a mangled merge, I guess
11:09 < attriel> different question:  you guys have any idea why I can't get anything but /dev/ubd0 to work? ubd1 for instance :o
11:09 < Lathiat> ok, build attempt #4
11:09 < green> well might be so
11:09 < green> attriel: wrong minors ;)
11:09  * Lathiat remembers he forgot to turn Acorn paritions off - so goes back to fix that up and goes for #5
11:10 < attriel> 98,0 98,1 and 98,2 is what it has right now; brw-r--r-- ... (ubd0, ubd1, ubd2) are those not the right minors?
11:10 < green> yup
11:10 < green> minor shift is 4 these days
11:11 < attriel> so 0, 4, 8?
11:11 < green> so they should be 98,0 98,16 and so on
11:11 < attriel> oh duh 4 BITS :o
11:14 < green> hm, bitkeeper have not deleted two lines during merge... How fun ;)
11:15 < attriel> lol
11:19 < Lathiat> kernel/posix-timers.c: In function `do_clock_nanosleep':
11:19 < Lathiat> kernel/posix-timers.c:1240: Internal compiler error:
11:19 < Lathiat> kernel/posix-timers.c:1240: internal error--unrecognizable insn:
11:19 < Lathiat> (insn/i 589 588 1116 (parallel[
11:19 < Lathiat>             (set (reg:SI 0 %eax)
11:19 < Lathiat>  
11:19 < green> yeah, this one is known
11:19 < Lathiat> and?
11:19 < Lathiat> how do i fix it :P
11:20 < green> gcc 2.95.4 from Suse 7.3 and 8.0 produces that, but plain gcc 2.95.3 works fine, I presume this is some gcc bug in your case ;)
11:20 < Lathiat> ahh
11:20 < Lathiat> im using debian
11:20 < Lathiat> ermm
11:20 < Lathiat> probably gcc-3.3
11:20 < green> I changed gcc, my coworker changed that 1240 line and added linefeed in the middle
11:20 < Lathiat> gcc version 3.3.1 20030728 (Debian prerelease)
11:20 < green> gcc 3.3 works fine for me ;)
11:20 < green> ah, 3.3.1... means you need to file a bug report ;)
11:21 < Lathiat> doh
11:21 < Lathiat> i ahte doing that
11:21 < Lathiat> whats the patch?
11:21 < Lathiat> ill file buig report later
11:21 < Lathiat> i just want a built damnit :P
11:22 < green> hehe, in case of gcc 2.95.4 we just changed the code a bit around, as I remember and it started to work
11:22  * green files a bugreport to bitmover
11:24 < green> hm, merged tree compiles and boots. Cool
11:28  * jdike documents the external module build process
11:29  * Lathiat slaps jdike
11:29 < Lathiat> this is an open source project, who needs docs!
11:30 < jdike> Lathiat: maintainers who wish to retain the few remaining shards of their sanity need docs
11:30 < jdike> Lathiat: to prevent the same questions from being asked a zillion times
11:31 < Lathiat> :)
11:31 < green> jdike: contact linuxchix, they are good at writing docs ;)
11:32 < snide> jdike: thx ;-)
11:32 < jdike> green: contact them how?
11:32 < snide> jdike: (documents the external module build process)
11:32 < green> jdike: well, write them an email ;)
11:32 < jdike> green: I'm on the mailing list and haven't seen people volunteering to write docs
11:32 < green> jdike: now that you missed the chance to discuss the stuff with them in person ;)
11:32 < jdike> green: hehe
11:33 < jdike> snide: can you fact-check it?
11:33 < jdike> snide: compile.html 
11:33 < snide> jdike: ok
11:33 < attriel> yay ubd1 works now, now i can move forward :o
11:33 < attriel> thanks green
11:33  * jdike needs to document that too
11:34 < green> too bad /proc/partition seems not to work correctly in 2.5
11:34  * green still sticks to ubd_shift of 0 ;)
11:35 < snide> jdike: so... it works for me ;-)
11:39 < snide> jdike: is MINOR(ubd1)=1 ?
11:39 < green> nope
11:40 < green> if you use standard um pathces, then it is 16
11:40 < snide> green: that's what i thought also ... so the page compile.html has an error in it ;-) [ UML# for i in 0 1 2 3 4 5 6 7; do mknod ubd$i b 98 $i; done ]
11:41 < green> well, not for me.
11:41 < snide> should read 'mknod ubd$i b 98 $(($i * 16))' no ?
11:41 < green> I changed UBD_SHIFT back to zero ;)
11:41 < snide> green: ;-)
11:42  * snide understands now the [green still sticks to ubd_shift of 0]
11:45 < jdike> snide: I just noticed that, was about to fix it
11:50 < Lathiat> umm
11:50 < Lathiat> so how do i fix that insn thing?
11:50 < snide> jdike: ;)
11:57 -!- coryb [~cory@129.237.123.31] has joined #uml
11:58 -!- snide [~snide@80.13.55.143] has quit [Quit: Killed by frash (Requested by panasync)]
12:33 < jdike> strange
12:33  * Lathiat sleeps
12:33 < jdike> rm behaves differently depending on whether the filename ends with /
12:38 < green> sure. if it ends with '/', chances are this is a directory ;)
12:44 < miah> what?
12:45 < jdike> green: the difference is if it's a symlink to a dir
12:46 < jdike> green: / makes it look at the target
12:46 < green> no. if you appended '/'. you already folowed the symlink
12:46 < jdike> green: no / makes it look at the link
12:46 < green> yup
12:46 < jdike> green: ah, that makes sense
12:46 < jdike> green: so that was namei in action?
12:46 < green> yup
13:13 < miah> \quit
13:14 -!- miah [miah@sifl.digivill.net] has quit [Quit: ircII EPIC4-1.0.1 -- Are we there yet?]
13:17 -!- Jax [~computer_@148.100.220.72] has quit [Quit: reboot....f**king winblows]
13:19 -!- OldDude [~OldDude@66.218.32.148] has joined #uml
13:32 -!- OldDude [~OldDude@66.218.32.148] has left #uml [Client exiting]
13:43 -!- MikeH [~mike@82.68.69.89] has quit [Remote host closed the connection]
13:46 -!- MikeH [~mike@82.68.69.89] has joined #uml
14:13 -!- snide [~snide@80.13.55.143] has joined #uml
14:23 -!- zanshin [~zanshin@212.187.21.137] has joined #uml
14:25 < zanshin> Does uml work on 2.6.0-testx?
14:34 < solarce> http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.6.0-test2-1.bz2
14:35 < solarce> zanshin: ;)
14:35 < zanshin> thanks I heard in kernelnewbies :)
15:01 -!- Dorian [~dorian@host81-132-150-242.in-addr.btopenworld.com] has joined #uml
15:07 -!- DorianGriffiths [~dorian@81.132.150.242] has joined #uml
15:07 -!- DorianGriffiths [~dorian@81.132.150.242] has left #uml []
15:17 -!- Dorian [~dorian@host81-132-150-242.in-addr.btopenworld.com] has left #uml []
16:52 < arthur> zanshin: i had to make a fiew tweks to get it to compile
16:53 < arthur> has anyone been scussfull with TUN/TAP in 2.6.0-test2
16:53 < arthur> ?
16:54 < jdike> arthur: the network seems not to work in 2.6 UML
16:54 < jdike> arthur: but there was a note on uml-devel from someone who fixed the problem
16:55 < snide> jdike: seems that not much works in 2.6 ;-pp *grins*
16:55 < green> snide: you can boot it, hence it is bugfree(tm)
16:55 < jdike> snide: init works
16:55 < jdike> snide: when init is running, my job is done :-)
16:56 < snide> jdike: beware... for 2.8 u'll need to rewrite init : void main() {}; ...
16:57 < arthur> thanks
16:57 < snide> jdike: btw, ur Makefile patch works nice... 
16:58 < jdike> snide: good, now that it's documented and everything, maybe people will stop bugging me about external modules
16:58  * jdike dreams on
16:59 < green> hehe. people are too lazy to search for docs
16:59 < snide> green: yup.
17:00 < snide> green: we should put up a FAQ ;) ( hmm... s/me/jeff/ ? )
17:00 < green> well, that would barely work
17:00 < jdike> snide: there's sort of one on the web site, but I don't really maintain it
17:01 < jdike> snide: I could create a FAQ category on uml.org, though
17:02 < jdike> snide: people could post stories to it, and the full faq would be accessible by selecting that category
17:03 < snide> jdike: docs are boring... faq are nice... (and actually, the biggest prob is that we don't get informed when the doc on the site is updated...)
17:04 < snide> jdike: i must admit that i don't look at them everytime ;-)
17:04 < snide> hmm... uldd is halfway of completion...
17:06 < snide> bedtime ;-)
17:06 < snide> see u all..
17:06 < snide> and thx
17:07 -!- snide [~snide@80.13.55.143] has quit [Quit: sleep_on_timeout(tommorow_morning)]
17:15 < zanshin> jdike:/usr/src/uml/linux-2.6.0-test1/arch/um/sys-i386/module.c:122: undefined reference to `apply_alternatives'
17:15 < zanshin> jdike: which file should this be in?
17:19 < jdike> zanshin: disable module support
17:20 < zanshin> ah okay thanks
17:21 < zanshin> hmmm I should have thought about that myself :)
17:31 < zanshin> jdike: btw MTD misses iobuf.h so I disabled that to.
17:32 < jdike> zanshin: have a look at uml.org, I just posted a bunch of stuff
17:34 < zanshin> k
17:35 -!- jdike [~jdike@129.170.249.251] has quit [Remote host closed the connection]
18:37 < arthur> i got 2.6.0-test2 fulley working with networking now!
18:37  * arthur is happy
18:38 < attriel> yay
18:38 < arthur> it is nessasary to specify the HWaddr for the Tun/TAP interface
18:41 -!- coryb [~cory@129.237.123.31] has quit [Quit: leaving]
19:09 < arthur> oops i think i was booting wrong kernel when i thought it was working
19:34 < david> hi
19:39 < Getty> hi\
19:39 < Getty> how are yeah? :)
19:42 < Getty> ah i'm fine, thx
19:42 < Getty> yeah ;)
20:41 -!- zanshin [~zanshin@212.187.21.137] has quit [Quit: Client exiting]
21:30 -!- arthur [~arthur@64.171.188.114] has quit [Remote host closed the connection]
21:53 -!- MikeH [~mike@82.68.69.89] has quit [Quit: Client exiting]
21:54 -!- MikeH [~mike@82.68.69.89] has joined #uml
21:57 -!- OldDude [~OldDude@adsl-66.218.32.148.dslextreme.com] has joined #uml
22:50 -!- MikeH [~mike@82.68.69.89] has quit [Read error: Connection reset by peer]
23:22 -!- MikeH [~mike@82-68-69-89.dsl.in-addr.zen.co.uk] has joined #uml
--- Log closed Fri Aug 01 00:00:00 2003