[00:06] <groz> interesting, if you include kmod-zd1211 in your build
[00:06] <groz> kernel goes ooops when you insert a memory stick
[00:09] <[mbm]> which means it's a badly written module
[00:10] <groz> no kiddin
[00:10] <groz> i woulda never guessed
[00:10] <[mbm]> yep, good thing you have me here to explain these things ..
[00:11] <groz> so, please explain then
[00:11] <groz> why is the sky blue ?
[00:11] <[mbm]> it's actually orange, adjust the tint controls
[00:11] <groz> you need to get out and away from the computer more
[00:12] <[mbm]> the sky most certainly isn't blue in my world
[00:12] <[mbm]> most of the time it's black
[00:12] <groz> ya i forgot, you live in the land of smog
[00:13] <[mbm]> there's a few dead pixels which are stuck white
[00:13] <groz> see now if you were up north, where life is good, it's only black for a short period during the summer
[00:13] <groz> the rest of the time, the pixels all work fine
[00:30] <groz> ok, mbm, here is another 'food for thought'
[00:31] <groz> hotplug feeds us info on devices as they come/go
[00:31] <groz> kernel devs are indeed trying to rid the world of devfs
[00:31] <groz> whats your thoughts on a hotplug script that just runs mknod
[00:32] <groz> when devices are plugged ?
[00:32] <[mbm]> it'd probably come with some crazy name like 'udev'
[00:32] <groz> is that what udev does ?
[00:32] <[mbm]> in a nutshell, yes
[00:33] <groz> hmm, my only experience with udev so far
[00:33] <groz> it is makes desktop machines fail to boot
[00:36] <groz> but i did notice it in the packages list last nite
[00:37] <CIA-17> groz * r4604 /branches/buildroot-ng/openwrt/target/linux/generic-2.6/files/ (init postinit): Update init to use /etc/banner for presence test, remove postinit
[00:38] <CIA-17> groz * r4605 /branches/buildroot-ng/openwrt/include/kernel-build.mk: Remove postinit stuff for initramfs
[00:46] <groz> http://pastebin.ca/138063
[00:46] <groz> now there is a box with room to play, probly fit almost all the packages on there
[00:52] <[mbm]> :)
[00:52] Action: [mbm] likes df's -h option
[01:01] <groz> http://pastebin.ca/138077
[01:01] <groz> there, happy ?
[01:01] <groz> chalk another arch up to 'just works'
[01:01] <groz> note the lilo menu here too
[01:02] Action: [mbm] doesn't comment on free's -m option ...
[01:02] <[mbm]> anywyas, that's really cool
[01:02] <groz> options like that are for folks that cant read computerspeak
[01:02] <[mbm]> I can, I just refuse to
[01:02] <[mbm]> btw, when I boot to ramdisk is there an option "dump to udb stick" ?
[01:03] <[mbm]> er usb ..
[01:03] <groz> no, because, it doesn't have the lilo boot stuff in it
[01:03] <groz> but, my mkboot script in the lilo package
[01:03] <groz> will create an img you can dd to the stick
[01:03] <groz> sooo, what i do
[01:03] <groz> i netboot the image, scp it on, then dd to the stick
[01:03] <groz> netboot into ramdisk obviously
[01:04] <[mbm]> hmm
[01:04] <groz> then after its on, i resize it, tune it to add the journal, then manually mount once as ext3
[01:04] <groz> and after that, it'll always mount as ext3
[01:04] <groz> if you dont manually do that once, it'll keep mounting as ext2
[01:05] <groz> again, more i can streamline, but, this is the big hurdle
[01:05] <[mbm]> well, everythign apart from the kernel and lilo could be dumped on the stick
[01:05] <groz> it makes pc just work
[01:05] <groz> yah
[01:05] <groz> and you could then probly set it up to nfs mount a lilo source
[01:05] <[mbm]> er wait .. your kernel is part of the filesystem on those things
[01:05] <groz> and lilo the stick manually
[01:05] <groz> well, it's incestuous
[01:06] <groz> first an empty file system is created
[01:06] <groz> that's used as the initramfs, without a kernel in it i mean by empty
[01:06] <groz> then the mkboot script mounts it, adds a kernel to it, lilo runs, and you end up with boot.img
[01:06] <groz> which is the file system with kernel
[01:06] <groz> the initramfs does not include the kernel
[01:06] <[mbm]> I just mean if you added a new option in menuconfig to toss the kenrel and lilo on the initramfs you'd have everything you need
[01:07] <groz> yah, that could be done
[01:07] <groz> so just netboot it, and include a script to format the stick, put the stuff on, lilo it
[01:07] <groz> will need a few utils in the initial image, but, that's not a big deal
[01:07] <[mbm]> might be a handy way to deploy it
[01:08] <groz> actually it would be, and i did enough manual copies along the way
[01:08] <groz> i almost did something like that
[01:08] <groz> then, go the next step
[01:08] <groz> create netboot and pxe boot images in the bin directory
[01:08] <groz> and it becomes turnkey
[01:08] <[mbm]> :)
[01:08] <groz> the thing about my lilo example setup
[01:08] <groz> it assumes serial console
[01:08] <groz> i shoud probably change it so it'll work with a keyboard
[01:09] <[mbm]> you know, all my computers now support pxe out of the box but I've never actually used it
[01:09] <groz> the kernel doesn't even have keyboard/console support right now
[01:09] <groz> oh, i long ago set up netboot, so
[01:09] <groz> now the ones that come with pxe, i go to rom-o-matic
[01:09] <groz> and fetch a pxe boot rom
[01:09] <groz> 2 step process, they pxe boot a netboot boot rom
[01:09] <[mbm]> hmm can keyboard/console support be loaded as a module or will we need to move to generating kernel .configs?
[01:09] <groz> then netboot my elf images
[01:10] <groz> hmmm, i'll play with that
[01:10] <groz> the big issue, kernel boot spew on the console
[01:10] <groz> vs on the serial port
[01:10] <groz> may have to wire in console, module load keyboard
[01:11] <groz> the other detail
[01:11] <groz> most of the kmod stuff isn't correctly making autoload
[01:11] <groz> so, if you need something that doesn't autoload ok, you'll have to tweak
[01:11] <groz> but i think the right fix for that
[01:11] <groz> is fixing autoload
[01:11] <groz> the usb stick stuff autoloads ok
[01:11] <groz> its still in the old kmod stuff
[01:12] <groz> but example, my network driver via rhine, the new kmod stuff is not generating the autoload
[01:12] <groz> so i actually have it in an Sxx script on my media
[01:12] <groz> the initramfs is not initializing network
[01:12] <groz> but that;'s ok for me
[01:12] <groz> i can manually insmod and dhcp if i'm in a ramdisk or failsafe
[01:12] <[mbm]> well, as I said before we need to move the autoload macros out of the kernel makefile
[01:13] <[mbm]> and use them globally
[01:13] <groz> i know, and i haven't touched em yet
[01:13] <groz> to many things need done, it's priorities
[01:13] <groz> for me, the current priority was, get my via boards up and running
[01:13] <[mbm]> :)
[01:13] <CIA-17> mbm * r4606 /packages/net/ (cbtt/Makefile dsl-qos-queue/Makefile): fix makefile
[01:13] <groz> and now, i've arrived, nice clean setup on them
[01:14] Action: [mbm] is expecting several new toys in the mail in about a week
[01:14] <groz> what kind of toys ?
[01:14] Action: [mbm] can't say yet
[01:15] <groz> well, i have another target coming real soon, will be interesting
[01:15] <groz> its gonna be uclinux
[01:15] <groz> a processor with no mmu
[01:15] <groz> i'm sure i can get base stuff up and going ok
[01:16] <groz> but how much you wanna bet, a lot of packages will be a no go
[01:16] <[mbm]> yeah actually one of the toys doesn't have an mmu
[01:16] <[mbm]> uclibc has a few mmu options so I really doubt the packages will even notice
[01:17] <groz> fork breaks
[01:17] <groz> so, it'll be a big thing on a lot of them
[01:17] <groz> it has to be done differently
[01:17] <[mbm]> hmm didn't know that (I've never actually run a non-mmu)
[01:18] <groz> example
[01:18] <groz> udhcpd doesn't run
[01:18] <groz> or at least it didn't when i was playing a while back
[01:18] <groz> have to change the way things fork off to background
[01:18] <groz> and be VERY congizant of your memory map when you do
[01:18] <groz> cuz you will fragment it badly if you are not careful spawning stuff
[01:19] <groz> you can end up with lots of little bits free, and no single spot big enough to run any programs anymore
[01:19] <groz> this is why most real cheap ap/router stuff requires a reboot when you change options
[01:20] <groz> so the processes get restarted in the right order for the memory map
[02:22] <rugolini> groz ?
[08:01] <CIA-17> florian * r4607 /packages/net/wccpd/ (. Config.in Makefile ipkg/): Port wccpd to -ng
[08:43] <[florian]> I am off for the weekend, and will be back around midnight sunday, see you !
[08:48] <groz> florian, who said you can have a weekend off ????
[08:48] <groz> :)
[08:49] <[florian]> no choice, I am away :)
[10:11] <db90h> nbd once told me, but I've forgotten.. regarding porting webif to kamikaze, what are the current issues? I've seen that someone has already created a proper configuration file for lighttp, but it seems he said there were other issues...
[10:13] <db90h> i am working together with some people on a project to vastly extend the current white russian webif, until this new package configuration format is widely adopted, then it can be revamped. While waiting for the awesome power of kamikaze, I'd really like to bring WR6 to more people .. also, I think I will finally work on the library pruning i've ranted about for so long.. both of which should be easily migratable to kamikaze, b
[10:14] <db90h> you may disagree, but I believe that the White Russian branch needs to be updated a lot, because the ambitious plans for buildroot-ng seen to mandate it will be a long while before it's ready... in the meantime, there is a big gap
[10:15] <db90h> so, this is my aim.. work on the White Russian Branch, tyring to do things that will later be easily portable to kamikaze
[10:16] <groz> db, i guess that depends on what you mean by 'ready'
[10:16] <groz> but from my perspective, i think ng is 'ready' for it's target audience
[10:17] <groz> which is developers
[10:18] <groz> ie the folks that make things for end users
[10:18] <db90h> my intended target audience is not developers.. i am still tempted to use buildroot-ng instead, as i know it more readily furthers openwrt, but...
[10:18] <groz> i dont thing -ng will ever 'just produce' anything directly targetted at the end user
[10:18] <groz> it's a tool that developers will use, to make it easier for them to produce an 'end user' thingy
[10:19] <db90h> i guess i should give buildroot-ng a try.. but i just fear having to go and address issues. I don't want to work on the base system, I want to work on extending it into the end user space.. so I must have a stable backbone
[10:19] <groz> no, you need a consistent setup, which means, dont go svn up every half hour
[10:19] <db90h> well I am the target audience of openwrt I think, as I've said to many.. this is what OpenWrt is made for, to build from ;)
[10:20] <groz> if you keep chasing head, it'll never be stable
[10:20] <groz> you gotta grab a snapshot that works for what you want to work on, then go work on it
[10:21] <groz> if you wait for ng to be 'finished', it's gonna be a LONG wait, cuz it's the kind of thing that'll grow forever
[10:21] <db90h> well i think what i'm doing now will be readily portable to ng, so perhaps you guys can be on the lookout for a relatively stable revision of buildroot-ng to recommend me to?
[10:21] <db90h> or is the current revision relatively stable AND at least as feature complete as WR?
[10:21] <groz> actually, what you are doing now, is yakking on irc, and that'll never produce anything but more yakking
[10:22] <db90h> lol
[10:22] <db90h> well i was working, before i started yakking ;)
[10:22] <db90h> i thought i'd solicit pretty much the same info i solicited yesterday, because i'm still not sure what i want to do ;)
[10:23] <db90h> so the end effect of this conversation: please let me know if there is a buildroot-ng revision that comes up that you believe i won't have to go fixing issues for to build from
[10:24] <groz> well, what final hardware are you targetting ?
[10:24] <db90h> broadcom 43xx only
[10:24] <groz> but if you took a snapshot now
[10:24] <groz> you could do a lot of the grunt work, granted, you will have the 'google doesn't load right' issue
[10:25] <groz> and a few others probably, no biggie if it doesn't affect what you are working
[10:25] <db90h> indeed, i don't want that issue ;)
[10:25] <groz> but it is my understanding, everything you want to work on is user interface basically no ?
[10:25] <db90h> i'd have to move the older driver to it, that'd be #1 step
[10:25] <groz> so why bother with hardware at all then
[10:25] <db90h> mostly.. that and startup scripts, plus i am going to do the library pruning
[10:25] <groz> work it all up in the uml build
[10:25] <groz> and when it's ready
[10:25] <groz> rebuild for final target
[10:26] <db90h> because i want it to run on hardware right away, i am not into doing something that comes to fruition months down the line
[10:26] <groz> you just waste a lot of time reflashing
[10:26] <groz> as it progresses
[10:26] <[mbm]> as already pointed out, it's not stripping the libraries as much as it's recompiling the libraries from the .a
[10:26] <groz> in a uml, you can stop and restart in 10 seconds
[10:26] <db90h> true, i would like to set up a virtual environment of some time
[10:27] <groz> and if your pruning stuff is properly generalized
[10:27] <db90h> [mbm]: yea, that's what i mean, pruning the libraries (removing unused objects by relinking)
[10:27] <groz> it'll prune just fine in the x86 uml target
[10:27] <groz> and still work fine run against the final broadcom target
[10:27] <db90h> [mbm]: unless you mean something different? please tell me if you do, i may misunderstand something
[10:27] <groz> and then, it's useful for ALL tiny systems
[10:28] <[mbm]> might I make the suggestion that you compile *all* of the packages and then do that trick to see which functions aren't used by any of the currently ported programs ...
[10:28] <groz> gonna be an awful small list
[10:28] <[mbm]> well, there's several openssl functions which almost never get used
[10:29] <[mbm]> and various other similar examples
[10:29] Action: groz points to _almost_ as the qualifier
[10:29] <db90h> yes, i do plan on compiling all and seeing how much is unused
[10:29] <db90h> but i could implement it in the image builder..
[10:29] <[mbm]> but it's nowhere near as effective as just strippind down to the absolute minimum needed to support the current firmware image
[10:29] <db90h> so that it's only used when people build relatively static images
[10:29] <[mbm]> can
[10:30] <[mbm]> can't be done in imagebuilder
[10:30] <db90h> oh, it can't?
[10:30] <[mbm]> you need to read the script more carefully
[10:30] <db90h> ok
[10:30] <[mbm]> short version:
[10:31] <[mbm]> when you compile a .c file, you get a .o file
[10:31] <[mbm]> a statically liked library is nothing more than an ar archive of .o files
[10:32] <[mbm]> you can literally un-ar it and get back a dump of the .o files
[10:32] <db90h> yea, i know how linking works.. i didn't think it through, you are right
[10:32] <[mbm]> a shared library is a .so file, and it's actually a compiled elf binary
[10:33] <[mbm]> for your trick to work, you need the .a files, and you need a compiler
[10:33] <[mbm]> btw, after running your script you can still run sstrip on the new .so to save even more space
[10:33] <groz> here's a better trick then
[10:34] <db90h> yea, i planned to run sstrip afterwards on the entire file system
[10:34] <groz> why not make scripts to automatically merge everything into one multi binary like busybox
[10:34] <groz> and then static link that
[10:34] <[mbm]> heh, I'll one up you on that
[10:34] <groz> that'll get you 'no extras'
[10:35] <[mbm]> suppose a binary uses the libraries libc, libfoo, libbar
[10:35] <db90h> it'd be one very large multi-binary.. on systems with little free RAM, do you think it would affect its ability to load?
[10:35] <[mbm]> you can map out which symbols it uses
[10:35] <[mbm]> and you can produce libraries libc, libfoo and libbar as per the example script
[10:35] <[mbm]> BUT
[10:35] <[mbm]> there's no reason that the symbols the program needs from libbar have to actaully come from libbar
[10:36] <groz> dont forget to check for dependancies between the libs too, cuz libc may use something from libfoo
[10:36] <[mbm]> so, if I wanted to I could put all the symbols in libc
[10:36] <groz> yes, then soft link libfoo to libc
[10:36] <[mbm]> wouldn't need to
[10:36] <groz> and the program would never know the difference
[10:36] <groz> if you leave it as a dynamic lib
[10:37] <db90h> are you saying link all the objects into one single library, regardless of what library they original were linked into?
[10:37] <[mbm]> db90h: bingo
[10:37] <[mbm]> well, the program unless modified is going to look for libfoo and libbar and whine loudly if it can't find them
[10:38] <[mbm]> the advantage to putting them all into one lib like that is to reduce the elf overhead
[10:38] <db90h> is there that much ELF overhead?
[10:38] <[mbm]> you'll save a bit
[10:39] <db90h> every bit counts indeed
[10:39] <[mbm]> it also means faster loading since the library will already be in memory
[10:39] <db90h> an effect on RAM use?
[10:39] <db90h> err any
[10:39] <groz> 25 years ago, every bit counted, today, a kilobyte costs less than a bit did then
[10:39] <groz> just buy more ram
[10:40] <[mbm]> linux is smart enough that if two programs both request libfoo they basically share one copy of it in ram
[10:40] <db90h> i'm not at all famaliar with the way linux maps executables into memory.. if it loads pages of the physical images on-demand, then it should be ok with RAM use
[10:40] <db90h> right, copy on write?
[10:40] <[mbm]> of certain sections
[10:40] <groz> code will always load only once
[10:40] <groz> data sections will be recreated
[10:40] <db90h> at least, that's how Windows does it.. shares them unless the pages are written to, then makes a copy of the modified pages for all processes to which they are mapped into ... of course, some sections are RO most all the time
[10:41] <groz> but, only as needed
[10:41] <[mbm]> now the ram usage for an individual program might appear higher
[10:41] <groz> yes, but only applicable if the processor has an mmu
[10:41] <db90h> err, makes a copy of the previously shared modified page for the process that modified it i mean ;)
[10:41] <groz> it normally does appear high mbm, if th eprogram uses threads
[10:41] <[mbm]> if my program never used libfoo and it suddenly has to load a libc containing libfoo and libbar then it will appear as if the program is using more ram
[10:42] <groz> cuz each thread gets a context, but much of the context is duplicated
[10:42] <[mbm]> right
[10:42] <groz> cuz alth there is one physical copy of say the copyright message in the data segs
[10:42] <groz> it's mapped once for each thread
[10:42] <groz> so with 10 threads, it looks like it's loaded at 10 different addresses
[10:42] <groz> in reality, the same page is mapped 10 times
[10:43] <[mbm]> I'm also not sure if it'll let you symlink libfoo back to libc or if at some point you'll have to create an empty library and just symlink everything to that
[10:43] <db90h> ok, so the simple answer is RAM use won't be really affected... as far as the programs that depend on libfoo, does it need changes so that the symbols are imported from libc instead, or is a symlink ok?
[10:44] Action: [mbm] hasn't dug through ld lately
[10:44] Action: groz has never dug thru ld, faster and cheaper to buy a stick of ram
[10:44] <[mbm]> an unresolved symbol isn't specific through a library
[10:44] <groz> hehe
[10:44] <db90h> oh ok
[10:44] <[mbm]> suppose I use the function printf
[10:45] <db90h> in Portable Executables imports are specific to their applicable modules
[10:45] <[mbm]> the program will just say 'unresolved symbol printf, used at location ___, ___, ___ ..."
[10:45] <groz> now you are going to the territory that is commonly referred to a dll-hell
[10:45] <[mbm]> at no point does it say where the printf function came from
[10:45] <groz> cuz, assume you built expecting printf from libfoo
[10:45] <groz> but printf has been stripped outa libfoo
[10:45] <[mbm]> but it will say to attempt to load libc, libfoo and libbar
[10:46] <groz> and libbar exports printf, but, a different vairant
[10:46] <groz> with different stack conventions
[10:46] <[mbm]> it works on the basis that after loading all those libraries, one of them will have a printf symbol
[10:46] <groz> precisely
[10:47] <[mbm]> the table of where the function was used in my program is called a relocation table
[10:47] <[mbm]> and that's tons of fun
[10:47] <groz> and that is why a glibc upgrade can get so painful
[10:47] <[mbm]> to undstand what I mean by that you have to understand ltrace
[10:47] <groz> cuz it changes the conventions of the calls, but, the binaries dont realize that
[10:47] <groz> they link, and call blindly
[10:47] <db90h> and the address of the function is put into addresses referenced by the relocatable table, I assume?
[10:47] <[mbm]> ltrace will read in a relocation table and figure out where all the calls to printf are in my program (and any other shared symbols)
[10:48] <[mbm]> and then it will put breakpoints on those locations
[10:48] <db90h> makes sense
[10:48] <[mbm]> allowing me to monitor the arguments that get passed to printf and the return code from it
[10:48] <db90h> i've worked with Windows Portable Executables for many years, and they are not so different, from your description of ELFs.. but I have still not done my homework on the ELF format, I need to
[10:49] <[mbm]> so if a program uses tons of shared libraries, I can basically ltrace it and get a very clear high level view of the program
[10:49] <[mbm]> strace on the other hand works based on syscalls
[10:49] <[mbm]> which are very low level, almost atomic
[10:49] <db90h> in Windows there is usually a jump table that is where the imported API address get placed, and all calls to imports go through this single jump table
[10:50] <[mbm]> right .. ltrace doesn't work on the mips platform
[10:50] <[mbm]> and the reason for that is the elf implementation on mips
[10:50] <[mbm]> there's no relocation table
[10:50] <[mbm]> there's a global pointer
[10:50] <[mbm]> which works as a jump table
[10:51] <[mbm]> (and nobody has gotten around to patching ltrace to handle that format since it's highly mips specific)
[10:51] <db90h> ah, understood
[10:51] <db90h> i hadn't even heard of ltrace before, i'll have to check it out.. that's awful handy ;)
[10:52] <groz> if you want to really get fancy , you set up a system
[10:52] <groz> and trace it for a week, logging the trace
[10:52] <[mbm]> yeah, I had tons of fun with ltrace on the tivos when they used to have multiple executables and shared libraries
[10:52] <groz> then you compare that to all the functions in everything
[10:52] <groz> and you will be able to figure out what was never called
[10:52] <[mbm]> shortly after publishing some of that research they switched to one large executable with statically linked libraries
[10:52] <groz> it's kind of the reverse process of doing a coverage analysis
[10:53] <db90h> the API hookers in Windows I've seen are nowhere near as simple to use as you make ltrace sound.. how does it know the calling convention and number of parameters of functions though? does it have a list, or is this information specified somewhere in the symbol definitions?
[10:53] <groz> db, you assume the headers are available
[10:53] <groz> and it becomes easy
[10:53] <[mbm]> db90h: ah, it knows that because it scans /usr/include and reads in the headers from the libraries
[10:53] <db90h> oh, ok, so it builds them from that ;)
[10:54] <[mbm]> the ltrace code is a hell of a lot cleaner than the strace code
[10:54] <[mbm]> even though they both work on similar principles
[10:54] <db90h> which is a nice effect of open source software, the headers are almost always there, you don't have many proprietary modules who functions have unknown calling conventions and parameters
[10:54] <[mbm]> oh, another fun trick if you want to mess with people -
[10:55] <[mbm]> insert a breakpoint into your program
[10:55] <[mbm]> just write it into the code
[10:55] <[mbm]> you can crash debuggers that go crazy trying to figure out what caued the breakpoint
[10:56] <db90h> hehe
[10:56] <db90h> does linux ignore breakpoints if a debugger isn't attached to the process then?
[10:57] <db90h> Windows sure doesn't, int 3 is attached to an exception handler that throws an exception to the user if no other handler is there..
[10:57] <[mbm]> no, it's based on the assumption that you've written an exception handler in your program that just ignores the breakpoint
[10:57] <db90h> err, i shouldn't say int 3, that's x86 specific ;)
[10:57] <db90h> oh, ok, that makes more sense
[10:57] <[mbm]> which also means that you know explicitly if your program is being traced or not
[10:57] <[mbm]> based on if your exception handler got hit
[10:58] <db90h> i didn't know software protection mechanisms were used in OSS ;p
[10:58] <[mbm]> and if you're very evil, you can have two code paths
[10:58] <[mbm]> one that gets seen by the debugger, and one that gets seen when the program runs natively
[10:59] Action: [mbm] knows all sorts of dirty tricks
[10:59] <db90h> usually my policy is to just simply change some random thing when i find a debugger and let the fault occur way on down the line ;)
[11:00] <groz> lame, much better to have a ring 0 component in, and just tell it to wipe the hardware interrupt vector table
[11:00] <groz> much more effective
[11:00] <db90h> lol
[11:00] <db90h> much more evil ;)
[11:00] <db90h> well now i know much more about how linux works.. thanks for that
[11:00] <groz> oh, you want to have fun figuring some things out
[11:01] <groz> try this one, i had an oops once in a driver
[11:01] <groz> floppy driver
[11:01] <groz> arithmetic error in dma code
[11:01] <groz> so, it was reading the floppy, and, dma transferring that data to random location in physical ram
[11:02] <groz> i _believer_ it ended up in the disk cache data
[11:02] <groz> and then the cache flushed
[11:02] <db90h> so it wrote the read data to some random spot on disk?
[11:02] <groz> end result, a little while later, i was restoring backup tapes
[11:02] <db90h> hehe
[11:02] <groz> my whole source tree just vanished
[11:03] <groz> and then shortly after, the machine crashed hard
[11:03] <[mbm]> heh
[11:03] <groz> when it came back, there was no mbr
[11:03] <db90h> that's why you always write ring 0 code on a dedicated, expendable machine ;)
[11:03] <[mbm]> I did that just a few days ago with my new system
[11:03] <groz> the funny part was
[11:03] <groz> myu project at the time, tape backup software
[11:03] <groz> and my backup was less than 3 hours old
[11:03] <groz> but
[11:03] <groz> the ONLY copy of the program i had to restore the tape
[11:03] <groz> was on the wiped drive
[11:04] <groz> i had to go get a copy of the installer from a recent beta release
[11:04] <groz> from one of my beta sites
[11:04] <groz> to be able to restore the tapes
[11:04] <[mbm]> turns out that the 'amd cool n quiet' is guarnateed to crash my kernel within 30 seconds of bootup, and in that process it compeltely invalidates the disk cache
[11:04] <[mbm]> and the end result was that it wiped out several key files on the disk
[11:04] <[mbm]> in this case I logged in and my motd had been replaced my a mimecap
[11:05] <db90h> i believe crashing your kernel is technically making your computer cool 'n quiet ;)
[11:05] <[mbm]> and the sql server was complaining that the databases were trashed
[11:05] <db90h> hehe
[11:06] <[mbm]> some weird interaction between the cooln quiet and the kernel's power management .. it's documented on several linux forums
[11:06] <[mbm]> annoying as hell though
[11:06] <db90h> i haven't had any such accidents in a while, haven't done any NT device driver development in a long time.. but it seems every driver I develop I have to go through about 100 BSODs before it's ready for prime time ;)
[11:06] <[mbm]> especially since I was playing with the bios trying to nail down the faulty ram timings when I discovered it
[11:07] <[mbm]> (brand new system and it was running unstable because it didn't like the ram I bought it :P)
[11:08] <db90h> my current system is doing almost random hard-freezes for some reason.. I think it's related to the video adaptor, but i don't know more.. been trying to track it down forever
[11:08] <[mbm]> db90h: you need to do a better job of planning before you actually write the code :)
[11:08] <db90h> oh, i thought writing code was planning ;)
[11:09] Action: [mbm] used to have fun at the university, you'd see all the first year students sit down and spend 4 hours writing code, not once even attempting to compile it
[11:09] <[mbm]> and then once written they would yell for help because they had 80 pages of error messages attempting to compile it
[11:09] <[mbm]> and once all those were fixed they'd find the logic was faulty
[11:10] <db90h> hehehe
[11:10] <db90h> they will learn better quickly ;)
[11:11] <[mbm]> several of them learned they didn't like cs and switched to cis or buisness
[11:11] <db90h> the CS students at my university were 70% totally incompetent even as seniors..dunno if that's a norm in the undustry or what
[11:11] <db90h> of course, i went to a lame university
[11:11] <[mbm]> depends on where you go
[11:11] <[mbm]> for a small university or one that doesn't specialize in cs that's prefectly normal
[11:12] <[mbm]> and even gets into the 99% really don't have a clue even after they've graduated
[11:12] <[mbm]> if you go to one of the expensive technical universities it's a compeltely different story
[11:12] <groz> that's a high level of competence compared to average it department at <insert big corp name here>
[11:12] <db90h> if I were hiring people, I don't think i'd give much thought to a degree or resume.. they prove so little in the end
[11:13] <[mbm]> that's why most interviwers will ask you programming questions or logic puzzles
[11:13] <[mbm]> microsoft and google are famous for giving logic puzzles
[11:14] <db90h> i had this one instructor who told a story of a interview he had at Microsoft (for a job).. they asked him to write a bubble sort algorithm (or something like that) on the spot... he said to them "I have a masters degree! I'm not writing any bubble sort!" and walked out... I thought to myself, yea right, he probably was afraid he couldn't do it ;)
[11:14] <[mbm]> if you ever apply to a job and nobody asks you any technical questions, RUN!
[11:15] <[mbm]> there's only two reasons why that will happen: 1) they're totally incompetent and don't have anythig good to ask
[11:15] <[mbm]> or 2) you're famous and they don't need to ask
[11:15] <[mbm]> chances are it's 1
[11:15] <db90h> the times i've got a coding job, i use my web site as a resume .. i say, 'just go here..' ;)
[11:16] <[mbm]> I've always been asked programming questions
[11:17] <[mbm]> stuff like "here is a singly linked list, each node points to the next node and the last node points to a null; what's the most efficient way to get the 10th item from the end?"
[11:18] <db90h> i like how it defines a singly linked list in the question ;p
[11:18] <db90h> well, i guess they could be structured differently, maybe
[11:19] <[mbm]> right, the goal is to keep you from pestering them about the structure of the list
[11:19] <groz> hmm, i've rarely been asked technical questions, but, often spend a lot of time on 'architectural' discussion
[11:19] <groz> i've NEVER had anybody ask specific programming questins
[11:19] <[mbm]> groz: yeah, I get that too
[11:19] <groz> wait, not ture
[11:19] <groz> once, way way back
[11:19] <groz> i was asked a few asm technical questions
[11:19] <[mbm]> depends on where you apply
[11:19] <[mbm]> and what you'll be doing
[11:20] <db90h> is there a more efficient way than iterating through the list, recording the pointer to NODE-10 (after you've reached +10 nodes or more), then emitting that pointer when you've reached the end?
[11:21] <groz> mbm, depends how big that list is
[11:21] <db90h> i need to go get a job, but i have not liked any programming job i've had.. i get to where i don't like programming anymore
[11:21] <[mbm]> db90h: I came up with two solutions, one terribly unoptimized recursive one that walked through the list and then went 10 back in the stack
[11:21] <[mbm]> and another one that had a 10 item circular buffer
[11:22] <[mbm]> and would walk through the list once, writing every node to the buffer
[11:22] <[mbm]> and then return the oldest item in the buffer
[11:22] <db90h> ah, yes, you would have to use a stack or something to track NODE-10
[11:22] <groz> see, you guys do it the hard way
[11:22] <groz> i'd write the problem down, then hand it to the jr programmers, tell em to bring me back a solution
[11:23] <[mbm]> the recursion one impressed them just because I was able to give a working example without much thought
[11:23] <[mbm]> apparently most people have real issues trying to mentally keep track of recursion
[11:24] <[mbm]> but doing it that way eats up tons of stack space
[11:24] <db90h> i haven't really been through any interviews, everyone who has hired me really knew of me already.. but i had one employer who told me about his interview process. He said the most important thing was if someone didn't know how to solve a problem, they were humble enough to ask for aid (which he made avaialble before-hand)
[11:25] <[mbm]> oh .. there's one more (evil) way to solve the above problem
[11:25] <[mbm]> and that's using xor
[11:26] <[mbm]> you can make a singly linked list into a doubly linked list
[11:26] <Bartman007> lol, that's great
[11:26] <db90h> xor each pointer by the next, then u can re-traverse by reversing the xor
[11:26] <Bartman007> I always love solutions that effectively rewrite the problem =)
[11:26] <[mbm]> the trick is that the pointer is "previous item xor next item"
[11:26] <[mbm]> right
[11:26] <db90h> that's brilliant ;)
[11:27] <[mbm]> it's assumed that you either know the previous or next node
[11:27] <db90h> i would have never thought of that on the spot, it came to me when u said xor, but it's very creative
[11:27] <groz> guess they ddin't specify you were not allowed to damage the list
[11:27] <db90h> you just need one xor variable, don't you?
[11:28] <[mbm]> you'd overwrite the existing pointers
[11:30] Action: [mbm] loves evil programming tricks
[11:30] Action: groz thinks mbm has not yet had to deploy stuff into the real world, and take over maintanence on project written by kids that love evil tricks
[11:30] <db90h> hehe
[11:31] <[mbm]> groz: heh, I know enough to document my evil hacks
[11:31] <[mbm]> now, depending on how much I like you, I may or may not give you that documentation when I give you the sources
[11:31] <Bartman007> but the source is the documentation :-P
[11:31] <groz> well a lot of my recent work is moving to stuff where evil hacks not permitted
[11:32] <groz> everything must be verifiable
[11:32] <[mbm]> Bartman007: heh, if you say so
[11:32] <groz> and eventually ends up certified
[11:32] <[mbm]> groz: fips?
[11:32] <db90h> lol, self-docuemnting source code.. that is an OSS mantra it seems ;)
[11:32] <groz> do-178
[11:32] <[mbm]> ah
[11:32] <Bartman007> [mbm]: it's the documentation for at least a few hours... then you forget wtf each bit does.
[11:32] <[mbm]> Bartman007: exactly
[11:33] <groz> take any byte in the executeble, show what line of code generated it, and, then what line in the spec requires it
[11:33] <groz> and then prove it's not a safety issue
[11:33] <db90h> what i find annoying is when people don't record rationale for doing non-obvious things... that is the #1 thing required for good project maintenance
[11:33] <groz> db90, ever looked inside microsoft produced vga video drivers
[11:34] <db90h> nope
[11:34] <groz> they compile code on the stack on the fly, then execute it
[11:34] <groz> that's the main reason why it was such a big deal for windows to deal with nx
[11:34] <groz> cuz windows is full of self modifyng crap like that
[11:34] <db90h> hehe, that's a virus trick ;)
[11:34] <groz> it's a performance trick
[11:34] <groz> it's faster to generate and execute highly optimized blit code, than to run general purpose
[11:34] <db90h> with DEP that isn't so valid anymore..
[11:35] <groz> in 99% of cases
[11:35] <db90h> i mean, execute protection on non-executable pages.. whatever u linux guys call it
[11:35] <db90h> course you can just modify the page permissions
[11:36] <[mbm]> one of my friends has this great approach to writing code - don't try to be creative and nest loops and get all of your code indented 40 characters, the code should be written so the single intented code is the normal case and anything indented more than that is an error condition
[11:36] <db90h> sounds kinda unreadable to me ;p
[11:36] <[mbm]> which makes it very trivial to visually scan over a function
[11:36] <Bartman007> [mbm]: ow...
[11:36] <db90h> i use identation for every branch and loop
[11:37] <db90h> err conditional branch
[11:37] <Bartman007> I take it he doesn't write python?
[11:37] <[mbm]> well, I didn't mean it like that
[11:37] <[mbm]> the code is properly indented
[11:37] <db90h> oh, ok ;)
[11:37] <db90h> i thought u meant no identation except error conditions
[11:37] <db90h> that does make more sense
[11:38] <[mbm]> but the code is written in such a way that usually when you see an indented section of code it's because it's part of an error handler
[11:39] <Bartman007> ouch, my computer doesn't play playing flash video while buildroot-ng is compiling, and I'm folding in the background...
[11:40] <[mbm]> http://svn.mythtv.org/svn/trunk/mythtv/libs/libmythtv/hdhomerun/hdhomerun_discover.c .. not the best example but it illustrates what I mean
[11:40] <[mbm]> look at what parts of the code are indented
[11:44] <[mbm]> (see what I mean?)
[11:49] <Bartman007> [mbm]: that's fairly cool, though it does take some getting used to
[11:49] <groz> give it 5 years to 'grow'
[11:49] <groz> it wont look so pretty anymore
[11:53] <[mbm]> it really just means two things - write conditionals only to handle exceptions, and use functions rather than indenting the code further
[12:00] <groz> in years gone past, i woulda argued about stack growth etc, but, a good compiler will actually end up inlining it all anyways
[12:00] <groz> so it makes sense to write it maintainable
[12:09] <groz> mbm, philisophical question for you
[12:09] <groz> example, package iptables, includes firewall scripts etc
[12:10] <groz> i'd like to break it into 2 pacakges, one, iptables, just iptables, second, firewall scripts, dependant on iptables
[12:10] <groz> so it's possible to get iptables on a box, but, not drag along the default firewall setup
[12:11] <[mbm]> think the firewall script is currently part of base-files
[12:11] <groz> i think it doesn't end up in there if you dont put in iptables
[12:11] <[mbm]> but yeah, I can see what you're getting at
[12:11] <groz> so it must be part of iptables
[12:11] <groz> so an openwrt example image, would include firewall
[12:11] <groz> that'll drag along iptables
[12:12] <groz> but, it's a pain to have to delete that firewall script
[12:12] <[mbm]> really my only concern is package management overhead
[12:12] <groz> well, it goes in the same makefile
[12:12] <groz> just 2 packages from the same makefile
[12:12] <[mbm]> .. will you let me explain? ...
[12:12] Action: groz waits
[12:13] <[mbm]> if you were to go to the extreme and put every file into a new ippk, then you _will_ have overhead
[12:13] <[mbm]> because of the ipkg databases being meintained on the router
[12:13] <[mbm]> which store things like the name, version, description of each package and the list of files installed by that package
[12:14] <[mbm]> so it's ideal to beak things down into as few packages as required
[12:15] <[mbm]> even if it only saves you a few k for each ipkg
[12:15] <[mbm]> ...
[12:15] <groz> well the current iptables scripts that come along, _assume_ its going on a masquerading router
[12:16] <[mbm]> yeah I know
[12:17] <[mbm]> and really I don't care if the firewall gets moved to another ipkg
[12:17] <groz> i just finished building one called _mypolicies_ made it dependant on iptables, and put 'rm -f /etc/init.d/S45firewall' into it's preinst
[12:17] <[mbm]> just don't go overboard with creating new ipkgs
[12:17] <groz> no, this is a case, of a very defined 'function group'
[12:17] <[mbm]> right
[12:17] <groz> the firewall is a unique function
[12:17] <[mbm]> ...
[12:18] <groz> i'm actually looking at all the iptables modules groups, wondering if there's to many of them
[12:18] <[mbm]> well, that's the other side of packages
[12:18] <groz> yep
[12:20] <groz> this knife has 2 edges
[12:20] <[mbm]> if I install a package, I want it to only install what I've asked for
[12:20] <[mbm]> and not to install everything
[12:20] <groz> and they are both sharp
[12:20] <[mbm]> yep.
[12:20] <groz> been wondering about some sort of functional heirarchy
[12:20] <groz> for package displays
[12:20] <groz> ie, ipkg list
[12:20] <groz> is kinda huge
[12:20] <groz> and alphabetical
[12:20] <[mbm]> and as I said, I really don't care exactly where the edge is, just as long as it's somewhat reasonable
[12:20] <[mbm]> (so you really don't need to waste time trying to sell me on the idea)
[12:20] <groz> i'm not trying
[12:20] <groz> i'm just contemplating whats reasonable, and this one is
[12:20] <[mbm]> well, you did explain it a few times above
[12:20] <groz> but i dont really wanna end up in a pissing match after the fact
[12:21] <[mbm]> heh
[12:22] <[mbm]> usually works like this: give me some vauge idea what you're planning and I'll either drag you into the details or say "whatever" and let you do it
[12:22] <groz> you know what would be cool, a 'netboot' option in lilo
[12:22] Action: groz gonna go see if i can co-erce lilo to chain a netboot rom image
[12:23] <[mbm]> how would that work?
[12:23] <groz> lilo loads a netboot rom image, executes it
[12:23] <groz> and it netboots a kernel, instead of a local one
[12:23] <groz> cuz th ebios on this thing is to brain dead to let me configure it as optional
[12:23] <groz> it's on or off
[12:23] <[mbm]> well, it wouldn't exactly be a netboot if lilo loaded it off the drive
[12:23] <groz> well, i want to test a kernel
[12:23] <[mbm]> and as far as I know that's all lilo will do
[12:23] <groz> without actually flashing it
[12:24] <groz> but just a once off
[12:24] <groz> lilo will chain load a dos setup
[12:24] <groz> and i've got setups where a netboot runs from a dos boot disk
[12:24] <groz> I'll try that
[12:25] <groz> just put a dos boot disk image in there, that actually has a netboot exe in as command.com
[12:26] <groz> just a pain to switch this board back and forth, it's not on the kvm anymore
[16:02] <dbcch> if i want to temporarily quit using the target/ patches and instead work on a static firmware source, what would be the most proper way to modify the makefiles to handle this/?
[16:08] <nbd> why do you want to do this?
[16:09] <dbcch> because it'll be more convienent when i am messing around on the source tree
[16:10] <nbd> you can change things in build_mipsel/linux/
[16:10] <dbcch> thanks
[16:11] <nbd> maybe you'll have to delete vmlinux and stamp files
[16:12] <dbcch> ok
[16:13] <dbcch> do you guys always generate those target/ style patches manually?
[16:14] <nbd> i do it like this:
[16:14] <nbd> i run make target/linux-{clean,prepare} to have an openwrt-patched kernel tree
[16:14] <nbd> i copy that to build_mipsel/linux.dev and linux.old
[16:15] <nbd> then i hack around in linux.dev and copy changed files to linux/
[16:15] <nbd> if i do hacks for debugging, then i put those in linux/ directly
[16:15] <nbd> when i'm done, i diff linux.dev and linux.old
[16:15] <nbd> and have a clean patch
[16:16] <dbcch> makes sense
[16:16] <nbd> maybe i'll write a few scripts to automate parts of this process, but for me it's fast enough
[16:17] <dbcch> mirabilis says freewrt has some automated generation of thoes patches now, tho the style of the build root isn't the same as openwrt anymore
[16:17] <nbd> their scripts generate one patch per file
[16:18] <nbd> which i don't like at all
[16:18] <dbcch> that's a lot more patch files no doubt ;)
[16:18] <nbd> because there's no separation between logical changes
[16:18] <nbd> which is very important to me
[16:18] <dbcch> yea, i see your point
[16:18] <dbcch> with openwrt, u have patche sets in one file that add X or remove Y
[16:18] <nbd> exactly
[16:20] <dbcch> so you have been keeping up with the freewrt changes?
[16:20] <nbd> parts
[16:20] <nbd> there is not much for us to keep up with imho
[16:21] <dbcch> i haven't looked at it in a while, may check it out again whenever they finish totally overhauling the build root
[16:22] <nbd> all the overhaul that i can see in their buildroot is a few added scripts and a few variable name changes
[16:22] <dbcch> i thought i saw in one of the recent digests about a whole new directory structure, but maybe i misread, i just glanced at it
[16:23] <nbd> they were talking about a few changes, most of which only requires changing the variable name in rules.mk
[16:23] <dbcch> oh, ok
[16:23] <nbd> and it's not entirely different, just a few small changes
[16:24] <nbd> nothing comparable to buildroot-ng
[16:45] <CIA-17> nbd * r4608 /branches/buildroot-ng/openwrt/package/base-files/default/lib/network/config.sh: fix typo
[16:59] <CIA-17> nbd * r4609 /branches/buildroot-ng/openwrt/target/linux/aruba-2.6/config: enable ipip for aruba
[17:00] <CIA-17> nbd * r4610 /branches/buildroot-ng/openwrt/target/image/aruba/Makefile: don't pad aruba images - unnecessary with the jffs2 hack
[18:55] <nbd> [mbm]: btw. i'm working on merging the umts support into whiterussian and buildroot-ng now
[18:55] <nbd> [mbm]: (i have access to some test hardware now)
[19:14] <nbd> [mbm]: ping
[23:39] <db90h> unless I'm mis-perceiving things, CIFS seems to be caching file system data on shares (it ought to).. how can I force this read cache to be flushed?
[23:40] <db90h> i guess remount until i know a better way
[00:00] --- Sun Aug 20 2006
[00:06] <groz> kernel goes ooops when you insert a memory stick
[00:09] <[mbm]> which means it's a badly written module
[00:10] <groz> no kiddin
[00:10] <groz> i woulda never guessed
[00:10] <[mbm]> yep, good thing you have me here to explain these things ..
[00:11] <groz> so, please explain then
[00:11] <groz> why is the sky blue ?
[00:11] <[mbm]> it's actually orange, adjust the tint controls
[00:11] <groz> you need to get out and away from the computer more
[00:12] <[mbm]> the sky most certainly isn't blue in my world
[00:12] <[mbm]> most of the time it's black
[00:12] <groz> ya i forgot, you live in the land of smog
[00:13] <[mbm]> there's a few dead pixels which are stuck white
[00:13] <groz> see now if you were up north, where life is good, it's only black for a short period during the summer
[00:13] <groz> the rest of the time, the pixels all work fine
[00:30] <groz> ok, mbm, here is another 'food for thought'
[00:31] <groz> hotplug feeds us info on devices as they come/go
[00:31] <groz> kernel devs are indeed trying to rid the world of devfs
[00:31] <groz> whats your thoughts on a hotplug script that just runs mknod
[00:32] <groz> when devices are plugged ?
[00:32] <[mbm]> it'd probably come with some crazy name like 'udev'
[00:32] <groz> is that what udev does ?
[00:32] <[mbm]> in a nutshell, yes
[00:33] <groz> hmm, my only experience with udev so far
[00:33] <groz> it is makes desktop machines fail to boot
[00:36] <groz> but i did notice it in the packages list last nite
[00:37] <CIA-17> groz * r4604 /branches/buildroot-ng/openwrt/target/linux/generic-2.6/files/ (init postinit): Update init to use /etc/banner for presence test, remove postinit
[00:38] <CIA-17> groz * r4605 /branches/buildroot-ng/openwrt/include/kernel-build.mk: Remove postinit stuff for initramfs
[00:46] <groz> http://pastebin.ca/138063
[00:46] <groz> now there is a box with room to play, probly fit almost all the packages on there
[00:52] <[mbm]> :)
[00:52] Action: [mbm] likes df's -h option
[01:01] <groz> http://pastebin.ca/138077
[01:01] <groz> there, happy ?
[01:01] <groz> chalk another arch up to 'just works'
[01:01] <groz> note the lilo menu here too
[01:02] Action: [mbm] doesn't comment on free's -m option ...
[01:02] <[mbm]> anywyas, that's really cool
[01:02] <groz> options like that are for folks that cant read computerspeak
[01:02] <[mbm]> I can, I just refuse to
[01:02] <[mbm]> btw, when I boot to ramdisk is there an option "dump to udb stick" ?
[01:03] <[mbm]> er usb ..
[01:03] <groz> no, because, it doesn't have the lilo boot stuff in it
[01:03] <groz> but, my mkboot script in the lilo package
[01:03] <groz> will create an img you can dd to the stick
[01:03] <groz> sooo, what i do
[01:03] <groz> i netboot the image, scp it on, then dd to the stick
[01:03] <groz> netboot into ramdisk obviously
[01:04] <[mbm]> hmm
[01:04] <groz> then after its on, i resize it, tune it to add the journal, then manually mount once as ext3
[01:04] <groz> and after that, it'll always mount as ext3
[01:04] <groz> if you dont manually do that once, it'll keep mounting as ext2
[01:05] <groz> again, more i can streamline, but, this is the big hurdle
[01:05] <[mbm]> well, everythign apart from the kernel and lilo could be dumped on the stick
[01:05] <groz> it makes pc just work
[01:05] <groz> yah
[01:05] <groz> and you could then probly set it up to nfs mount a lilo source
[01:05] <[mbm]> er wait .. your kernel is part of the filesystem on those things
[01:05] <groz> and lilo the stick manually
[01:05] <groz> well, it's incestuous
[01:06] <groz> first an empty file system is created
[01:06] <groz> that's used as the initramfs, without a kernel in it i mean by empty
[01:06] <groz> then the mkboot script mounts it, adds a kernel to it, lilo runs, and you end up with boot.img
[01:06] <groz> which is the file system with kernel
[01:06] <groz> the initramfs does not include the kernel
[01:06] <[mbm]> I just mean if you added a new option in menuconfig to toss the kenrel and lilo on the initramfs you'd have everything you need
[01:07] <groz> yah, that could be done
[01:07] <groz> so just netboot it, and include a script to format the stick, put the stuff on, lilo it
[01:07] <groz> will need a few utils in the initial image, but, that's not a big deal
[01:07] <[mbm]> might be a handy way to deploy it
[01:08] <groz> actually it would be, and i did enough manual copies along the way
[01:08] <groz> i almost did something like that
[01:08] <groz> then, go the next step
[01:08] <groz> create netboot and pxe boot images in the bin directory
[01:08] <groz> and it becomes turnkey
[01:08] <[mbm]> :)
[01:08] <groz> the thing about my lilo example setup
[01:08] <groz> it assumes serial console
[01:08] <groz> i shoud probably change it so it'll work with a keyboard
[01:09] <[mbm]> you know, all my computers now support pxe out of the box but I've never actually used it
[01:09] <groz> the kernel doesn't even have keyboard/console support right now
[01:09] <groz> oh, i long ago set up netboot, so
[01:09] <groz> now the ones that come with pxe, i go to rom-o-matic
[01:09] <groz> and fetch a pxe boot rom
[01:09] <groz> 2 step process, they pxe boot a netboot boot rom
[01:09] <[mbm]> hmm can keyboard/console support be loaded as a module or will we need to move to generating kernel .configs?
[01:09] <groz> then netboot my elf images
[01:10] <groz> hmmm, i'll play with that
[01:10] <groz> the big issue, kernel boot spew on the console
[01:10] <groz> vs on the serial port
[01:10] <groz> may have to wire in console, module load keyboard
[01:11] <groz> the other detail
[01:11] <groz> most of the kmod stuff isn't correctly making autoload
[01:11] <groz> so, if you need something that doesn't autoload ok, you'll have to tweak
[01:11] <groz> but i think the right fix for that
[01:11] <groz> is fixing autoload
[01:11] <groz> the usb stick stuff autoloads ok
[01:11] <groz> its still in the old kmod stuff
[01:12] <groz> but example, my network driver via rhine, the new kmod stuff is not generating the autoload
[01:12] <groz> so i actually have it in an Sxx script on my media
[01:12] <groz> the initramfs is not initializing network
[01:12] <groz> but that;'s ok for me
[01:12] <groz> i can manually insmod and dhcp if i'm in a ramdisk or failsafe
[01:12] <[mbm]> well, as I said before we need to move the autoload macros out of the kernel makefile
[01:13] <[mbm]> and use them globally
[01:13] <groz> i know, and i haven't touched em yet
[01:13] <groz> to many things need done, it's priorities
[01:13] <groz> for me, the current priority was, get my via boards up and running
[01:13] <[mbm]> :)
[01:13] <CIA-17> mbm * r4606 /packages/net/ (cbtt/Makefile dsl-qos-queue/Makefile): fix makefile
[01:13] <groz> and now, i've arrived, nice clean setup on them
[01:14] Action: [mbm] is expecting several new toys in the mail in about a week
[01:14] <groz> what kind of toys ?
[01:14] Action: [mbm] can't say yet
[01:15] <groz> well, i have another target coming real soon, will be interesting
[01:15] <groz> its gonna be uclinux
[01:15] <groz> a processor with no mmu
[01:15] <groz> i'm sure i can get base stuff up and going ok
[01:16] <groz> but how much you wanna bet, a lot of packages will be a no go
[01:16] <[mbm]> yeah actually one of the toys doesn't have an mmu
[01:16] <[mbm]> uclibc has a few mmu options so I really doubt the packages will even notice
[01:17] <groz> fork breaks
[01:17] <groz> so, it'll be a big thing on a lot of them
[01:17] <groz> it has to be done differently
[01:17] <[mbm]> hmm didn't know that (I've never actually run a non-mmu)
[01:18] <groz> example
[01:18] <groz> udhcpd doesn't run
[01:18] <groz> or at least it didn't when i was playing a while back
[01:18] <groz> have to change the way things fork off to background
[01:18] <groz> and be VERY congizant of your memory map when you do
[01:18] <groz> cuz you will fragment it badly if you are not careful spawning stuff
[01:19] <groz> you can end up with lots of little bits free, and no single spot big enough to run any programs anymore
[01:19] <groz> this is why most real cheap ap/router stuff requires a reboot when you change options
[01:20] <groz> so the processes get restarted in the right order for the memory map
[02:22] <rugolini> groz ?
[08:01] <CIA-17> florian * r4607 /packages/net/wccpd/ (. Config.in Makefile ipkg/): Port wccpd to -ng
[08:43] <[florian]> I am off for the weekend, and will be back around midnight sunday, see you !
[08:48] <groz> florian, who said you can have a weekend off ????
[08:48] <groz> :)
[08:49] <[florian]> no choice, I am away :)
[10:11] <db90h> nbd once told me, but I've forgotten.. regarding porting webif to kamikaze, what are the current issues? I've seen that someone has already created a proper configuration file for lighttp, but it seems he said there were other issues...
[10:13] <db90h> i am working together with some people on a project to vastly extend the current white russian webif, until this new package configuration format is widely adopted, then it can be revamped. While waiting for the awesome power of kamikaze, I'd really like to bring WR6 to more people .. also, I think I will finally work on the library pruning i've ranted about for so long.. both of which should be easily migratable to kamikaze, b
[10:14] <db90h> you may disagree, but I believe that the White Russian branch needs to be updated a lot, because the ambitious plans for buildroot-ng seen to mandate it will be a long while before it's ready... in the meantime, there is a big gap
[10:15] <db90h> so, this is my aim.. work on the White Russian Branch, tyring to do things that will later be easily portable to kamikaze
[10:16] <groz> db, i guess that depends on what you mean by 'ready'
[10:16] <groz> but from my perspective, i think ng is 'ready' for it's target audience
[10:17] <groz> which is developers
[10:18] <groz> ie the folks that make things for end users
[10:18] <db90h> my intended target audience is not developers.. i am still tempted to use buildroot-ng instead, as i know it more readily furthers openwrt, but...
[10:18] <groz> i dont thing -ng will ever 'just produce' anything directly targetted at the end user
[10:18] <groz> it's a tool that developers will use, to make it easier for them to produce an 'end user' thingy
[10:19] <db90h> i guess i should give buildroot-ng a try.. but i just fear having to go and address issues. I don't want to work on the base system, I want to work on extending it into the end user space.. so I must have a stable backbone
[10:19] <groz> no, you need a consistent setup, which means, dont go svn up every half hour
[10:19] <db90h> well I am the target audience of openwrt I think, as I've said to many.. this is what OpenWrt is made for, to build from ;)
[10:20] <groz> if you keep chasing head, it'll never be stable
[10:20] <groz> you gotta grab a snapshot that works for what you want to work on, then go work on it
[10:21] <groz> if you wait for ng to be 'finished', it's gonna be a LONG wait, cuz it's the kind of thing that'll grow forever
[10:21] <db90h> well i think what i'm doing now will be readily portable to ng, so perhaps you guys can be on the lookout for a relatively stable revision of buildroot-ng to recommend me to?
[10:21] <db90h> or is the current revision relatively stable AND at least as feature complete as WR?
[10:21] <groz> actually, what you are doing now, is yakking on irc, and that'll never produce anything but more yakking
[10:22] <db90h> lol
[10:22] <db90h> well i was working, before i started yakking ;)
[10:22] <db90h> i thought i'd solicit pretty much the same info i solicited yesterday, because i'm still not sure what i want to do ;)
[10:23] <db90h> so the end effect of this conversation: please let me know if there is a buildroot-ng revision that comes up that you believe i won't have to go fixing issues for to build from
[10:24] <groz> well, what final hardware are you targetting ?
[10:24] <db90h> broadcom 43xx only
[10:24] <groz> but if you took a snapshot now
[10:24] <groz> you could do a lot of the grunt work, granted, you will have the 'google doesn't load right' issue
[10:25] <groz> and a few others probably, no biggie if it doesn't affect what you are working
[10:25] <db90h> indeed, i don't want that issue ;)
[10:25] <groz> but it is my understanding, everything you want to work on is user interface basically no ?
[10:25] <db90h> i'd have to move the older driver to it, that'd be #1 step
[10:25] <groz> so why bother with hardware at all then
[10:25] <db90h> mostly.. that and startup scripts, plus i am going to do the library pruning
[10:25] <groz> work it all up in the uml build
[10:25] <groz> and when it's ready
[10:25] <groz> rebuild for final target
[10:26] <db90h> because i want it to run on hardware right away, i am not into doing something that comes to fruition months down the line
[10:26] <groz> you just waste a lot of time reflashing
[10:26] <groz> as it progresses
[10:26] <[mbm]> as already pointed out, it's not stripping the libraries as much as it's recompiling the libraries from the .a
[10:26] <groz> in a uml, you can stop and restart in 10 seconds
[10:26] <db90h> true, i would like to set up a virtual environment of some time
[10:27] <groz> and if your pruning stuff is properly generalized
[10:27] <db90h> [mbm]: yea, that's what i mean, pruning the libraries (removing unused objects by relinking)
[10:27] <groz> it'll prune just fine in the x86 uml target
[10:27] <groz> and still work fine run against the final broadcom target
[10:27] <db90h> [mbm]: unless you mean something different? please tell me if you do, i may misunderstand something
[10:27] <groz> and then, it's useful for ALL tiny systems
[10:28] <[mbm]> might I make the suggestion that you compile *all* of the packages and then do that trick to see which functions aren't used by any of the currently ported programs ...
[10:28] <groz> gonna be an awful small list
[10:28] <[mbm]> well, there's several openssl functions which almost never get used
[10:29] <[mbm]> and various other similar examples
[10:29] Action: groz points to _almost_ as the qualifier
[10:29] <db90h> yes, i do plan on compiling all and seeing how much is unused
[10:29] <db90h> but i could implement it in the image builder..
[10:29] <[mbm]> but it's nowhere near as effective as just strippind down to the absolute minimum needed to support the current firmware image
[10:29] <db90h> so that it's only used when people build relatively static images
[10:29] <[mbm]> can
[10:30] <[mbm]> can't be done in imagebuilder
[10:30] <db90h> oh, it can't?
[10:30] <[mbm]> you need to read the script more carefully
[10:30] <db90h> ok
[10:30] <[mbm]> short version:
[10:31] <[mbm]> when you compile a .c file, you get a .o file
[10:31] <[mbm]> a statically liked library is nothing more than an ar archive of .o files
[10:32] <[mbm]> you can literally un-ar it and get back a dump of the .o files
[10:32] <db90h> yea, i know how linking works.. i didn't think it through, you are right
[10:32] <[mbm]> a shared library is a .so file, and it's actually a compiled elf binary
[10:33] <[mbm]> for your trick to work, you need the .a files, and you need a compiler
[10:33] <[mbm]> btw, after running your script you can still run sstrip on the new .so to save even more space
[10:33] <groz> here's a better trick then
[10:34] <db90h> yea, i planned to run sstrip afterwards on the entire file system
[10:34] <groz> why not make scripts to automatically merge everything into one multi binary like busybox
[10:34] <groz> and then static link that
[10:34] <[mbm]> heh, I'll one up you on that
[10:34] <groz> that'll get you 'no extras'
[10:35] <[mbm]> suppose a binary uses the libraries libc, libfoo, libbar
[10:35] <db90h> it'd be one very large multi-binary.. on systems with little free RAM, do you think it would affect its ability to load?
[10:35] <[mbm]> you can map out which symbols it uses
[10:35] <[mbm]> and you can produce libraries libc, libfoo and libbar as per the example script
[10:35] <[mbm]> BUT
[10:35] <[mbm]> there's no reason that the symbols the program needs from libbar have to actaully come from libbar
[10:36] <groz> dont forget to check for dependancies between the libs too, cuz libc may use something from libfoo
[10:36] <[mbm]> so, if I wanted to I could put all the symbols in libc
[10:36] <groz> yes, then soft link libfoo to libc
[10:36] <[mbm]> wouldn't need to
[10:36] <groz> and the program would never know the difference
[10:36] <groz> if you leave it as a dynamic lib
[10:37] <db90h> are you saying link all the objects into one single library, regardless of what library they original were linked into?
[10:37] <[mbm]> db90h: bingo
[10:37] <[mbm]> well, the program unless modified is going to look for libfoo and libbar and whine loudly if it can't find them
[10:38] <[mbm]> the advantage to putting them all into one lib like that is to reduce the elf overhead
[10:38] <db90h> is there that much ELF overhead?
[10:38] <[mbm]> you'll save a bit
[10:39] <db90h> every bit counts indeed
[10:39] <[mbm]> it also means faster loading since the library will already be in memory
[10:39] <db90h> an effect on RAM use?
[10:39] <db90h> err any
[10:39] <groz> 25 years ago, every bit counted, today, a kilobyte costs less than a bit did then
[10:39] <groz> just buy more ram
[10:40] <[mbm]> linux is smart enough that if two programs both request libfoo they basically share one copy of it in ram
[10:40] <db90h> i'm not at all famaliar with the way linux maps executables into memory.. if it loads pages of the physical images on-demand, then it should be ok with RAM use
[10:40] <db90h> right, copy on write?
[10:40] <[mbm]> of certain sections
[10:40] <groz> code will always load only once
[10:40] <groz> data sections will be recreated
[10:40] <db90h> at least, that's how Windows does it.. shares them unless the pages are written to, then makes a copy of the modified pages for all processes to which they are mapped into ... of course, some sections are RO most all the time
[10:41] <groz> but, only as needed
[10:41] <[mbm]> now the ram usage for an individual program might appear higher
[10:41] <groz> yes, but only applicable if the processor has an mmu
[10:41] <db90h> err, makes a copy of the previously shared modified page for the process that modified it i mean ;)
[10:41] <groz> it normally does appear high mbm, if th eprogram uses threads
[10:41] <[mbm]> if my program never used libfoo and it suddenly has to load a libc containing libfoo and libbar then it will appear as if the program is using more ram
[10:42] <groz> cuz each thread gets a context, but much of the context is duplicated
[10:42] <[mbm]> right
[10:42] <groz> cuz alth there is one physical copy of say the copyright message in the data segs
[10:42] <groz> it's mapped once for each thread
[10:42] <groz> so with 10 threads, it looks like it's loaded at 10 different addresses
[10:42] <groz> in reality, the same page is mapped 10 times
[10:43] <[mbm]> I'm also not sure if it'll let you symlink libfoo back to libc or if at some point you'll have to create an empty library and just symlink everything to that
[10:43] <db90h> ok, so the simple answer is RAM use won't be really affected... as far as the programs that depend on libfoo, does it need changes so that the symbols are imported from libc instead, or is a symlink ok?
[10:44] Action: [mbm] hasn't dug through ld lately
[10:44] Action: groz has never dug thru ld, faster and cheaper to buy a stick of ram
[10:44] <[mbm]> an unresolved symbol isn't specific through a library
[10:44] <groz> hehe
[10:44] <db90h> oh ok
[10:44] <[mbm]> suppose I use the function printf
[10:45] <db90h> in Portable Executables imports are specific to their applicable modules
[10:45] <[mbm]> the program will just say 'unresolved symbol printf, used at location ___, ___, ___ ..."
[10:45] <groz> now you are going to the territory that is commonly referred to a dll-hell
[10:45] <[mbm]> at no point does it say where the printf function came from
[10:45] <groz> cuz, assume you built expecting printf from libfoo
[10:45] <groz> but printf has been stripped outa libfoo
[10:45] <[mbm]> but it will say to attempt to load libc, libfoo and libbar
[10:46] <groz> and libbar exports printf, but, a different vairant
[10:46] <groz> with different stack conventions
[10:46] <[mbm]> it works on the basis that after loading all those libraries, one of them will have a printf symbol
[10:46] <groz> precisely
[10:47] <[mbm]> the table of where the function was used in my program is called a relocation table
[10:47] <[mbm]> and that's tons of fun
[10:47] <groz> and that is why a glibc upgrade can get so painful
[10:47] <[mbm]> to undstand what I mean by that you have to understand ltrace
[10:47] <groz> cuz it changes the conventions of the calls, but, the binaries dont realize that
[10:47] <groz> they link, and call blindly
[10:47] <db90h> and the address of the function is put into addresses referenced by the relocatable table, I assume?
[10:47] <[mbm]> ltrace will read in a relocation table and figure out where all the calls to printf are in my program (and any other shared symbols)
[10:48] <[mbm]> and then it will put breakpoints on those locations
[10:48] <db90h> makes sense
[10:48] <[mbm]> allowing me to monitor the arguments that get passed to printf and the return code from it
[10:48] <db90h> i've worked with Windows Portable Executables for many years, and they are not so different, from your description of ELFs.. but I have still not done my homework on the ELF format, I need to
[10:49] <[mbm]> so if a program uses tons of shared libraries, I can basically ltrace it and get a very clear high level view of the program
[10:49] <[mbm]> strace on the other hand works based on syscalls
[10:49] <[mbm]> which are very low level, almost atomic
[10:49] <db90h> in Windows there is usually a jump table that is where the imported API address get placed, and all calls to imports go through this single jump table
[10:50] <[mbm]> right .. ltrace doesn't work on the mips platform
[10:50] <[mbm]> and the reason for that is the elf implementation on mips
[10:50] <[mbm]> there's no relocation table
[10:50] <[mbm]> there's a global pointer
[10:50] <[mbm]> which works as a jump table
[10:51] <[mbm]> (and nobody has gotten around to patching ltrace to handle that format since it's highly mips specific)
[10:51] <db90h> ah, understood
[10:51] <db90h> i hadn't even heard of ltrace before, i'll have to check it out.. that's awful handy ;)
[10:52] <groz> if you want to really get fancy , you set up a system
[10:52] <groz> and trace it for a week, logging the trace
[10:52] <[mbm]> yeah, I had tons of fun with ltrace on the tivos when they used to have multiple executables and shared libraries
[10:52] <groz> then you compare that to all the functions in everything
[10:52] <groz> and you will be able to figure out what was never called
[10:52] <[mbm]> shortly after publishing some of that research they switched to one large executable with statically linked libraries
[10:52] <groz> it's kind of the reverse process of doing a coverage analysis
[10:53] <db90h> the API hookers in Windows I've seen are nowhere near as simple to use as you make ltrace sound.. how does it know the calling convention and number of parameters of functions though? does it have a list, or is this information specified somewhere in the symbol definitions?
[10:53] <groz> db, you assume the headers are available
[10:53] <groz> and it becomes easy
[10:53] <[mbm]> db90h: ah, it knows that because it scans /usr/include and reads in the headers from the libraries
[10:53] <db90h> oh, ok, so it builds them from that ;)
[10:54] <[mbm]> the ltrace code is a hell of a lot cleaner than the strace code
[10:54] <[mbm]> even though they both work on similar principles
[10:54] <db90h> which is a nice effect of open source software, the headers are almost always there, you don't have many proprietary modules who functions have unknown calling conventions and parameters
[10:54] <[mbm]> oh, another fun trick if you want to mess with people -
[10:55] <[mbm]> insert a breakpoint into your program
[10:55] <[mbm]> just write it into the code
[10:55] <[mbm]> you can crash debuggers that go crazy trying to figure out what caued the breakpoint
[10:56] <db90h> hehe
[10:56] <db90h> does linux ignore breakpoints if a debugger isn't attached to the process then?
[10:57] <db90h> Windows sure doesn't, int 3 is attached to an exception handler that throws an exception to the user if no other handler is there..
[10:57] <[mbm]> no, it's based on the assumption that you've written an exception handler in your program that just ignores the breakpoint
[10:57] <db90h> err, i shouldn't say int 3, that's x86 specific ;)
[10:57] <db90h> oh, ok, that makes more sense
[10:57] <[mbm]> which also means that you know explicitly if your program is being traced or not
[10:57] <[mbm]> based on if your exception handler got hit
[10:58] <db90h> i didn't know software protection mechanisms were used in OSS ;p
[10:58] <[mbm]> and if you're very evil, you can have two code paths
[10:58] <[mbm]> one that gets seen by the debugger, and one that gets seen when the program runs natively
[10:59] Action: [mbm] knows all sorts of dirty tricks
[10:59] <db90h> usually my policy is to just simply change some random thing when i find a debugger and let the fault occur way on down the line ;)
[11:00] <groz> lame, much better to have a ring 0 component in, and just tell it to wipe the hardware interrupt vector table
[11:00] <groz> much more effective
[11:00] <db90h> lol
[11:00] <db90h> much more evil ;)
[11:00] <db90h> well now i know much more about how linux works.. thanks for that
[11:00] <groz> oh, you want to have fun figuring some things out
[11:01] <groz> try this one, i had an oops once in a driver
[11:01] <groz> floppy driver
[11:01] <groz> arithmetic error in dma code
[11:01] <groz> so, it was reading the floppy, and, dma transferring that data to random location in physical ram
[11:02] <groz> i _believer_ it ended up in the disk cache data
[11:02] <groz> and then the cache flushed
[11:02] <db90h> so it wrote the read data to some random spot on disk?
[11:02] <groz> end result, a little while later, i was restoring backup tapes
[11:02] <db90h> hehe
[11:02] <groz> my whole source tree just vanished
[11:03] <groz> and then shortly after, the machine crashed hard
[11:03] <[mbm]> heh
[11:03] <groz> when it came back, there was no mbr
[11:03] <db90h> that's why you always write ring 0 code on a dedicated, expendable machine ;)
[11:03] <[mbm]> I did that just a few days ago with my new system
[11:03] <groz> the funny part was
[11:03] <groz> myu project at the time, tape backup software
[11:03] <groz> and my backup was less than 3 hours old
[11:03] <groz> but
[11:03] <groz> the ONLY copy of the program i had to restore the tape
[11:03] <groz> was on the wiped drive
[11:04] <groz> i had to go get a copy of the installer from a recent beta release
[11:04] <groz> from one of my beta sites
[11:04] <groz> to be able to restore the tapes
[11:04] <[mbm]> turns out that the 'amd cool n quiet' is guarnateed to crash my kernel within 30 seconds of bootup, and in that process it compeltely invalidates the disk cache
[11:04] <[mbm]> and the end result was that it wiped out several key files on the disk
[11:04] <[mbm]> in this case I logged in and my motd had been replaced my a mimecap
[11:05] <db90h> i believe crashing your kernel is technically making your computer cool 'n quiet ;)
[11:05] <[mbm]> and the sql server was complaining that the databases were trashed
[11:05] <db90h> hehe
[11:06] <[mbm]> some weird interaction between the cooln quiet and the kernel's power management .. it's documented on several linux forums
[11:06] <[mbm]> annoying as hell though
[11:06] <db90h> i haven't had any such accidents in a while, haven't done any NT device driver development in a long time.. but it seems every driver I develop I have to go through about 100 BSODs before it's ready for prime time ;)
[11:06] <[mbm]> especially since I was playing with the bios trying to nail down the faulty ram timings when I discovered it
[11:07] <[mbm]> (brand new system and it was running unstable because it didn't like the ram I bought it :P)
[11:08] <db90h> my current system is doing almost random hard-freezes for some reason.. I think it's related to the video adaptor, but i don't know more.. been trying to track it down forever
[11:08] <[mbm]> db90h: you need to do a better job of planning before you actually write the code :)
[11:08] <db90h> oh, i thought writing code was planning ;)
[11:09] Action: [mbm] used to have fun at the university, you'd see all the first year students sit down and spend 4 hours writing code, not once even attempting to compile it
[11:09] <[mbm]> and then once written they would yell for help because they had 80 pages of error messages attempting to compile it
[11:09] <[mbm]> and once all those were fixed they'd find the logic was faulty
[11:10] <db90h> hehehe
[11:10] <db90h> they will learn better quickly ;)
[11:11] <[mbm]> several of them learned they didn't like cs and switched to cis or buisness
[11:11] <db90h> the CS students at my university were 70% totally incompetent even as seniors..dunno if that's a norm in the undustry or what
[11:11] <db90h> of course, i went to a lame university
[11:11] <[mbm]> depends on where you go
[11:11] <[mbm]> for a small university or one that doesn't specialize in cs that's prefectly normal
[11:12] <[mbm]> and even gets into the 99% really don't have a clue even after they've graduated
[11:12] <[mbm]> if you go to one of the expensive technical universities it's a compeltely different story
[11:12] <groz> that's a high level of competence compared to average it department at <insert big corp name here>
[11:12] <db90h> if I were hiring people, I don't think i'd give much thought to a degree or resume.. they prove so little in the end
[11:13] <[mbm]> that's why most interviwers will ask you programming questions or logic puzzles
[11:13] <[mbm]> microsoft and google are famous for giving logic puzzles
[11:14] <db90h> i had this one instructor who told a story of a interview he had at Microsoft (for a job).. they asked him to write a bubble sort algorithm (or something like that) on the spot... he said to them "I have a masters degree! I'm not writing any bubble sort!" and walked out... I thought to myself, yea right, he probably was afraid he couldn't do it ;)
[11:14] <[mbm]> if you ever apply to a job and nobody asks you any technical questions, RUN!
[11:15] <[mbm]> there's only two reasons why that will happen: 1) they're totally incompetent and don't have anythig good to ask
[11:15] <[mbm]> or 2) you're famous and they don't need to ask
[11:15] <[mbm]> chances are it's 1
[11:15] <db90h> the times i've got a coding job, i use my web site as a resume .. i say, 'just go here..' ;)
[11:16] <[mbm]> I've always been asked programming questions
[11:17] <[mbm]> stuff like "here is a singly linked list, each node points to the next node and the last node points to a null; what's the most efficient way to get the 10th item from the end?"
[11:18] <db90h> i like how it defines a singly linked list in the question ;p
[11:18] <db90h> well, i guess they could be structured differently, maybe
[11:19] <[mbm]> right, the goal is to keep you from pestering them about the structure of the list
[11:19] <groz> hmm, i've rarely been asked technical questions, but, often spend a lot of time on 'architectural' discussion
[11:19] <groz> i've NEVER had anybody ask specific programming questins
[11:19] <[mbm]> groz: yeah, I get that too
[11:19] <groz> wait, not ture
[11:19] <groz> once, way way back
[11:19] <groz> i was asked a few asm technical questions
[11:19] <[mbm]> depends on where you apply
[11:19] <[mbm]> and what you'll be doing
[11:20] <db90h> is there a more efficient way than iterating through the list, recording the pointer to NODE-10 (after you've reached +10 nodes or more), then emitting that pointer when you've reached the end?
[11:21] <groz> mbm, depends how big that list is
[11:21] <db90h> i need to go get a job, but i have not liked any programming job i've had.. i get to where i don't like programming anymore
[11:21] <[mbm]> db90h: I came up with two solutions, one terribly unoptimized recursive one that walked through the list and then went 10 back in the stack
[11:21] <[mbm]> and another one that had a 10 item circular buffer
[11:22] <[mbm]> and would walk through the list once, writing every node to the buffer
[11:22] <[mbm]> and then return the oldest item in the buffer
[11:22] <db90h> ah, yes, you would have to use a stack or something to track NODE-10
[11:22] <groz> see, you guys do it the hard way
[11:22] <groz> i'd write the problem down, then hand it to the jr programmers, tell em to bring me back a solution
[11:23] <[mbm]> the recursion one impressed them just because I was able to give a working example without much thought
[11:23] <[mbm]> apparently most people have real issues trying to mentally keep track of recursion
[11:24] <[mbm]> but doing it that way eats up tons of stack space
[11:24] <db90h> i haven't really been through any interviews, everyone who has hired me really knew of me already.. but i had one employer who told me about his interview process. He said the most important thing was if someone didn't know how to solve a problem, they were humble enough to ask for aid (which he made avaialble before-hand)
[11:25] <[mbm]> oh .. there's one more (evil) way to solve the above problem
[11:25] <[mbm]> and that's using xor
[11:26] <[mbm]> you can make a singly linked list into a doubly linked list
[11:26] <Bartman007> lol, that's great
[11:26] <db90h> xor each pointer by the next, then u can re-traverse by reversing the xor
[11:26] <Bartman007> I always love solutions that effectively rewrite the problem =)
[11:26] <[mbm]> the trick is that the pointer is "previous item xor next item"
[11:26] <[mbm]> right
[11:26] <db90h> that's brilliant ;)
[11:27] <[mbm]> it's assumed that you either know the previous or next node
[11:27] <db90h> i would have never thought of that on the spot, it came to me when u said xor, but it's very creative
[11:27] <groz> guess they ddin't specify you were not allowed to damage the list
[11:27] <db90h> you just need one xor variable, don't you?
[11:28] <[mbm]> you'd overwrite the existing pointers
[11:30] Action: [mbm] loves evil programming tricks
[11:30] Action: groz thinks mbm has not yet had to deploy stuff into the real world, and take over maintanence on project written by kids that love evil tricks
[11:30] <db90h> hehe
[11:31] <[mbm]> groz: heh, I know enough to document my evil hacks
[11:31] <[mbm]> now, depending on how much I like you, I may or may not give you that documentation when I give you the sources
[11:31] <Bartman007> but the source is the documentation :-P
[11:31] <groz> well a lot of my recent work is moving to stuff where evil hacks not permitted
[11:32] <groz> everything must be verifiable
[11:32] <[mbm]> Bartman007: heh, if you say so
[11:32] <groz> and eventually ends up certified
[11:32] <[mbm]> groz: fips?
[11:32] <db90h> lol, self-docuemnting source code.. that is an OSS mantra it seems ;)
[11:32] <groz> do-178
[11:32] <[mbm]> ah
[11:32] <Bartman007> [mbm]: it's the documentation for at least a few hours... then you forget wtf each bit does.
[11:32] <[mbm]> Bartman007: exactly
[11:33] <groz> take any byte in the executeble, show what line of code generated it, and, then what line in the spec requires it
[11:33] <groz> and then prove it's not a safety issue
[11:33] <db90h> what i find annoying is when people don't record rationale for doing non-obvious things... that is the #1 thing required for good project maintenance
[11:33] <groz> db90, ever looked inside microsoft produced vga video drivers
[11:34] <db90h> nope
[11:34] <groz> they compile code on the stack on the fly, then execute it
[11:34] <groz> that's the main reason why it was such a big deal for windows to deal with nx
[11:34] <groz> cuz windows is full of self modifyng crap like that
[11:34] <db90h> hehe, that's a virus trick ;)
[11:34] <groz> it's a performance trick
[11:34] <groz> it's faster to generate and execute highly optimized blit code, than to run general purpose
[11:34] <db90h> with DEP that isn't so valid anymore..
[11:35] <groz> in 99% of cases
[11:35] <db90h> i mean, execute protection on non-executable pages.. whatever u linux guys call it
[11:35] <db90h> course you can just modify the page permissions
[11:36] <[mbm]> one of my friends has this great approach to writing code - don't try to be creative and nest loops and get all of your code indented 40 characters, the code should be written so the single intented code is the normal case and anything indented more than that is an error condition
[11:36] <db90h> sounds kinda unreadable to me ;p
[11:36] <[mbm]> which makes it very trivial to visually scan over a function
[11:36] <Bartman007> [mbm]: ow...
[11:36] <db90h> i use identation for every branch and loop
[11:37] <db90h> err conditional branch
[11:37] <Bartman007> I take it he doesn't write python?
[11:37] <[mbm]> well, I didn't mean it like that
[11:37] <[mbm]> the code is properly indented
[11:37] <db90h> oh, ok ;)
[11:37] <db90h> i thought u meant no identation except error conditions
[11:37] <db90h> that does make more sense
[11:38] <[mbm]> but the code is written in such a way that usually when you see an indented section of code it's because it's part of an error handler
[11:39] <Bartman007> ouch, my computer doesn't play playing flash video while buildroot-ng is compiling, and I'm folding in the background...
[11:40] <[mbm]> http://svn.mythtv.org/svn/trunk/mythtv/libs/libmythtv/hdhomerun/hdhomerun_discover.c .. not the best example but it illustrates what I mean
[11:40] <[mbm]> look at what parts of the code are indented
[11:44] <[mbm]> (see what I mean?)
[11:49] <Bartman007> [mbm]: that's fairly cool, though it does take some getting used to
[11:49] <groz> give it 5 years to 'grow'
[11:49] <groz> it wont look so pretty anymore
[11:53] <[mbm]> it really just means two things - write conditionals only to handle exceptions, and use functions rather than indenting the code further
[12:00] <groz> in years gone past, i woulda argued about stack growth etc, but, a good compiler will actually end up inlining it all anyways
[12:00] <groz> so it makes sense to write it maintainable
[12:09] <groz> mbm, philisophical question for you
[12:09] <groz> example, package iptables, includes firewall scripts etc
[12:10] <groz> i'd like to break it into 2 pacakges, one, iptables, just iptables, second, firewall scripts, dependant on iptables
[12:10] <groz> so it's possible to get iptables on a box, but, not drag along the default firewall setup
[12:11] <[mbm]> think the firewall script is currently part of base-files
[12:11] <groz> i think it doesn't end up in there if you dont put in iptables
[12:11] <[mbm]> but yeah, I can see what you're getting at
[12:11] <groz> so it must be part of iptables
[12:11] <groz> so an openwrt example image, would include firewall
[12:11] <groz> that'll drag along iptables
[12:12] <groz> but, it's a pain to have to delete that firewall script
[12:12] <[mbm]> really my only concern is package management overhead
[12:12] <groz> well, it goes in the same makefile
[12:12] <groz> just 2 packages from the same makefile
[12:12] <[mbm]> .. will you let me explain? ...
[12:12] Action: groz waits
[12:13] <[mbm]> if you were to go to the extreme and put every file into a new ippk, then you _will_ have overhead
[12:13] <[mbm]> because of the ipkg databases being meintained on the router
[12:13] <[mbm]> which store things like the name, version, description of each package and the list of files installed by that package
[12:14] <[mbm]> so it's ideal to beak things down into as few packages as required
[12:15] <[mbm]> even if it only saves you a few k for each ipkg
[12:15] <[mbm]> ...
[12:15] <groz> well the current iptables scripts that come along, _assume_ its going on a masquerading router
[12:16] <[mbm]> yeah I know
[12:17] <[mbm]> and really I don't care if the firewall gets moved to another ipkg
[12:17] <groz> i just finished building one called _mypolicies_ made it dependant on iptables, and put 'rm -f /etc/init.d/S45firewall' into it's preinst
[12:17] <[mbm]> just don't go overboard with creating new ipkgs
[12:17] <groz> no, this is a case, of a very defined 'function group'
[12:17] <[mbm]> right
[12:17] <groz> the firewall is a unique function
[12:17] <[mbm]> ...
[12:18] <groz> i'm actually looking at all the iptables modules groups, wondering if there's to many of them
[12:18] <[mbm]> well, that's the other side of packages
[12:18] <groz> yep
[12:20] <groz> this knife has 2 edges
[12:20] <[mbm]> if I install a package, I want it to only install what I've asked for
[12:20] <[mbm]> and not to install everything
[12:20] <groz> and they are both sharp
[12:20] <[mbm]> yep.
[12:20] <groz> been wondering about some sort of functional heirarchy
[12:20] <groz> for package displays
[12:20] <groz> ie, ipkg list
[12:20] <groz> is kinda huge
[12:20] <groz> and alphabetical
[12:20] <[mbm]> and as I said, I really don't care exactly where the edge is, just as long as it's somewhat reasonable
[12:20] <[mbm]> (so you really don't need to waste time trying to sell me on the idea)
[12:20] <groz> i'm not trying
[12:20] <groz> i'm just contemplating whats reasonable, and this one is
[12:20] <[mbm]> well, you did explain it a few times above
[12:20] <groz> but i dont really wanna end up in a pissing match after the fact
[12:21] <[mbm]> heh
[12:22] <[mbm]> usually works like this: give me some vauge idea what you're planning and I'll either drag you into the details or say "whatever" and let you do it
[12:22] <groz> you know what would be cool, a 'netboot' option in lilo
[12:22] Action: groz gonna go see if i can co-erce lilo to chain a netboot rom image
[12:23] <[mbm]> how would that work?
[12:23] <groz> lilo loads a netboot rom image, executes it
[12:23] <groz> and it netboots a kernel, instead of a local one
[12:23] <groz> cuz th ebios on this thing is to brain dead to let me configure it as optional
[12:23] <groz> it's on or off
[12:23] <[mbm]> well, it wouldn't exactly be a netboot if lilo loaded it off the drive
[12:23] <groz> well, i want to test a kernel
[12:23] <[mbm]> and as far as I know that's all lilo will do
[12:23] <groz> without actually flashing it
[12:24] <groz> but just a once off
[12:24] <groz> lilo will chain load a dos setup
[12:24] <groz> and i've got setups where a netboot runs from a dos boot disk
[12:24] <groz> I'll try that
[12:25] <groz> just put a dos boot disk image in there, that actually has a netboot exe in as command.com
[12:26] <groz> just a pain to switch this board back and forth, it's not on the kvm anymore
[16:02] <dbcch> if i want to temporarily quit using the target/ patches and instead work on a static firmware source, what would be the most proper way to modify the makefiles to handle this/?
[16:08] <nbd> why do you want to do this?
[16:09] <dbcch> because it'll be more convienent when i am messing around on the source tree
[16:10] <nbd> you can change things in build_mipsel/linux/
[16:10] <dbcch> thanks
[16:11] <nbd> maybe you'll have to delete vmlinux and stamp files
[16:12] <dbcch> ok
[16:13] <dbcch> do you guys always generate those target/ style patches manually?
[16:14] <nbd> i do it like this:
[16:14] <nbd> i run make target/linux-{clean,prepare} to have an openwrt-patched kernel tree
[16:14] <nbd> i copy that to build_mipsel/linux.dev and linux.old
[16:15] <nbd> then i hack around in linux.dev and copy changed files to linux/
[16:15] <nbd> if i do hacks for debugging, then i put those in linux/ directly
[16:15] <nbd> when i'm done, i diff linux.dev and linux.old
[16:15] <nbd> and have a clean patch
[16:16] <dbcch> makes sense
[16:16] <nbd> maybe i'll write a few scripts to automate parts of this process, but for me it's fast enough
[16:17] <dbcch> mirabilis says freewrt has some automated generation of thoes patches now, tho the style of the build root isn't the same as openwrt anymore
[16:17] <nbd> their scripts generate one patch per file
[16:18] <nbd> which i don't like at all
[16:18] <dbcch> that's a lot more patch files no doubt ;)
[16:18] <nbd> because there's no separation between logical changes
[16:18] <nbd> which is very important to me
[16:18] <dbcch> yea, i see your point
[16:18] <dbcch> with openwrt, u have patche sets in one file that add X or remove Y
[16:18] <nbd> exactly
[16:20] <dbcch> so you have been keeping up with the freewrt changes?
[16:20] <nbd> parts
[16:20] <nbd> there is not much for us to keep up with imho
[16:21] <dbcch> i haven't looked at it in a while, may check it out again whenever they finish totally overhauling the build root
[16:22] <nbd> all the overhaul that i can see in their buildroot is a few added scripts and a few variable name changes
[16:22] <dbcch> i thought i saw in one of the recent digests about a whole new directory structure, but maybe i misread, i just glanced at it
[16:23] <nbd> they were talking about a few changes, most of which only requires changing the variable name in rules.mk
[16:23] <dbcch> oh, ok
[16:23] <nbd> and it's not entirely different, just a few small changes
[16:24] <nbd> nothing comparable to buildroot-ng
[16:45] <CIA-17> nbd * r4608 /branches/buildroot-ng/openwrt/package/base-files/default/lib/network/config.sh: fix typo
[16:59] <CIA-17> nbd * r4609 /branches/buildroot-ng/openwrt/target/linux/aruba-2.6/config: enable ipip for aruba
[17:00] <CIA-17> nbd * r4610 /branches/buildroot-ng/openwrt/target/image/aruba/Makefile: don't pad aruba images - unnecessary with the jffs2 hack
[18:55] <nbd> [mbm]: btw. i'm working on merging the umts support into whiterussian and buildroot-ng now
[18:55] <nbd> [mbm]: (i have access to some test hardware now)
[19:14] <nbd> [mbm]: ping
[23:39] <db90h> unless I'm mis-perceiving things, CIFS seems to be caching file system data on shares (it ought to).. how can I force this read cache to be flushed?
[23:40] <db90h> i guess remount until i know a better way
[00:00] --- Sun Aug 20 2006