OpenWrt

[00:16] <BrainSlayer2> @florian: my one uses cfe too. my main problem now is the ethernet driver
[01:01] <groz> mbm, ping
[01:09] <[mbm]> ?
[01:09] <groz> figured out why pivot_root wasn't working from the initramfs
[01:10] <groz> you are supposed to use switch_root from there
[01:10] <groz> not pivot
[01:11] <groz> gonna have a 2.6 setup going with this now shortly, but, there's a bit of a gotcha
[01:11] <groz> you gotta load a bunch of modules to mount your media
[01:11] <groz> before yuou run rcS
[01:12] <groz> if you leave init as it stands, what happens, you end up not reading the files out of /etc/init.d on your media, but, from the ramdisk
[01:12] <groz> and any init scripts you put on the media, are never run
[01:19] <[mbm]> sounds like all you need to do is patch firstboot and mount_root then let the preinit scripts handle it
[01:20] <groz> cept, firstboot isn't included in the x86 stuff
[01:21] <groz> and it blindly copies the init from generic-2.6 in
[01:21] <groz> that'sd where the changes need to be
[01:21] <groz> in the init
[01:21] <groz> but the changes will be board specific
[01:21] <groz> because different boards will have different media in different locations
[01:23] <groz> i'll get this one going here, then work out a more generic way of doing it
[01:23] <[mbm]> it's really sounding like we need to use preinit
[01:23] <groz> well, i've got an idea cooking
[01:23] <groz> that's neatly modular
[01:23] <groz> i wanna try it out, but, what i'm thinking is this
[01:24] <groz> init as it sits, wont do, but
[01:24] <groz> it can check a command parameter, and continue on like it does now
[01:24] <groz> for a 'no mount' boot
[01:24] <groz> and then, i'm thinking, we can add board specific packages to provide board support for booting various configs
[01:24] <[mbm]> ...
[01:24] <groz> and init calls a board support script
[01:25] <groz> which comes in when you include that board support in menuconfig
[01:25] <[mbm]> you haven't looked at the preinit stuff have you?
[01:25] <groz> well, not sure what you mean, if you use initramfs on x86
[01:25] <groz> it blindly copies in an init script that just runs busybox init
[01:25] <groz> and once rcS runs, it's to late
[01:26] <[mbm]> take a close look at how preinit works on the broadcom platforms
[01:26] <groz> you are running from the initrramfs, not the media
[01:26] <[mbm]> since the answer to your problem is very similar
[01:28] <groz> yah, same concept
[01:29] <groz> basically boils down to including arch specific stuff prior to execing init
[01:29] <groz> and that's the concept
[01:31] <[mbm]> I just don't want to see a solution that only gets used for x86
[01:32] <groz> heh, and that's different from a broacom specific solution how ?
[01:32] <groz> but my thoughts were to end up with something that's generic across the board
[01:33] <groz> and it can inline a board support package, irrelavent of what kind of board it is
[01:33] <[mbm]> well, point out what part of the existing pretinit is specific to broadcom :P
[01:33] <[mbm]> it really is modular
[01:34] <groz> well, the first part is, its all living in brcm-2.4
[01:34] <[mbm]> look at the actual code
[01:35] <groz> but i'm gonna move a bunch of it once i've got the switch_root stuff actually figured
[01:35] <groz> and see if it belongs in generic with a few tweaks
[01:37] <groz> the other minor change, it'll need to run a variant of load_modules, but that will be 2.6 initramfs specific, not arch specific
[01:37] <groz> so that we can get drivers in, and mounts done
[01:38] <groz> then perish the thought, we'll end up using initramfs like the mainline guys figured it would be used :)
[02:00] <CIA-17> nico * r4586 /branches/buildroot-ng/openwrt/package/busybox/patches/001-wget_long_options.patch: fix wget long options bug (closes: #682)
[03:07] <CIA-17> nico * r4587 /packages/net/mini_httpd/Makefile: fix mini_httpd, standardize
[03:18] <CIA-17> nico * r4588 /branches/buildroot-ng/openwrt/include/kernel-build.mk: cosmetic coherency fix
[03:23] <groz> mbm, ok, hows this for generalized
[03:23] <groz> init, basically whats in the brcm preinit
[03:23] <groz> but, added a call for load_modules to load any modules in the ramfs
[03:24] <groz> then mount_root if failsafe true, fall thru as per what it was doing
[03:24] <groz> but if there is a root= parameter
[03:24] <groz> we mount that one, and switch_root to it
[03:24] <groz> BUT, there's a kicker here, if you load the usb modules
[03:24] <groz> it can take some time before the stick is actually mountable
[03:25] <groz> so, i'm thinking the mount of the stick will loop for a little bit if it fails, after 10 failures, falls thru without the mount
[03:25] <groz> if it succeeds suring the 10 tries, proceed on that root
[03:25] <groz> the only x86 specific thing then is the boot loader, and kernel command parameters via the loader
[03:26] <groz> and failsafe parameter or failure to mount the stick
[03:26] <groz> takes you on thru running from the initramfs
[03:26] <[mbm]> use the hotplug system to know when usb is ready
[03:27] <groz> either way, it'll have to time out, and fall thru to failsafe
[03:27] <groz> if the stick doesn't become ready
[03:27] <[mbm]> right
[03:28] <groz> and if we are using hotplug, then
[03:28] <groz> we need smarts in the scripts to tell what we are waiting on
[03:28] <[mbm]> I also don't see why you're passing root= if you can just probe and switch_root to whatever
[03:28] <groz> whereas, if we trigger on a failed mount, all we need is a command param saying what mount we are waiting on
[03:28] <groz> well, there may be more than one option if you probe
[03:29] <groz> could be 2 sticks in the box
[03:29] <groz> or maybe a stick and a spinning hd
[03:29] <[mbm]> we're talking lilo here so it's not like you'd get a chance to interact with the loader to set root=
[03:30] <groz> 4 stanzas in lilo, and a boot menu on the serial console
[03:30] <groz> maybe it's a partitioned stick, with 4 partitions
[03:30] <groz> and you are choosing which one you want
[03:31] <groz> trying to find the way that will _always_ work here
[03:31] <groz> not specific to the box on my desk
[03:32] <[mbm]> so it's a partitioned stick now?
[03:32] <groz> i have a pile of sticks here
[03:32] <groz> some are partitioned, others are not
[03:33] <groz> my preferred route to deploy is without
[03:33] <[mbm]> I just remember having this argument a day or so ago
[03:33] <groz> but my point is, create an initramfs setup that works in all cases for initramfs
[03:34] <groz> the only thing that becomes box specific then, is the actual mount point
[03:36] <[mbm]> ok
[03:36] <[mbm]> next question - if we had the broadcom boards pass a root= line, would that help?
[03:36] <groz> the assumption is, modules required to access the mount point are included in initramfs
[03:37] <groz> well in the brcm side, there's already a fair amount of broadcom specific stuff, which queries mounts for the existance of jffs
[03:37] <groz> so i went with the one in base-files/default
[03:37] <groz> for the mount_root
[03:37] <groz> the only real change needed there then is this
[03:38] <[mbm]> it really isn't a spcific as you seem to think
[03:38] <groz> it terminates now with a mount of /dev/root on /
[03:38] <groz> ok, i'ts specific to jffs
[03:38] <groz> but the mount_root in base/default doesn't have that
[03:38] <groz> so, if we work up a complete general case solution around the final mount
[03:38] <groz> it'll work on anything
[03:39] <[mbm]> that's why I was asking about the root= line
[03:39] <groz> well, a root= param will work just about anywhere wont it ?
[03:39] <[mbm]> yep
[03:40] <groz> and, we could use preinit.arch
[03:40] <groz> to include a file with a default
[03:40] <groz> so, for something like the brcm where it's never gonna change
[03:40] <groz> set it in the arch file, be done with it
[03:40] <[mbm]> my only other question would be how much space this is all going to eat
[03:40] <groz> brcm build uses preinit.arch to set it
[03:40] <groz> about 20 lines in the scripts
[03:41] <groz> over what's already there
[03:41] <groz> if that
[03:41] <groz> as far as run time footprint, it reduces it
[03:41] <[mbm]> souns good
[03:41] <groz> because when you switch_root
[03:41] <groz> you free rootfs
[03:41] <groz> and then, on a board that doesn't have a flash map
[03:41] <groz> you just dont give it a mount point
[03:42] <groz> it runs from initramfs
[03:42] <groz> the lack of a mount point in the command line, implies stay in the initramfs
[03:42] <[mbm]> well, don't forget that initramfs loads much slower than squashfs and is larger
[03:42] <groz> well, in that case, you would be building images that are not initramfs
[03:42] <groz> it would be a squash image no ?
[03:43] <groz> and have the squash defined as it's starting point
[03:43] <[mbm]> right, but that means that the preinit script needs to handle that
[03:43] <groz> no, because this preinit scritp replaces the one for the initramfs special case
[03:43] <groz> in kernel-build.mk
[03:43] <groz> it only ever goes into initramfs
[03:44] <groz> kernel-build.mk line 59
[03:44] <[mbm]> maybe I should have clarified, above I was asking you about a general purpose case including the squashfs handoff
[03:44] <[mbm]> since I still think that's close enough to a usb handoff to share 90% of the script
[03:45] <groz> well, in this case, i grabbed the preinit out of the brcm, that triggers the handoff on brcm
[03:45] <groz> and basically added load modules and mount devfs to it
[03:45] <groz> it is the same script
[03:46] <[mbm]> you shouldn't need to mount devfs
[03:46] <groz> i dont have a dev populated
[03:46] <groz> using that to find the stick
[03:46] <[mbm]> it gets mounted at boot by the kernel and then you just move that around
[03:46] <groz> it's not in the mounts at that point
[03:46] <[mbm]> make sure you select the 'mount at boot' option in the kernel
[03:47] <[mbm]> oh wait .. you're right
[03:47] <groz> ya, but kernel doesn't do that, if it's going to initramfs
[03:47] <groz> it skips a bunch of stuff for initramfs
[03:47] <[mbm]> the early init happens before the mount
[03:47] <groz> it's now the task of init to set that up
[03:47] <groz> and then the kernel mount never gets called
[03:47] <[mbm]> I just remembered I hacked that into the initramfs init script
[03:47] <groz> once init takes over, it assumes full responsibility for setting up namespace
[03:48] <groz> rite
[03:48] <groz> so what we end up with is just a variant of preinit
[03:48] <groz> for use in initramfs
[03:48] <[mbm]> maybe we should just turn off the mount at boot option in the kernel and just move that to the preinit script
[03:48] <groz> 2 extra tings in it
[03:48] Action: [mbm] really likes standardizing things
[03:48] <groz> it loads modules, on the assumption you built image with enough modules to find your root device
[03:49] <[mbm]> right
[03:49] <groz> then it goes and mounts it
[03:49] <groz> all this must happen before we try exec /sbin/init
[03:49] <groz> so that any modules / scripts loaded onto the media later
[03:49] <groz> get loaded by the normal startup
[03:49] <[mbm]> obviously
[03:49] <groz> side effect
[03:49] <groz> we call load_modules twice
[03:50] <groz> once before, once after the switch_root
[03:50] <[mbm]> doesn't matter
[03:50] <groz> exactly, and for that matter
[03:50] <[mbm]> that'll just tell you 'module foo is already installed'
[03:50] <groz> on the media, you can delete those in the initramfs
[03:50] <groz> to save some space, if it matters
[03:50] <[mbm]> true
[03:50] <groz> then, my lilo kludge still works
[03:50] <groz> where i just use the same fs
[03:50] <groz> for both the initramfs, and the final root
[03:51] <groz> and that gives a full path to failsafe as well
[03:51] <[mbm]> but at that point are we better off using the initramfs on /rom like we do with squashfs?
[03:51] <groz> again, the lilo case, failsafe is a lilo stanza
[03:51] <groz> hmmm, i dunno the ramifications of leaving it around all the time
[03:52] <groz> you mean leave it on rom
[03:52] <groz> then firstboot to soft link everything ?
[03:52] <[mbm]> we don't do that anymore
[03:52] <[mbm]> we now have mini_fo to do an overlay
[03:52] <groz> hehe, unless you turn off mini_fo in the menuconfig
[03:52] <groz> :)
[03:52] <[mbm]> so basically you have /rom with squashfs and /jffs as an empty directory
[03:52] <[mbm]> and / is the combination of the two
[03:53] <groz> rite
[03:53] <groz> ok, now, here's the question then
[03:53] <[mbm]> we could easily pull the same trick with initramfs
[03:53] <groz> on a tight memory/flash constrained device, that works well
[03:53] <groz> but here's the drawback
[03:53] <groz> initramfs not compressed
[03:53] <groz> so to do that, an initrd would be much better
[03:53] <[mbm]> right, it eats memory
[03:54] <groz> and, every time you write something to initramfs, on purpose, or by accident
[03:54] <groz> it eats more
[03:54] <groz> and it NEVER frees it
[03:54] <groz> unless you delte the files
[03:54] <[mbm]> ok, if you want to go down this path .. why even have an initial ramdisk? you could just amke it boot the usb directly
[03:54] <groz> initramfs is simply files mapped into virtual space
[03:54] <groz> i do boot the usb, then, i need the initramfs, to load the linux modules for the usb
[03:55] <groz> to get back at it
[03:55] <groz> if you dont have the modules compiled in
[03:55] <groz> you need to load them
[03:55] <[mbm]> that's just it though
[03:55] <groz> i could bypass all of this trivially by simply compiling usb storage into the kernel
[03:55] <groz> but that defeats the generalized solution
[03:55] <[mbm]> compiling the modules into the kernel is much simpler and effective then the initramfs
[03:56] <groz> now if you are using x86 on a device that doesn't have usb, say something with cf mapped as hda
[03:56] <groz> you got the usb storage stuff hard wirede in
[03:56] <[mbm]> could be a compile time option
[03:56] <groz> and, the question then, do we hard wire all block devices that could possibly be used to boot ?
[03:57] <groz> but, if we go this route, the normal kmod selection gets you the modules
[03:57] <[mbm]> I'm just trying to see if there actually is an advantage to a general solution
[03:57] <groz> initramfs exists only to get started
[03:57] <groz> and then it's freed and gone
[03:57] <groz> also consider this
[03:57] <groz> x86
[03:57] <groz> not a lot of x86 boxes with tiny ram and tiny disk space
[03:57] <groz> so, in this scenario, burning a little ram/flash space
[03:57] <groz> no biggie
[03:58] <[mbm]> initramfs = slower boot, larger footprint vs just compiling support for the root fs in the kernel
[03:58] <[mbm]> sure we could do the extra complexity, but you need to make a compelling argument for it
[03:58] <groz> well just going to the kernel config, and turning on all block devices
[03:58] <groz> makes it trivial
[03:58] <groz> but, down the road
[03:59] <groz> are you envisioning this being a host platform for 'routers only' ?
[03:59] <[mbm]> nope
[03:59] <groz> or, larger more complex embedded devices ?
[03:59] <groz> do we include lvm and raid too
[03:59] <groz> cuz i certainly see the benefit to using buildroot-ng as a basis for creating firmware for a nas device
[03:59] <groz> which could get all sorts of fancy scsi etc
[04:00] <groz> so i like the modular approach myself
[04:00] <groz> it's way more flexible in the long run
[04:00] <groz> add a few kmods, and bingo, just works on stuff
[04:00] <[mbm]> well, you said it yourself, the initramfs will need all the modules required to access the root filesystem on the ramdisk
[04:00] <groz> yes, but
[04:00] <groz> only for the hardware in question
[04:00] <[mbm]> which means that at some point we're maintaining a list or allowing the user to select them
[04:00] <[mbm]> that doesn't change if you put them directly into the kernel
[04:00] <groz> well, in menuconfig
[04:00] <groz> we already have that
[04:01] <groz> but and when they <*> vs <M> they are in the initramfs
[04:01] <[mbm]> well, we have the option to compile the ipkg
[04:01] <[mbm]> the usage is similar though
[04:02] <groz> what it really boils down to then, is initramfs useful at all, or, should we just hard wire an x86 kernel with EVERYTHING
[04:02] <groz> and call it done
[04:02] <[mbm]> I'm saying what if we actually had the option to influence the kernel config
[04:02] <[mbm]> well, doesn't need to be EVERYTHING .. I'm sure they can load sound support as a module
[04:02] <groz> ok, so if we set up so that <*> actually changes kernel/config to y instead of m
[04:03] <[mbm]> all that needs to be there is enough to mount root
[04:03] <groz> but, if we stick with all modular
[04:03] <groz> it migrates better to an image builder
[04:03] <groz> example, i have one build tree, one kernel config
[04:03] <groz> and thru image building
[04:03] <[mbm]> what concerns me is how painfully slow initramfs is
[04:03] <groz> i include different things in different images
[04:04] <groz> i think it's only a concern if you are really worried about device boot time
[04:04] <groz> measured in sub second time intervals
[04:04] <groz> example
[04:04] <groz> my via booting from usb
[04:04] <[mbm]> it's basically the same as doing: mount / -o tmpfs; gzip -dc initramfs.cpio.gz | cpio -id
[04:04] <groz> takes about 15 to 20 seconds to load kernel off usb, and another 3 seconds to get to showing prompt
[04:04] <groz> it boots fast, takes forever to load kernel off the media thru painfully slow bios calls
[04:05] <groz> and once its up, neither flash nor memory footprints are an issue
[04:05] <[mbm]> I'm just thinking that one application will be routing where the downtime is critical
[04:05] <groz> cheap computer, cheapest memory stick i could get, 512 megs
[04:06] <groz> yah, on a downtime critical router, we wouldn't be booting from a usb stick
[04:06] <groz> it would have faster media
[04:06] <[mbm]> right, but we wouldn't want to have the initramfs overhead as part of a generalized booting solution
[04:06] <groz> and you do then have the option to not select initramfs
[04:06] <groz> in menuconfig
[04:06] <groz> again, this implies you have selected initramfs in menuconfig to begin with
[04:07] <groz> as your choice of image/boot style
[04:07] <[mbm]> I'm just trying to see the use case for initramfs
[04:07] <groz> oh, here's the case
[04:07] <[mbm]> when I hacked it in initially, it was for network booting to test images without reflashing
[04:07] <groz> i got a via on my desk
[04:07] <groz> and i neboot it
[04:07] <[mbm]> it was never intended to handoff onto another filesystem
[04:07] <groz> and usb boot it
[04:08] <groz> for the usb boot, it's a conveniant way to get the modules required in with the kernel during the boot loader startup
[04:08] <groz> without haveing to hardwire the kernel
[04:08] <[mbm]> gasp* can't do that ... sriously, what's the hang up with putting support in the kernel?
[04:09] <groz> struck me that the goal of the whole setup with the autoload kmodule stuff etc
[04:09] <[mbm]> it's not like we're going to force you to do a distclean if you ever change the config
[04:09] <groz> was so that you din't have to be redoing kernel config all the time,
[04:10] <[mbm]> again, we're simply talking about the modules required to access root
[04:10] <groz> and it's not like you have to turn that on if you dont want it
[04:10] <groz> if you aren't going to use initramfs, it'll never affect you
[04:11] <[mbm]> well, it was a fun argument until that last cop out ..
[04:11] <groz> well, if you intend to redo kernel config all the time
[04:11] <groz> why is it even stored in the svn ?
[04:11] <[mbm]> legacy
[04:11] <groz> shouldn't it be just something local then, and not get clobbered when i svn up
[04:11] <[mbm]> that's the way we used to do it
[04:12] <groz> no, its the way it goes now, if i svn up, i get a kernel config
[04:12] <groz> and if i make clean, it gets clobbered
[04:13] <[mbm]> right, that's because it wasn't feasable to regenerate the config file
[04:13] <[mbm]> but we're getting to the point that now it is
[04:13] <[mbm]> and we even let you specify the busyxbox config
[04:14] <groz> which i already use right off, cuz, there's a few things i want in busybox that aren't in the default
[04:14] <[mbm]> so I'm thinking which makese more sense in the future? selecting what goes into the kernel or doing this whole initramfs thing?
[04:15] <groz> think farther out
[04:15] <groz> now we are dealing with some storage device that you cannot inline to the kernel
[04:15] <groz> you get a .ko from a vendor
[04:15] <groz> and you are stuck with it
[04:15] <groz> now you need the early load of modules
[04:16] <[mbm]> honestly, that's unrealistic
[04:16] <[mbm]> since it would also lock us down to one kernel and we'd have the brcm-2.4 mess all over again
[04:16] <groz> one would say that for wireless and video too
[04:16] <groz> but it's the reality out there
[04:17] <[mbm]> ok, name one example of a filesystem or block device only provided as a .ko
[04:17] <[mbm]> I mean I can see where you're going with this but it's incredibly far fetched
[04:17] <groz> i dont know one offhand, but i'm sure there are or will be some high end stuf in futrure
[04:17] <groz> for various things like fibre channel
[04:18] <[mbm]> and when there is we can talk about the intiramfs stuff again ...
[04:18] <groz> ok, i see it happening already then
[04:18] <groz> gonna have to carry my own fork on a bunch of stuff
[04:18] <groz> jsut to be able to make it do what i need
[04:18] <groz> been there, done that
[04:19] <groz> i wont botheer committing back what i've done today then
[04:19] <[mbm]> ...
[04:19] <groz> obviously you dont want it
[04:20] <[mbm]> and here I thought we were just having a fun argument over technical merits
[04:20] <groz> i'm trying to get things up and running
[04:20] <groz> and just being told it's no good, a simple question about how to propogate something in the most general manner
[04:20] <groz> results in 'we will look at ramfs again later'
[04:21] <groz> well, i've got it working, functional, just tidy up to make it useable
[04:21] <groz> and you bascially said 'dont wanna use it'
[04:21] <[mbm]> and, this fundimental misunderstanding is why there are now several openwrt forks
[04:22] <groz> yes, well, folks do get tired of being told 'dont want it'
[04:22] <[mbm]> but that's just it
[04:22] <groz> cuz it's not pure enough for your method
[04:22] <[mbm]> you're misunderstanding what we're doing here
[04:23] <[mbm]> this isn't intended as "do it my way or get lost"
[04:23] <[mbm]> this is a brainstorming "if we did it this way would it be any better?"
[04:23] <groz> well it still boils down to one of two thing
[04:23] <groz> either arch specific files
[04:23] <groz> or command lines
[04:23] <[mbm]> suer
[04:23] <[mbm]> sure
[04:23] <groz> or the third option, dont bother at all
[04:24] <[mbm]> I think what you're not grasping about this is that there doesn't have to be one solution
[04:25] <groz> there is definitely a communication problem here
[04:25] <groz> [mbm]: and when there is we can talk about the intiramfs stuff again ...
[04:25] <groz> that comment strongly implies the 'dont bother' option
[04:25] <groz> well, its to late for me to 'dont bother'
[04:25] <[mbm]> no, that implies that we'll do this talk again
[04:25] <groz> the only question for me, now that i'm using it
[04:25] <groz> is what to do with it
[04:26] <[mbm]> if I were to turn around tomorrow and put in an option to compile the usb into the kernel, you'd probably yell at me for neglecting your work on initramfs
[04:26] <[mbm]> under the assumption that it undermined your efforts
[04:27] <[mbm]> but, it goes along with what I said above that there doesn't have to be a single solution
[04:27] <groz> nope, i'd go cool, more choices
[04:27] <groz> i liek the idea of maximum flexibility
[04:27] <groz> the flexibility of -ng is why i took it up
[04:27] <groz> and why i intend to get it going with more underlying platforms
[04:28] <[mbm]> so when I asked you earlier about the other solutions it was to gauge what other posibilities we should look into
[04:28] <groz> hehe, and when i asked 'opinion' on the options
[04:28] <groz> its so i can finish the last bits of a script that 'solves a problem'
[04:28] <groz> and build/test/commit it
[04:28] <groz> so it can solve the same problem for more folk
[04:29] <[mbm]> well, yeah, we're working off two different models here .. you're trying to do something to meet a deadline and I'm trying to be the system architect
[04:29] <groz> partly, i think with a easy/turnkey x86 starupt from a boot stick, we'll see a lot of 'new interest'
[04:30] <[mbm]> sure, I never doubted that
[04:30] <groz> cuz folks can easily play without buying special hardware
[04:30] <groz> hehe, but i think we'll really come to loggerheads when my next piece is ready :)
[04:30] <groz> openwrt as a windows firewall
[04:30] Action: [mbm] needs to stop having chats on irc and actually get the developers together .. it's so hard to gauge reactions when you can't even see the response
[04:31] <groz> complete set of install scripts, buried in an msi
[04:31] <groz> which installs colinux as a service, and puts windows 'behind' it
[04:31] <[mbm]> I know that 90% of what I say is taken to be highly offensive and blasphemous
[04:31] <groz> with an openwrt type setup
[04:31] <groz> inside it
[04:32] <groz> and i know for most thats probably blasphemy
[04:32] <groz> but for me, it's a developer scratching an itch
[04:32] <groz> cuz it's going on DADS computer
[04:32] <[mbm]> but the way I actually intend it is "I know that's the typical answer, but is it the only one?" .. I want to think about different ways
[04:33] <[mbm]> part of the fun is, to use the cliche "thinking outside the box"
[04:33] <[mbm]> and you generaly need to rattle people to get them into that mindset
[04:33] <groz> no, some of us are already wayyyyy outside the box
[04:34] <groz> you dont get 2000 wrts in the field by thinking inside the box
[04:34] <[mbm]> anyways, I didn't realize you had most of the code already written
[04:34] <groz> well, honestly, i didn't, you did
[04:34] <groz> i just moved it to another directory, added a few lines
[04:35] <groz> and now, debating the last step
[04:35] <groz> ie, exactly how is the best way to 'do the mount'
[04:35] <[mbm]> well, yeah that was why I was prodding you to look at that code
[04:35] <groz> well, ya, and i did
[04:35] <groz> then i copied, here's what i've got going, for this
[04:35] <groz> i have 'gerry-basefiles' as a package, override to base files
[04:35] <groz> when it's right, netboots ok, usb boots ok
[04:36] <groz> i can migrate from my overrides into base files
[04:36] <[mbm]> we already have the initramfs target
[04:36] <groz> but, like i said, if it's a big issue to change it
[04:36] <groz> no biggie, i leave it in my override
[04:36] <groz> and i use it, nobody else
[04:36] <groz> the sticky point tho is htis
[04:36] <groz> with ramfs, it is nice, its a great 'failsafe'
[04:36] <[mbm]> yep
[04:36] <groz> the sticky part is the most general solution
[04:37] <groz> for making the switch
[04:37] <groz> that will NEVER break
[04:37] <groz> waiting on hotplug is ok
[04:37] <groz> but
[04:37] <groz> it implies puttingin code to know what you are waiting on
[04:37] <[mbm]> hmm .. now .. initrd image vs initramfs ?
[04:37] <groz> oh, i can give you a clear answer on that one
[04:37] <[mbm]> I know initrd is being obsoleted, but devfs already is and we still use that ;)
[04:37] <groz> kernel devs are going to make initrd obsolete
[04:37] <groz> lets not piss up wind
[04:38] <[mbm]> bah, that's no fun
[04:38] <[mbm]> next you'll be trying to convince me to drop the devfs patches
[04:38] <groz> well, it's easier than chasing 'whats broken in devfs' now, which still needs to be chased
[04:38] <[mbm]> see..
[04:38] <groz> no but, i like flexibility
[04:38] <groz> so, if _I_ choose to go without it
[04:39] <groz> that shouldn't mean i cant play in the big picture anymore
[04:39] <[mbm]> flexible is fun to a point
[04:39] <[mbm]> when all of the developers are off living in their own little worlds with no exposure to eachother, then you've gone too far
[04:40] <groz> well, that's my point, the initramfs done this way, may not be fastest/smallest
[04:40] <groz> but, it's the most general solution
[04:40] <groz> and, can be optimized on
[04:40] <groz> but, the top level, will 'always work'
[04:40] <[mbm]> sure, which is why I was asking if we s/initramfs/initrd/ if it'd be a better solution
[04:41] <groz> you are always just one kmod away from a given device
[04:41] <groz> personally, i'd like to see both options available
[04:41] <groz> for a stupid reason
[04:41] <groz> initramfs is soooo easy with netboot
[04:41] <[mbm]> because you're sure initrd is going to break soon?
[04:42] <groz> and then when initrd does break, i have a back door
[04:42] <[mbm]> ah, you must be thinking of the initrd format where the initrd is external to the kernel
[04:42] <[mbm]> you can actually put the image into the kernel
[04:42] <groz> well, you can do it just like initramfs
[04:42] <groz> just dont put in the init file
[04:42] <groz> and for now, it runs old initrd code
[04:43] <groz> but did yuou rmeember my mentioning netboot probs yesterday
[04:43] <groz> well, turns out it wasn't the patch
[04:43] <groz> it was the kernel not able to gzip -d the files i was building
[04:44] <[mbm]> my biggest grudge with initramfs is the implementation
[04:44] <[mbm]> it was designed for a desktop system
[04:44] <groz> well, i can live with it, cuz, it can be deleted
[04:44] <groz> but, ifyou tll me i gotta start doing udev
[04:44] <groz> then we'll have a real 'discussion'
[04:44] <groz> very one sidee
[04:44] <groz> sided
[04:45] <groz> :)
[04:45] <[mbm]> initramfs was designed to create a tmpfs, ungzip and uncpio the files into that ramdisk
[04:45] <[mbm]> now it's nice and unloads the compressed cpio
[04:46] <[mbm]> but that takes time, and if you're not careful the watchdog will fire off
[04:46] <[mbm]> plus, you now have an uncompressed filesystem eating up your ram vs something like squashfs which remains compressed and only compresses a few inodes at a time into ram
[04:46] <groz> how aggressive are you watchdogging, and on what hardware ?
[04:47] <[mbm]> about 3 seconds
[04:47] <groz> ok well, back to the top of this discussion, i never said initramfs was _good_, but, it's a short cut to some solutions
[04:47] <groz> and, especially in the x86 case, ram/space rarely an issue
[04:48] <[mbm]> sure, but let's not celebrate a global solution that uses initramfs
[04:48] <groz> on the same token, lets either 'finish it' or 'remove it' from the main option
[04:48] <groz> right now, it's lacking, and, it's just a couple scripts away from 'useable'
[04:49] <groz> and since all the preionit stuff is already there, why not just recycle it in
[04:49] <groz> but now, my dinner bell is ringing
[04:49] <[mbm]> the initramfs started as a hack for netbooting a specific board
[04:49] <[mbm]> and never pivoting to any other filesystem
[04:50] <[mbm]> I always figured that at some point I'd write a /sbin/init script that passed control over to usb
[04:51] <[mbm]> no fancy hooks in preinit or anything like that
[04:51] <groz> well the issue i ran into going that route
[04:51] <groz> rcs already has it's list read
[04:51] <[mbm]> I just knew that if I tossed a /sbin/init script on jffs2 it'd get executed
[04:51] <groz> if you dont hook before then
[04:51] <groz> scripts you've added to the usb wont get read
[04:52] <[mbm]> and I could chain squashfs:/etc/preinit -> jffs:/sbin/init -> usb:/sbin/init -> ...
[04:52] <groz> sounds like a lot of work
[04:52] <[mbm]> not really
[04:53] <groz> but see, on the flip side, consider this
[04:53] <[mbm]> I mean the only "work" is writing something like the following: #!/bin/sh; load_modules; mount_filesystem; pivot; exec /sbin/init
[04:53] <[mbm]> and the nice thing is that this can be a package
[04:53] <groz> i got a 700mhz x86 processor, with 512 meg of ram, 128 meg of flash on a stick, and i'd like to replace my main router with it
[04:53] <[mbm]> that just hooks itself into the bootup chain
[04:53] <groz> so, initramfs inefficiency is no big deal
[04:55] <[mbm]> well, if we actually wrote a script like what I just described, it would fit equally well on a initramfs
[09:25] <db90h> i don't suppose there is a branch i'm not aware of where you have started committing changes to White Russian for rc6, right? not to this point are you?
[09:26] <groz> if there is db, i'm not aware of it, i'm not working with WR
[09:26] <groz> i'm focussing on new platforms etc for ng
[09:27] <db90h> yea, i'm just curious because i'm not sure how this rc6 is going to come about.. you move appropriate NG changes to kamikaze, then will kamikaze branch, when tagged, be WR RC6?
[09:28] <groz> ng and kamikaze are the same thing now
[09:29] <db90h> so the old kamikaze build root is deprecated forever?
[09:29] <groz> not sure, just know that they both end up drawing the same thing now from svn
[09:30] <db90h> ah, that's interesting, i didn't know that.. i thought they each had distinct copies
[09:30] <db90h> i mean, of the applicable code.. of course the build systems are unique to each ;)
[09:32] <groz> i dunno for sure, i've never even extracted kamikaze
[09:35] <Bartman007> db90h: there is the WhiteRussian svn branch...
[09:38] <Kaloz> db90h: the old kamikaze (trunk) will get buildroot-ng when it's finished
[09:38] <db90h> and then kamikaze will get tagged as White Russian RC6?
[09:39] <Kaloz> db90h: rc6 will be the current whiterussian branch, if we don't find serious bugs, it will be renamed to 0.9.0
[09:39] <db90h> oh
[09:39] <Kaloz> db90h: and whiterussian 1.0 will get buildroot-ng and the updated code from for brcm-2.4 from that kamikaze
[09:39] <db90h> ok, so has work begun on updating White Russian branch for RC6?
[09:39] <Kaloz> db90h: Kamikaze itself will be OpenWrt 2.0
[09:40] <Kaloz> db90h: we need to close some tickets, other then that rc6 isn't interesting at all..
[09:40] <db90h> ah, ok, so you don't plan on adding anything from kamikaze really, just further stablizing the code
[09:40] <groz> kaloz, the real interest on the wr branch
[09:40] <groz> is a radio driver that 'actually works' :)
[09:40] <Kaloz> db90h: right for 0.9
[09:41] <Kaloz> groz: fix the new one ;)
[09:41] <groz> kaloz, get me sources
[09:41] <db90h> perhaps we can hire a bugular to break into Broadcom ;
[09:41] <db90h> err a burgular
[09:41] <db90h> hehehe
[09:42] <groz> hehe, a challenge for the black hat community
[09:42] <groz> produce the sources for broadcom wl driver
[09:42] <db90h> maybe someday that open source driver will get master mode, or whatever its lacking
[09:42] <groz> show us who is 'good'
[09:42] <Bartman007> then we would get SCO style lawsuits :-P
[09:42] <Kaloz> groz: or i have even a better suggestion
[09:42] <Kaloz> groz: update the brcm-2.6 systme code to support the 4702 4704 and 53xx as well
[09:43] <Kaloz> :P
[09:43] <Kaloz> db90h: it already has in wireless-dev
[09:43] <db90h> it has?!
[09:43] <Kaloz> db90h: just my only broadcom based devices aren't working with 2.6
[09:43] <db90h> oh ;(
[09:43] <groz> well i played with it the first time last week, just installed it, stock as ubuntu edgy puts it on the notebook
[09:44] <groz> worked ok as a client without any encryption
[09:44] <Kaloz> db90h: all of those are 4704 based :p
[09:44] <groz> i tried setting mode master, got a short blip of a crazy ssid, and that was the end of that
[09:44] <Kaloz> groz: master mode works with the devicescape stack
[09:44] <groz> then i went back to getting stuff done that I need done short term
[09:46] <Kaloz> anyways, i'm way to busy with porting to other platforms, so someone else should add the missing stuff to the brcm-2.6 kernel
[09:47] <[florian]> Kaloz: what's missing actually ?
[09:49] <Kaloz> [florian]: well, all the timing and board-related stuff.. of course, 90% of the code in 2.4 is useless, but for example 2.6 should check which cpu/soc does it running on, and adjust the system speed for that - as it has 200mhz hardcoded
[09:49] <Kaloz> [florian]: so it won't work on the 4702, and will downclock the 4704
[09:50] <Kaloz> also, for some reason the ethernet interfaces are swapped in 4704, probably something to hunt down in the 2.4 code
[09:50] <[florian]> ok, I ignored that
[09:50] <[florian]> by the way, I am almost ready with my wap54g v1.0
[09:50] <[florian]> and I have some ideas about making the image even more micro
[09:56] <db90h> what ideas florian?
[09:57] <[florian]> like tuning the kernel configuration and putting max things built-in
[09:57] <[florian]> but I wonder if the bcm43xx-dscape+hostap is not larger than the old wl binary
[09:58] <db90h> ah, ok
[09:59] <db90h> don't forget about that uclibc library pruning, if possible.. it's a big saver.. my latest plan (much like last) for hacking that in White Russian is to replace sstrip with a tool that does nothing, just returns success, then do the real sstrip on the entire file system after the library has been pruned
[10:05] <[florian]> yeah
[10:06] <Bartman007> db90h: I can't remember, how much space did that compressed Belkin CFE save?
[10:06] <[florian]> compressed CFE ? or CFE able to load compressed kernels ?
[10:06] <Bartman007> compressed CFE
[10:07] <[florian]> interesting
[10:07] <Bartman007> db90h mentioned a few weeks back that he had run across it in one of Belkin's GPL tarballs
[10:07] <[florian]> I am wondering if this could be possible :
[10:07] <db90h> 128KB
[10:08] <[florian]> half size approx ?
[10:08] <Bartman007> that's what I remembered...
[10:08] <db90h> if switching to LZMA and with a couple trims, it might be possible to get it down to 64KB
[10:08] <db90h> yes, the actual size of the compressed CFE 113KB
[10:09] <Bartman007> heh, that releases a _lot_ of space on 2MB devices
[10:10] <[florian]> if the device is not crashing (or using a kind of kexec hack), it could be possible to erase the CFE/pmon partition and remap the root partition to use this space, and rewrite the bootloader when rebooting/halting
[10:10] <db90h> i figured a way to take an existing CFE and compress it and append the decompression stub using the CFE's build system, but there's one little thing to overcome..
[10:11] <[florian]> it *justs* highly increase the chances you brick your router :)
[10:11] <db90h> perhaps you guys could help.. all that needs to be done is take an existing CFE.BIN and make it back into an ELF .. I can provide the ELF the CFE build emits as an intermediate file, if desired.. it's basically one big code section and a small data section
[10:12] <db90h> as far as getting build's of the CFE from source to work, this has been done on a WRT54Gv1, but no other boxes yet.. currently there is talk of switching to the CFE sources in the ASUS tarballs, as these are apparently newer
[10:12] <Kaloz> db90h: if you have time
[10:12] <db90h> or, rather, the platform drivers in it are newer
[10:12] <Kaloz> db90h: i've found an u-boot port for the 4702 - probably usable with the newer stuff as well after some modifications
[10:13] <[florian]> you can find several CFE.BIN here : http://downloads.openwrt.org/people/inh/cfe/
[10:13] <db90h> Kalox: I'd very much like to see that ;)
[10:13] <Kaloz> db90h: hold on, it was inside a gpl tarball
[10:13] <Bartman007> u-boot for the 4702? that's interesting
[10:14] <groz> that's VERY interesting
[10:14] <groz> kaloz, did you say the other nite that uboot is acceptable on pc too ?
[10:14] <groz> i've never looked at it, but, if it'll work on a pc, i wannt take a peek at it
[10:14] <groz> shortly
[10:15] <Kaloz> it should work. to be honest i'm still panning to make an openwrt desktop target with that :P
[10:15] <db90h> [florian]: as far as converting the CFE.BIN to an ELF, I have all the CFEs in the world, the issue is how to use binutils (or a custom tool) to transform the CFE back into an ELF.. shouldn't be hard.. in fact, should be easy, but I haven't had a chance to look into it deeper
[10:16] <groz> an openwrt desktop ??
[10:16] <db90h> by doing this, then the stuff in the CFE build that converts the output to a compressed CFE image will be usable with any pre-built CFE image..
[10:16] <Kaloz> groz: yeah
[10:16] <groz> you mean build x etc against uclibc
[10:16] <groz> and one monster large set of packages ?
[10:16] <db90h> I'd much rather use UBoot tho, for many reasons, including the fact that I can legally redistribute it;p
[10:16] <groz> did you ever see uWoody ?
[10:16] <Kaloz> groz: for thinclients, old computers, for wardriving, etc :P
[10:16] <Kaloz> forget uwoody
[10:16] <Kaloz> i don't want debian
[10:17] <Kaloz> i like clean stuff
[10:17] <groz> andersee did that, rebuilt woody against uclibc a long time ago
[10:17] <Kaloz> i know
[10:17] <groz> i didn't say use it, i said, did you see it ?
[10:17] <groz> it was interesting to play with, in it's day
[10:17] <Kaloz> but i rather stick to what we have, spice it up with X and kdrive
[10:17] <groz> well, i've considered what'll be involved in getting X going, but then wonder
[10:18] <groz> there is a little setup, cant remember the name, it's a browser, works against a frame buffer
[10:18] <groz> was pretty slick when i last looked
[10:18] Action: Bartman007 cries at the thought of ipkg on a desktop
[10:18] <Kaloz> Bartman007: why? :)
[10:18] <groz> kaloz, here's another i'm gonna get going soon
[10:18] <groz> i'm gonna build openwrt as a colinux setup
[10:18] <groz> then wrap it into an msi
[10:19] <groz> so when you install it on a windows box, it sets up networking so
[10:19] <groz> windows is behind openwrt
[10:19] <db90h> kaloz: what about this uboot 4702 port, where can i get it? i'd like to try that out right now
[10:19] <Bartman007> Kaloz: I've been spoiled by package managers that handle version checking
[10:19] <Kaloz> db90h: trying to find it
[10:20] <db90h> oh, ok, sorry ;)
[10:20] <Kaloz> db90h: http://kbserver.netgear.com/kb_web_files/n101238.asp
[10:20] <db90h> thanks
[10:20] <Kaloz> db90h: it was in one of the FSM* switch tarballs
[10:20] <Kaloz> downloading the one for 7328
[10:20] <db90h> ok, i'll check 7352
[10:20] <Bartman007> groz: personally I despise any msi/installer that tweaks networking settings
[10:21] <Bartman007> but that's one of the reasons I ditched windows, too much voodoo going on.
[10:21] <groz> well, i have a specific target for that setup
[10:21] <groz> my dads puter
[10:21] <db90h> how big is a typical uboot build?
[10:21] <Kaloz> Bartman007: without voodoo noone could get the eXPerience
[10:21] <Kaloz> :D
[10:21] <groz> i can ship it, and then put a vpn in the openwrt
[10:22] <groz> and deal with his system remotely, and keep him behind a firewall that _I_ control
[10:22] <Bartman007> lol
[10:22] <Bartman007> ah crap it's late, I should get some sleep
[10:22] <db90h> bartman007: should would could, but why?
[10:23] <Kaloz> db90h: ftp://downloads.netgear.com/files/GPL/fsm7326poss.tgz
[10:23] <db90h> thanks
[10:23] <Bartman007> my gf is dragging me out to see Snakes on a Plane after work tomorrow... so I won't be able to do anything comp/router related until late tomorrow
[10:24] <Kaloz> db90h: probably it lacks networking, but adding drivers from linux to uboot is easy
[10:24] <Bartman007> damn that move is going to be bad...
[10:25] <db90h> ok
[10:28] <db90h> Kaloz: this is cool ;)
[10:28] <db90h> 94702 and 94704 board support
[10:29] <db90h> jffs2 drivers
[10:29] <db90h> along with fat
[10:30] <db90h> and everything else in the world.. i'll pray for the appropriate network drivers to already be there, but ok if not
[10:31] <db90h> of course, no real use for jffs2 or any other file system drivers, i was just expressing its coolness
[10:34] <Kaloz> :)
[10:49] <db90h> it will require some work, but would be worthwhile.. i'm going to check and see if i have any better luck getting a CFE based on asus sources to boot on a newer device real quick first
[10:51] <[florian]> lol
[10:51] <groz> db90 when you are done all this
[10:51] <groz> and thaty V5 boots
[10:52] <groz> how much flash is free in it, with a kernel, and just enough to run
[10:52] <db90h> ?
[10:52] <groz> you seem to be putting a lot of effort into shrinking
[10:52] <groz> so i'm curious, what is the result
[10:52] <groz> so, just a kernel, and enough scripts to get a shell
[10:52] <groz> with nothing else
[10:52] <db90h> optimized static firmwares (like dd-wrt micro) have included everything any average user would want already in the 1.7MB available.. and on GS units with 16MB of RAM it's high usable (and works ok on G's with 8MB)
[10:52] <groz> what do you end up with for space to work on
[10:53] <db90h> the point is making the devices better, not making them into something they aren't
[10:54] <db90h> plus, with my firmware mod kit, people can install custom stuff into the micro builds.. strip out PPPOE or UPNP, whatever u don't want, and u can include your own stuff
[10:55] <groz> well that's what im asking, with all the crap stripped out, including iptables etc, just enough to bring it up
[10:55] <groz> what kind of space is left ?
[10:55] <db90h> dd-wrt micro includes upnp, pppoe, ppp, pptp, qos, and everything else 'standard'
[10:56] <db90h> oh, ok, i thought u were attacking the poor v5, i get defensive ;p
[10:56] <db90h> well, openwrt micro builds leave like 60KB on JFFS2 partition
[10:56] <groz> no, i'm tring to figure out what that baseline is
[10:56] <db90h> if you stripped them down further, i'm not sure...
[10:56] <groz> 60k, isn't even an erase block
[10:56] <groz> or does that use 32k erase blocks ?
[10:57] <db90h> umm, not positive.. all I remember is seeing around 6xKB free on JFFS2 partition when i installed it, aboout all I can speak for..
[10:57] <db90h> I think the erase blocks are 64KB, i've not seen indications of smaller sizes
[10:58] <db90h> probably there was 1 erase block
[10:58] <db90h> and minus file system overhead, about 60KB
[10:59] <db90h> busybox could have no doubt been trimmed a bit on that openwrt micro build, and the uclibc library wasn't pruned..
[11:00] <db90h> but, of course, such things are useless, u really gotta use a static firmware that fills the squashfs with everything u can get in there
[11:02] <db90h> and then not even try to include jffs2.. the belkin 7231-4 firmwares are a good example of how to squeeze as much as possible into a 2MB flash, in the end the extensible philosophy of openwrt has to be completely abandoned
[11:03] <db90h> so the baseline is hard to say for sure.. a usable baseline that allows extension leaves not much at all
[11:03] <groz> well, for the job i'm considering
[11:03] <groz> i need some read/write space
[11:03] <groz> but none of the typical things you expect in a router
[11:03] <groz> just one rather small custom app
[11:03] <groz> i need bridge, and that's it
[11:03] <groz> no firewall, nothing
[11:04] <groz> but i do need some read/write space
[11:04] <db90h> would nvram as storage and writing files out to /tmp at boot from it work?
[11:04] <groz> no
[11:04] <groz> it's logging data from a very slow data source
[11:04] <db90h> well i think u could do it
[11:04] <groz> so i need to write to a file, which gets read and deleted once in a while
[11:04] <groz> from another unit
[11:04] <db90h> if u don't need any of the other stuff, u could probably get 256KB free JFFS2 at least
[11:04] <groz> over wifi
[11:05] <db90h> if u trim busybox u can get more
[11:05] <groz> my app linked against uclibc runs about 175K
[11:06] <db90h> i don't think you'll have a problem if you need such a minimal base system
[11:11] <db90h> hehe, now i see clearly how i am so quick to misunderstand and over-react.. a mere mention of the v5 got my blood pumping, lol
[11:11] <groz> you and a few others
[11:13] Action: db90h strokes his precious
[11:14] <db90h> btw, above, i wasn't including in my estimates having a compressed CFE (or alternate boot loader) actually working... so consider that as well
[11:15] <db90h> and i'm sorry i misintrepeted your question at first
[11:16] <groz> those v5 only have 8 meg ram dont they ?
[11:16] <db90h> the Gs are 8, GS are 16
[11:16] <groz> so gs is 2/16
[11:16] <db90h> 8MB of RAM is really hard to work with, harder than the ROM limitations
[11:16] <db90h> yep
[11:16] <groz> yah, dunno if we could squeeze into 8 megs
[11:17] <db90h> it took getting someone to send me a GS so i could figure out the sdram parameters (btw, i wrote a tool to encoder and decode them if anybody ever needs it..).. in the end, i had to resort to brute force guessing, because no logical choices worked. sdram_init=0x0A ended up being the magic
[11:18] <db90h> and, naturally, as soon as I posted the info with warnings all around that it only pertains to GS units and would brick G units, 100 people instantly tried it on their G units and bricked them ;p
[11:19] <[florian]> maybe it's time to admit vxworks can run on this 8mb devices :p
[11:19] <groz> it may run florian, but, they aren't stable
[11:27] <db90h> not sure what the issue is, if it's simply bugs in the broadcom implementation or linksys modifications.. or if it's the low resources
[11:27] <db90h> i'd love to be able to play with vxworks sources
[11:27] <db90h> again, that burgular is needed ;)
[11:28] <db90h> the belkin 7231-4 firmware is probably the best example of a linux firmware that runs pretty well in 8MB RAM
[11:38] <[florian]> has anyone had a try to ath-driver ?
[11:39] <[florian]> looks like they have published some code recently
[12:14] <groz> mbm ping
[12:44] <CIA-17> florian * r4589 /packages/libs/uclibc++/ (Makefile files/config.armeb): Add an arm config file. Remove the armeb to arm substitution since we will probably want something else than just armeb to be supported
[12:50] <[florian]> is 1 << 1 the equivalent of 0x02 ?
[12:50] <groz> should be
[12:52] <[florian]> thanks
[12:53] <groz> the only time it isn't, is when one of the shift registers has a wrap around bug
[12:54] <groz> and then occaisionally, that would become either 4 or 0
[12:54] <[florian]> ok
[12:54] <groz> i dont think to many folks build hardware like that anymore :)
[12:54] <groz> it's now 'well known'
[12:56] <db90h> if 1<<1 didn't always equal 2 due to some hardware bug, i'd be highly upset ;p
[12:56] <groz> ya, well, i've written drivers that have to account for that bug
[12:56] <groz> it occurs in a 16550 of older vintage at times
[12:57] <db90h> i don't know if there are any endian considerations with shifts on variables larger than a byte or not.. can't think it through.. i always use shifts like that, but then again my shit on rarely needs to be endian neutral
[12:57] <groz> it's the reason the 16550A came out
[12:57] <groz> no, I've only seen it happen on the shift registers in fifo setups
[12:57] <groz> and it happens when you input one end, and extract the other end of the fifo
[12:57] <groz> at the same time
[12:57] <groz> with the fifo full to begin with
[12:58] <groz> it was a common problem way back when in chips with fifos
[12:58] <groz> 16550 uart did it, and i can remember a few more
[12:58] <groz> the real trick was, never let the fifo actually reach full
[12:58] <db90h> i have never done anything that works with the 16550, so fortunately i have been spared that bug ;)
[12:59] <groz> yah, well, most basic engineering texts now use that as a classic case of why most counters need an extra bit
[12:59] <db90h> i'll have to read up on it sometime and get a grasp of why it happened, i can't visualize it atm
[13:00] <groz> ok, consider this
[13:00] <groz> 16 byte fifo
[13:00] <groz> 4 bit counter
[13:00] <db90h> ok
[13:00] <groz> stuff 16 bytes in, it reads back 0x0f in the counter
[13:00] <groz> now, stuff in a byte, while one is being extracted
[13:00] <groz> counter reads back 0
[13:01] <groz> is it full, or empty ?
[13:01] <groz> no data was actually lost, the extraction end has already latched it
[13:01] <groz> but, it doesn't decrement the count, till the next cycle
[13:02] <groz> so there's a window of opportunity for the counter to read 0
[13:02] <groz> yet, the fifo is full, not empty
[13:02] <groz> now extrapolate that kind of condition
[13:02] <groz> and you reach scenarios where shift register overflows
[13:02] <groz> cause funny math
[13:04] <db90h> hmm.. hurts my brain
[13:04] <db90h> oh wait
[13:05] <db90h> 4 bit counter means the push makes it go to 0
[13:05] <groz> no, what hurts the brain, is sitting there trying to diagnose a buggy chip
[13:05] <groz> so you spend endless days writing test case code, to identify, and validate that bug
[13:05] <db90h> ..nah, i still don't see why the bug happens ;)
[13:05] <db90h> yea, that would suck ;)
[13:05] <groz> you push on a byte, counter overflows, the 4 bit counter
[13:06] <groz> rolls over to 0
[13:06] <db90h> right, but isn't there handling of this?
[13:06] <groz> but, there is a timing case of this being valid
[13:06] <db90h> oh ok
[13:06] <groz> yah, but my point is, the proper way to handle it
[13:06] <db90h> ic
[13:06] <groz> was learned thru hard grief
[13:06] <groz> way back when
[13:06] <db90h> so the pop occurs while the counter is temporarily 0
[13:06] <groz> well, the pop happens first, on clock cycle a
[13:07] <groz> but, the counter wont decrement, till 3 clocks later
[13:07] <groz> during those 3 clocks
[13:07] <groz> the popped data is latched
[13:07] <groz> on the first of them, you push a new one
[13:07] <groz> fifo is consistent
[13:07] <groz> next you read the counter status
[13:07] <groz> it reads 0
[13:07] <db90h> gotcha.. so the push is a valid push (only 15 bytes really there), but the counter is wrong (indicates 16==0) when the push happens
[13:07] <groz> even tho, one byte is out
[13:07] <groz> cuz it's in the output latches now
[13:08] <groz> so it has not been lost
[13:08] <groz> now, that's the error, but, assume for a minute, you dont know that
[13:08] <groz> you just know, code that _should_ work breaks
[13:08] <db90h> ok, i think i see now.. could be fixed with a semaphore or mutex tho couldn't it?
[13:08] <groz> and you've got 4 prototype chops on your desk
[13:08] <groz> and a mandate to prove why they are broken
[13:09] <groz> in 2 weeks, before the design is locked into production
[13:09] Action: groz been there, done that
[13:09] <db90h> that would suck
[13:09] <groz> actually, it's fun
[13:09] <groz> challenging
[13:09] <db90h> might tempt you to attack the writers of the code
[13:09] <groz> and you feel real good when you can go back to the hardware guys
[13:09] <db90h> or rather the 16550 designers
[13:09] <groz> with a test case, that proves the error
[13:10] <groz> nahh, you dont attack them, you are working with them
[13:10] <db90h> oh, ok ;)
[13:10] <groz> they are in the next row of cubes
[13:10] <db90h> well, yea, in that case i can see it being fun.. it is cool to discover reproducible hardware bugs
[13:11] <groz> yah, and, bunch of eager young kids, creating leading edge electroincs
[13:11] <groz> everybody is eager, and having fun
[13:11] <groz> so it's just a big challenge to make it better, find the problems, etc
[13:11] <db90h> different environment than i imagined.. i always envision this corporate environment where you got some asshole non-technical manager breathing down your neck
[13:12] <groz> never worked in one of those
[13:13] <groz> I tend to choose places where it's a team effort, everybody focussed on the final goal
[13:13] <db90h> i don't guess i have either come to think of it.. but i've always assumed it's a frequent scenario
[13:13] <groz> i've been at a lot of silicon valley chip makers shops
[13:13] <groz> and the ONLY one i remember being like that
[13:13] <groz> was intel
[13:15] <db90h> i have respect for the unique skills management requires, but have little respect for 'professional managers'.. those who believe management is the same no matter what industry
[13:16] <db90h> for whatever reason, it seems good programming requires a unique sort of environment
[13:16] <db90h> or maybe i'm just spoiled and don't want to actually 'work' unless i find it fun ;p
[13:18] <groz> that's always been my attitude
[13:23] <db90h> btw, i emailed the author of that management GUI for openwrt
[13:24] <groz> but did you get a response ?
[13:24] <db90h> he is still working on it, and believes the future is management UIs that reside on clients and connect to the router though either ssh, telnet, or a specialized protocol
[13:24] <db90h> yea, in like 10 minutes
[13:24] <db90h> he wanted to update whatever web app platform it wrote it with before making further progress, but as his spare time allows, he does intend to continue it..
[13:25] <db90h> i find the idea of management tools on the client somewhat appealing, particularly if they are platform independent
[13:25] <groz> i dont like the idea of a tool on the client, that's what browsers are for
[13:25] <groz> neatly platform independant
[13:26] <db90h> yea, there's definitely trade offs either way.. the advantage of a client side management tool is a more advanced UI and less resources usage on the router
[13:26] <groz> i do not like the idea of having to fuss around finding compatible binaries for whatever i'm on today
[13:26] <db90h> i envision a management GUI written in something like Java
[13:26] <groz> that would suck big time
[13:26] <groz> i use clients that are not fat enough for java
[13:27] <db90h> yea, i thought of that, after you telliing me of your client that uses his cell phone to manage the router
[13:27] <groz> i carry a nokia 770
[13:27] <groz> use it all th etime
[13:28] <groz> and i'm willing to bet, a 'client gui' would not be available as an app for my 770
[13:28] <db90h> i am finding the idea less appealing now
[13:29] <db90h> oh well, it seemed good at the time ;)
[13:29] <groz> have you seen the 770 ?
[13:29] <db90h> nope
[13:29] <groz> it's a great 'browser in the pocket' with a damn good wifi client on it
[13:30] <groz> it can see aps that none of my other boxes can see, right here on my desk
[13:30] <db90h> its not opera is it?
[13:30] <groz> i believe it is
[13:30] <db90h> opera does an awesome job of resizing web content so its viewable.. it's amazing in fact
[13:30] <groz> http://europe.nokia.com/770
[13:31] <[florian]> good device :)
[13:31] <db90h> cool
[13:31] <groz> I love it
[13:31] <db90h> wish i had one ;)
[13:31] <groz> i'm parked on the ramp at an airport up coast
[13:31] <groz> i can get email, fetch weather maps
[13:31] <groz> all sitting in the cockpit of the plane
[13:31] <groz> most ramps have wifi these days
[13:32] <groz> i've never had the batteries die
[13:32] <groz> during a day on the road
[13:32] <groz> it's simply amazing at it's smarts regarding power management
[13:33] <groz> I have 9 WRT54 in my apartment right now, 2 of them with 7dbi antenna sets on them
[13:33] <groz> my nokia can see 2 aps that none of the wrts, and none of the laptops can see
[13:33] <groz> and it'll connect, and trasnfer data thru them
[13:34] <groz> i've actually been toying with the idea of setting up usbnet on it
[13:34] <groz> and then using it as a client mode router
[13:34] <groz> to route p2p traffic thru a neighbors ap
[13:34] <db90h> what for?
[13:35] <db90h> i mean, route p2p traffic
[13:35] <[florian]> not being caught himself, or just avoid buying CD's, DVD's ;)
[13:35] <groz> so the load isn't on my network connection
[13:35] <db90h> ;)
[13:35] <db90h> i thought about that myself ;)
[13:35] <groz> actually florian, the only thing i've got on p2p right now, ubuntu cds
[13:35] <[florian]> lol
[13:37] <groz> as far as music goes, i have no need to get it on p2p, and i wouldn't anyways
[13:37] <groz> in my airplane business, a record label is one of my largest clients
[13:37] <groz> and i regularily fly around a couple of thier 'stars'
[13:37] <groz> doing that tomorrow evening actually
[13:38] <db90h> whohoo, get an autograph from Britney Spears for me!
[13:38] <db90h> ;)
[13:38] <groz> last time i mentioned to her that i thought her latest cd was pretty good, i she brought 50 autographed copies next time
[13:38] <[florian]> lol
[13:38] <db90h> i knew it was Britney!
[13:38] <groz> shes' on a different label, and i wouldn't let her in my plane anyways
[13:38] <db90h> hehe
[13:38] <groz> but one of her competitors is a regular
[13:38] <db90h> Christina?!
[13:39] <db90h> get some nudie pics!
[13:39] <[florian]> lol
[13:41] <groz> but my point is, when record companies are part of the bread and butter
[13:41] <groz> one doesn't risk getting nailed with p2p problems
[13:43] <[florian]> Kaloz: why the xscale target is big endian ? cannot it run in le too ?
[13:52] <[florian]> there is a tricky problem when switching from architectures, especially with the optimized options
[13:55] <[florian]> it will attempt to use the architecture specific cflags
[13:56] <[florian]> and changing the architecture in the menu, does not change the optimized cflags
[14:04] <Kibobo> salut
[14:04] <[florian]> Kibobo: stick to english please
[14:04] <Kibobo> k
[14:04] <[florian]> thanks
[14:07] <Kibobo> the 2.6 port for BCM94704 is it based on 2.4 sources from broadcom ?
[14:07] <Kaloz> [florian]: ixp42x is big endian by default
[14:07] <[florian]> Kaloz: ok
[14:08] <Kaloz> [florian]: iop is the little endian xscale stuff (ixp42x can operate in le, too, but it doesn't do that by default)
[14:08] <Kibobo> There is, for instance, sources for Speedport W 500V based on 2.6 kernel
[14:08] <Kibobo> but it's not the same architecture
[14:08] <[florian]> Kibobo: the BCM97xx 2.6 port is based on the 2.4 sources that's right
[14:09] <Kibobo> ok
[14:09] <[florian]> Kibobo: I guess it's a bcm963xx ?
[14:09] <Kibobo> yes
[14:10] <[florian]> ok, as it is a completely different design, there may not be many things portable between these 2 arch
[14:11] <[florian]> but if you want to do some bcm963xx work, feel free to try the brcm63xx-2.6 port in buildroot-ng
[14:11] <Kibobo> I just would like to know if a manufacturer has supplied sources for 2.6
[14:12] <Kibobo> like for the 63xx
[14:12] <[florian]> I don't think there are 2.6 sources for bcm947xx/953xx yet
[14:12] <Kibobo> My work is on ASUS 500 premium
[14:12] <Kibobo> 4704
[14:13] <Kibobo> Montavista pro 3.1 include such support
[14:13] <Kibobo> but not integrated yet in the wireless/router market
[14:14] <Kaloz> only monstavista 4.x support 2.6
[14:14] <Kaloz> and even that doesn't support 2.6 on the 47xx
[14:15] <Kibobo> oops, ok
[14:21] <Kibobo> There is a bug list for 2.6 on 47xx ?
[14:22] <Kibobo> except wifi
[14:22] <Kaloz> it currently only support the 4712
[14:22] <Kaloz> someone should add the missing stuff for 4702/4704
[14:22] <Kibobo> And what about jolt patches ?
[14:23] <Kibobo> oops, ok
[14:24] <Kibobo> do you know the differences ?
[14:24] <Kibobo> between 02/04 and 12 ?
[14:24] <Kibobo> broadcom datasheets are very difficult to find
[14:25] <Kibobo> and tuxap cvs is maybe out to date
[14:25] <Kaloz> different speed and core
[14:26] <Kaloz> the 4707 has the same core as the 4712, but different speed (266mhz) and 2 ethernet interfaces
[14:26] <Kaloz> oh, and external pci
[14:26] <Kaloz> the 4702 is only 125mhz and 82bogomips, but has external pci as well
[14:32] <Kibobo> 4712 on netgear wgt634u ?
[14:36] <malbon> 5365 on wgt634u
[14:36] <murb> malbon: know if anyone has looked at the crypto accelation stuff on the wgt634u?
[14:37] <CIA-17> groz * r4590 /packages/utils/lilo/ (Makefile S11Pivot bdlilo.conf boot.msg lilo.conf mkbootable): Updated to properly set up 2.6 with early userspace file system boot
[14:37] <malbon> murb: there is a thread if the forum.
[14:37] <murb> malbon: is it just wibble or something more substantive/
[14:38] <malbon> murb: looks like someone has actually started work on it. not just the normal 'request' threads
[14:39] <murb> i should have some more wgt634us soon...
[14:39] <malbon> murb: http://forum.openwrt.org/viewtopic.php?pid=32297#p32297
[14:39] <malbon> they are good devices imho
[14:39] <CIA-17> groz * r4591 /branches/buildroot-ng/openwrt/include/kernel-build.mk: Update for initramfs handling
[14:40] <murb> problem is justdeals seem to have cornered the 2nd hand market
[14:40] <murb> and they are *slow*
[14:40] <malbon> yeah that's true, they are not fast.
[14:40] <CIA-17> groz * r4592 /branches/buildroot-ng/openwrt/target/linux/generic-2.6/files/init: Flesh out early userspace for initramfs to allow booting from media
[14:42] <groz> http://pastebin.ca/137454
[14:42] <groz> clean boot on the via board, 2.6, from the usb stick
[14:43] <groz> properly using initramfs and then switching to the usb as root
[14:43] <groz> so it's running from a usb stick boot the way I want/need
[14:44] <groz> complete with lilo options for failsafe and ramdisk boots as well, on the serial console
[14:45] <groz> and now for fun, i'm gonna raid 5 a group of 3 usb sticks
[14:46] <Kibobo> lol
[14:58] <CIA-17> groz * r4593 /packages/utils/lilo/README: update readme
[15:06] <[florian]> I am definitively not fond of the uml stuff : it highly depends on a x86 box running linux, whereas qemu is not plaftorm specific, nor os specific
[15:07] <[florian]> murb: if you feel brave enough, you can port the ubsec driver to linux in order to use this crypto stuff
[15:07] <groz> it's also an emulation, whereas uml is running raw on the processor
[15:07] <groz> so if you have an x86 box
[15:07] <[florian]> groz: right
[15:07] <groz> it's way more efficient
[15:07] <murb> [florian]: it has enough idiocincracies to be considered multiple platforms :-)
[15:07] <murb> [florian]: ooh.
[15:10] <Kibobo> [florian]: have you received my private message ?
[15:10] <CIA-17> florian * r4594 /branches/ (2 files in 2 dirs): Add support for the Asus power led, closes #349
[15:10] <murb> groz: there is acceleration for the x86 on x86 case.
[15:11] <[florian]> Kibobo: did not look yet :p
[15:11] <murb> and there is qemu-fast which requires minor guest modification.
[15:11] <Kibobo> however, i'm registred :/
[15:12] <Kibobo> come back
[15:13] <groz> ok, im done for tonite, now a coupld hours of zzz time
[15:13] <groz> then im gonna go make some holes in the sky
[15:16] <Kibobo> [florian]: do you accept PM ? :)
[15:17] <[florian]> Kibobo: sure, I can read you, what about me ? can you read me ?
[15:17] <Kibobo> no ...
[15:18] <[florian]> should be good now
[15:18] <Kibobo> ya
[15:30] <[florian]> murb: did you have a look at the ubsec sources ?
[15:31] <[florian]> malbon: ping ?
[16:02] <malbon> [florian]: hi
[16:10] <nbd> groz: ping
[16:23] <[florian]> shut up wrt
[16:23] <[florian]> malbon: it would be great to discuss how we are going to use your automated builds :)
[16:44] <CIA-17> nbd * r4595 /branches/buildroot-ng/openwrt/include/kernel-build.mk: remove reference to missing file
[16:50] <malbon> [florian]: ok, I'm open to suggestion, so let me know what you want, and I'll try to make it happen. :)
[16:50] <[florian]> actually I want to have other developpers opinion about that
[16:51] <[florian]> ihmo, it could be great to have dedicated reports
[16:51] <[florian]> for instance, all developpers receive packages related errors and reports
[16:52] <[florian]> and we individually receive "our target" specific report ?
[16:52] <[florian]> don't know if it makes sense
[16:52] <malbon> hmm, packages might be a bit hard, but certainly each arch can have it's own dist list.
[16:54] <malbon> so I have a bug open for scpa5xxx because it doesn't build on 2.4 kernels any more. Is that the 2.4 arch owners fault? or the package owners fault for not specifying only build on kernel-2.6?
[16:54] <[florian]> {Nico} proposed a good solution : downgrade to a 2.4 working version for 2.4 builds
[16:55] <[florian]> and keep the latest up to date version for 2.6 only
[16:55] <[florian]> could be handled in the Makefile I think
[16:56] <malbon> which is fair enough for that one package, but how should we handle that in the future.
[16:57] <malbon> brb phone
[16:58] <malbon> back
[16:58] <[florian]> ok
[17:01] <malbon> after the weekend I'll add the other base arch's in, then configure up mail.
[17:01] <CIA-17> florian * r4596 /branches/whiterussian/openwrt/target/linux/ (4 files in 3 dirs): Add ipt_connbytes, closes #660
[17:03] <[florian]> no pb malbon
[17:32] <[florian]> damn wrt just shut up
[17:37] <CIA-17> florian * r4597 /branches/whiterussian/openwrt/target/linux/ (4 files in 3 dirs): Add ipt_CLASSIFY target, closes #696
[18:10] <CIA-17> florian * r4598 /branches/whiterussian/openwrt/target/linux/linux-2.4/patches/generic/118-netfilter_connbytes.patch: Fix user-space libipt_connbytes compilation by adding missing declarations
[18:36] <[mbm]> ..
[18:36] <[mbm]> groz: ?
[18:46] <Bartman007> [florian]: if you haven't found it already, I'm fairly sure the dd-wrt svn repo is at svn://svn.dd-wrt.com/DD-WRT
[19:04] <nbd> common: ping
[19:07] <db90h> groz: if u see this, regarding your question yesterday about 2MB ROM space with only a minimal install, you may be interested in this thread that I just found, if you haven't already seen it: http://forum.openwrt.org/viewtopic.php?id=4039&p=1
[19:08] Action: [mbm] is getting sick of that thread
[19:09] <db90h> damnit nbd! I knew a WRT54Gv5 wouldn't be a good birthday gift for mbm!
[19:09] <db90h> i'll just imagine the laughter
[19:10] <db90h> ;)
[19:10] <nbd> :)
[19:10] <[mbm]> I'm just sick of getting flamed for the direction openwrt takes
[19:10] <db90h> i didn't read the whole thread carefully, they were flaming u?
[19:10] Action: nbd fixes the stupid ipkg wget bug...
[19:10] <[mbm]> db90h: yes, read a few posts by samot
[19:11] <db90h> 2MB ROMs are totally in opposition to OpenWrt's design ideals, no doubt about it
[19:11] <db90h> and this wasn't a concept i always grasped ;)
[19:11] <[mbm]> well, people seem to think that we absolutely refuse to add in any spport for 2M devices
[19:11] <[mbm]> and that I'm the cause of that
[19:11] <Bartman007> [mbm]: you could be so much more popular if you, personally, spent then time to get every obscure router model working. Forget about adding new functionality or increasing stability...
[19:12] <CIA-17> nbd * r4599 /branches/buildroot-ng/openwrt/package/busybox/patches/911-ipkg.patch: don't try to use gnu wget specific options in ipkg
[19:12] <Bartman007> then again, you could always take the James Ewing method of doing then and ban people who disagree with you. ;-)
[19:12] <db90h> i thought blaming mbm for everything was a cultural norm ;)
[19:12] <[mbm]> the reality is as I explained in one of the later posts of that thread .. I really don't care what gets added as long as it doesn't interfere with the rest of the system .. problem is that I don't have the time or resources to get 2M working
[19:13] <[mbm]> db90h: it is, and it's starting to get to me :/
[19:16] Action: Bartman007 starts the "buy [mbm] a masseuse fund"
[19:16] <[mbm]> :P
[19:18] <[mbm]> it's to the point that I can't say anything negative because somehow it's nolonger my opinion but an "openwrt is against ..." statement
[19:20] <[mbm]> for the longest time it was a running gag that someone would come into #openwrt asking some dumb question and I'd tell them openwrt sucks and that I wouldn't use it
[19:27] <common> nbd: pong
[19:28] <db90h> i've always considered your opinion that of openwrt's, perhaps i shouldn't have.. just because i saw you as the 'leader'
[19:29] <Bartman007> db90h: do you consider everything Bush says to be the opinion of the US?
[19:29] <db90h> yes, I see now my mistake
[19:31] <{Nico}> nbd: the wget ipkg bug was a busybox bug in fact and i fixed it in [4586]
[19:32] Action: {Nico} has to go now
[19:32] <[mbm]> define Build/Configure
[19:32] <[mbm]> $(call Build/Configure/Default)
[19:32] <[mbm]> endef
[19:33] <[mbm]> ..
[19:33] <[mbm]> that seems somewhat pointless ;)
[19:34] <nbd> common: i managed to get jtag on my xscale board
[19:35] <Bartman007> ndb: wrv, devel board, or other?
[19:36] <nbd> {Nico}: ah, then i looked into the wrong wget source as reference
[19:36] <nbd> Bartman007: compatible to wrv54g
[19:37] <common> nbd: want to check my image?
[19:37] <nbd> can't do it yet
[19:37] <nbd> still flashing the boot loader
[19:37] <nbd> takes ages...
[19:46] <[mbm]> hmm I'm seeing the same mistakes over and over again in almost all of the package makefiles
[19:46] Action: [mbm] needs to come up with a sed command to fix them all at once
[19:51] <Bartman007> the sedfu is strong in this one.
[20:09] <[mbm]> umm .. why do we have some packages passing STAGING_DIR to the compile?
[20:09] Action: [mbm] really can't see why the package would care
[20:21] <common> [mbm]: regexxer
[20:24] <[florian]> Bartman007: thanks for the link, if only he could provide patches !
[20:24] <[florian]> [mbm]: most of the time to include the right include/linking directories
[20:25] <[mbm]> I'm seeing things like this: $(MAKE) ... STAGING_DIR=$(STAGING_DIR)
[20:26] <[florian]> some makefiles are referencing STAGING_DIR inside the source makefile
[20:26] <[mbm]> and I'm really doubting that the program being compiled even looks at $(STAGING_DIR)
[20:26] <[florian]> ok
[20:27] <[florian]> feel free to fix things like that
[20:27] <[mbm]> the other thing I'm seeing a lot of is what I point out before, a define which simply calls the default rule
[20:28] <[mbm]> .. the reason we call it default is because that's what happens if you don't define it
[20:28] <[florian]> ok
[20:29] <[florian]> by the way, porting about 100 packages to a new layout is a real pain, take it in consideration ;)
[20:29] <[florian]> all the more as the new Makefile layout is not yet documented (yes I am working on documenting it)
[20:29] <[mbm]> and finally, the only purpose for an empty Build/Configure is if the package uses configure and you explicitly want to avoid that
[20:30] <[florian]> ok
[20:30] <[mbm]> and yes I know you're porting 100's of packages
[20:31] <[mbm]> I'm just trying to save myself from cleaning up 100's of makefiles ;)
[20:32] <[florian]> yes I understand, we need to minimize our work
[20:33] <[florian]> when is rc6 planned to be realeased, if any date ?
[20:34] <[mbm]> *shrug* I've given up on trying to guess dates
[20:35] <[mbm]> there's still some cleanup that needs to be done
[20:35] <[florian]> is whiterussian still feature freeze ? for instance ticket #690 is clearly a new package :
[20:35] <[mbm]> you don't read the news very often do you?
[20:36] <[florian]> depends on what you call news, I have been on holiday for 6 days
[20:36] <[florian]> and where is the news
[20:36] <[mbm]> the front page of openwrt.org, which is also the news section of the forum
[20:37] <[florian]> ok
[20:37] <[mbm]> I seem to recall mentioning somewhere in there that we weren't doing the feature freeze
[20:37] <[mbm]> although I would appreciate if you didn't do any major rewrites
[20:38] <[florian]> ok, I was just planning on closing this ticket 690 because I think addind the dsl_qos_queue package is a good idea
[21:34] <groz> mbm ping
[21:34] <nbd> groz: hi
[21:34] <[mbm]> 'lo
[21:35] <groz> so, our discussion on the subject became moot, after fussing with some switch_root issues
[21:35] <nbd> groz: you forgot postinit in your last commit.
[21:35] <groz> the whole mess ended up in the init
[21:35] <groz> oh, did i sorry, it as late, and i was tired
[21:35] <groz> hang on
[21:35] <[mbm]> groz: heh
[21:35] <nbd> you have to put in the line for it again
[21:35] <nbd> i commented it out to have a working svn tree while you were asleep
[21:36] <CIA-17> groz * r4600 /branches/buildroot-ng/openwrt/target/linux/generic-2.6/files/postinit: File I forgot
[21:36] Action: [mbm] going to grab some food bbiab
[21:36] <groz> nbd, postinit is just a kludge
[21:36] <groz> cuz i was having issues with switch_root
[21:37] <groz> and googling, i found there have been problems with it and parameters to the chroot
[21:37] <nbd> groz: i know, but i commented out the line that included it in the build
[21:37] <groz> so, i wrapped it thru a script
[21:40] <CIA-17> groz * r4601 /branches/buildroot-ng/openwrt/include/kernel-build.mk: handle postinit for initramfs
[21:40] <groz> there
[21:41] <groz> probably some script oops in it still, ash scripts not my strong point
[21:41] <groz> but, it's a pretty generic early userspace setup, should work for just about anything
[21:41] <groz> to find / mount a root, or fall back to a failsafe
[21:42] <groz> and if it falls back, it'll leave you with a reason why in an env var
[21:52] <[mbm]> re.
[21:53] <groz> mbm, as I was saying, turns out switch_root has some issues
[21:54] <[mbm]> specifically?
[21:54] <groz> but, when all was said and done, it's encapsulated in 2 scripts, which are only included
[21:54] <groz> when you use initramfs
[21:54] <groz> specifically, it doesnt pass args correctly every time
[21:54] <groz> and googling on the subject, others have had this problem
[21:54] <groz> so, instead of trying to start init from there
[21:55] <groz> i chained it thru another script
[21:55] <[mbm]> which args?
[21:55] <groz> the args to init
[21:55] <groz> or rather
[21:55] <groz> to chroot
[21:55] <groz> which beomes your init
[21:55] <[mbm]> hmm
[21:55] <[mbm]> didn't expect there to be any args to init
[21:55] <groz> well, as in your initial script
[21:56] <groz> calling /bin/busybox init
[21:56] <[mbm]> right, but that comes from the kernel commandline
[21:56] <[mbm]> ah
[21:56] <groz> anysays, the second script becomes quite useful anyways
[21:56] <[mbm]> well the "/bin/busybox init" is a hack to avoid recusion if the chroot failed
[21:56] <groz> as a presence test on the target media
[21:56] <groz> if the postinit doesn't exist there
[21:57] <groz> we dont wanna chroot anyways
[21:57] <groz> we wanna failsafe
[21:57] <[mbm]> and while that hack is good, it doesn't really lend itself well to other hacks like chaining init scripts
[21:58] <groz> well, it could be changed to call a preinit in the 'default' system at that point
[21:58] <groz> but that would assume the preinit is included, always
[21:58] <[mbm]> I haven't looked at your preinit/postinit stuff yet
[21:58] <groz> then it would lend itself to chaining gracefully
[21:59] <groz> boils down in a nutshell to this
[21:59] <[mbm]> for the last several hours I've been rewriting package makefiles :/
[21:59] <groz> switch_root to the target, running postinit
[21:59] <groz> postinit is basically what you used to have for init
[21:59] <groz> but if any steps in the process of finding/mounting the root fail
[22:00] <groz> just go to failsafe
[22:00] <[mbm]> back up a few steps .. where does this all hook in? another init=/etc/preinit ?
[22:00] <groz> no, kernel command line gets rootfs=/dev/something
[22:00] <groz> then the init script in early userspace
[22:00] <[mbm]> ok, and you're being called as the init .. got it.
[22:01] <groz> goes looking to find/mount that, using utils that are in busybox, relying on nothing but busybox
[22:01] <groz> at each step along the way, a failure sets an env var with a reason
[22:01] <groz> and goes failsafe, which is running in the initramfs, with no mounted root
[22:01] <[mbm]> you mean postint is basically the old /etc/preinit script?
[22:02] <groz> it's the old generic-2.6/init
[22:02] <groz> which ends up running from the final target media
[22:02] <groz> and it could easily be changed to go to the preinit on target media
[22:02] <groz> but not all envs have a preinit
[22:02] <groz> if we standardized on that
[22:03] <groz> it _should_ go and chain onto preinit from the media
[22:03] <[mbm]> ok, that init script that you're using as postinit really was just a hack to get around the fact initramfs didn't mount devfs
[22:03] <[mbm]> there's really no reason to make it into another script
[22:03] <groz> rite, and now, it's just a hack to get running off the target
[22:03] <[mbm]> that can go in your preinit
[22:04] <groz> well, the init still needs _something_ on the target to finalize the presence/validity test
[22:04] <groz> so we dont end up switch_root to a stick that doesn't have our rootfs on it
[22:05] <[mbm]> give me a sec to actually look over the patches
[22:05] <groz> heh, well keep in mind, bash is NOT my strong suit, so, it's probly different than you would do
[22:05] <groz> but it works
[22:06] <groz> and it accounts for how to do presence tests with timeout, assuming nothing but busybox available
[22:06] <groz> by just testing for failures on mounts etc
[22:06] <[mbm]> hmm you're already mounting /dev in your init .. there's mount -o move and mount -o bind to handle the moving mount points
[22:06] <groz> i just realized something this morning
[22:07] <groz> it needs /tmp as tmpfs
[22:07] <[mbm]> well, when you're on initramfs your everything is tmpfs
[22:07] <groz> yes, but not after you switch_root
[22:07] <[mbm]> ah
[22:08] <groz> and it's not ending up with a tmpfs after the switch
[22:08] <groz> but that goes back to part of what we were going on about yesterda
[22:08] <groz> if we include preinit in every arch
[22:08] <groz> even if it's a noop
[22:08] <groz> then something like this can rely on preinit as the place to chain
[22:08] <[mbm]> hmm you are using mount -o move
[22:09] <[mbm]> then the whole idea of mounting /dev again from postinit is pointless
[22:10] <groz> all i did was mv preinit postinit, and write the preinit basically
[22:10] <groz> but again, back to my point
[22:10] <groz> if we have /etc/preinit everywhere, then, something that's stepping in early like this
[22:10] <groz> can chain onto preinit, in all cases
[22:10] <groz> taht's not always the case right now
[22:11] <groz> or is it ?
[22:11] <[mbm]> current architecture we have init=/etc/preinit which mounts the root and then calls /sbin/init
[22:12] <[mbm]> no, you're completely free to put a script on jffs2 called /sbin/init which then mounts a usb stick and pivots onto that ..
[22:12] <[mbm]> so yes, you can chain the boots
[22:12] <groz> well, base-files/x86 didn't have a preinit
[22:12] <groz> but if we add one there
[22:12] <groz> and go thru, make sure they all have one for 2.6
[22:13] <groz> then this will work everywhere, and the early userspace can just chain directly onto /etc/preinit from the media
[22:13] <groz> so enabling early userspace boot at that point in menuconfig
[22:13] <groz> will have same behaviour everywhere
[22:13] <[mbm]> btw the concept of "postinit" is confusing since I consider init to be the actual "init" program and not just some arbirary script calling itself init
[22:14] <groz> ok, but you aren't listening to what i'm typing
[22:14] <[mbm]> yeah, I'm getting a little confused by all of this
[22:14] <groz> the reason for putting that there was, x86 base files doesn't have /etc/preinit when built
[22:14] <groz> so the point i'm making
[22:14] <[mbm]> yes, I know that
[22:14] <groz> if we standardize with /etc/preinit on all arches
[22:15] <groz> then, the early userspace can chain on it, and use it for the presence test
[22:15] <groz> no need for that postinit kludge anymore
[22:15] <groz> and then it's all magic, by simply enabling initramfs
[22:15] <groz> and you have identical behaviour everywhere
[22:15] <groz> where this becomes especially interesting/useful
[22:16] <groz> is netbooting the kernel
[22:16] <[mbm]> umm but isn't the early init script doing the job that we originally wrote preinit to do?
[22:16] <groz> to go find out whats wrong with your media
[22:16] <groz> well, it's doint that, and more
[22:17] <[mbm]> I just can't see any point of a noop /etc/preinit
[22:17] <groz> for example, it's testing the target first before mounting, to do presence and validity tests
[22:17] <groz> the point is, so early userspace can identify the media as a valid openwrt rootfs
[22:17] <groz> before it switches
[22:17] <groz> so, if you netboot with the wrong stick in
[22:17] <[mbm]> why not base it on /sbin/init?
[22:18] <groz> it goes failsafe
[22:18] <[mbm]> there will either be a /sbin/init left over from initramfs or there will be one on your new root
[22:18] <groz> example of a really stupid use
[22:18] <[mbm]> either way it's safe to call /sbin/init
[22:19] <groz> yes, but, any linux media will have /sbin/init, it's not necessarily an openwrt media, i may have netbooted this kernel, cuz, i want to go troubleshoot whats wrong with a stick i'm building for something else
[22:20] <[mbm]> how about this, we move our motd to /etc/openwrt-release
[22:20] <[mbm]> and then you test for the presence of /etc/openwrt-release
[22:21] <[mbm]> but you execute /sbin/init
[22:21] <groz> hehe, doesn't make any difference what the test is for
[22:21] <groz> yes, that'll work, i was just thinking it is good to have some openwrt specific presence test
[22:21] <[mbm]> yeah I know, I just don't like the test for a useless script :)
[22:21] <groz> well, my other thought working last nite
[22:21] <[florian]> I think it is a good idea to move out the OpenWrt motd
[22:21] <groz> was to isolate it into files only included when initramfs is chosen
[22:22] <groz> so, for folks not using it, there is zero impact
[22:22] <[mbm]> sure
[22:22] <groz> but, is /sbin/init the right way to chain
[22:22] <[mbm]> yes
[22:22] <groz> or should it chain thru something that gets control prior to init
[22:23] <[mbm]> I think we should work based on the assumption that /sbin/init is the real init and always try to pass control to that
[22:23] <groz> that's trivial to change
[22:23] <[mbm]> now, it might not be the actual init
[22:23] <[mbm]> but that doesn't matter
[22:24] <groz> the other detail i ran into, a root= command line doesn't show up in env during early userspace
[22:24] <groz> so i went with something that does get passed, rootfs=
[22:24] <[mbm]> it may have gotten passed as a different variable
[22:25] <groz> it didn't show up at all in the env
[22:25] <groz> when i looked
[22:25] <[mbm]> hmm
[22:25] <[mbm]> there was a way to get it, I remember seeing an example
[22:26] <groz> well, i would end up falling thru to failsafe
[22:26] <groz> and from there, it wasn't showing up in the enf
[22:26] <groz> env
[22:27] <[mbm]> also, moot point but can we change the pivot function from firstboot to handle switch_root and then call that from your early init?
[22:27] <groz> that could be done too
[22:27] <[mbm]> the way it's currently setup, firstboot looks at argv[0] to see if it's "firstboot"
[22:27] <[mbm]> so you cna safely do ". firstboot"
[22:27] <[mbm]> to source it
[22:27] <groz> but that also means adding firstboot to the x86 stuff
[22:27] <groz> it's in brcm now, not generic
[22:28] <[mbm]> or we just move that function somewhere else like functions.sh
[22:28] <[mbm]> which you're already using anyways
[22:28] <groz> that would make sense, so the whole pivot/switch concept gets encapsulated
[22:28] <[mbm]> right
[22:28] <groz> and, a fix one place, migrates everywhere
[22:29] <[mbm]> yeah, that was something I was trying to get across yesterday when I was telling you not to do something arch specific
[22:29] <groz> well, one of my main goals with this setup, including the lilo part of what i did
[22:29] <groz> this makes it trivial for somebody to check out -ng, run a make, and have a bootable stick
[22:30] <groz> possibly a big hurdle when -ng goes into a 'preview' mode
[22:30] <groz> cuz if folks can get up and going painlessly and easily
[22:30] <groz> it'll be a lot easier to attract more folks, in particular, i'd like to see more folks take on package roles
[22:32] <[mbm]> right
[22:32] <[mbm]> I'd really love to see all of that work
[22:32] <groz> one more major item on my list of things, which i'll run past you folks
[22:32] <groz> the download script, i want to make a change there
[22:32] <groz> along this line
[22:32] <groz> when dl a package, always preference a local server first, defined in menuconfig
[22:32] <groz> so, say i'm working with a team
[22:33] <groz> we have copies of the sources as we are using them, all on a local web server
[22:33] <groz> that way, if somebody changes soemthing out on the net
[22:33] <groz> it doesn't break our local team enviornment, and we can get around to updating our local sources when it suits us
[22:33] <[mbm]> yeah, I was thinking of fixing that a different way - have an option to define the download directory
[22:33] <groz> does that make sense to you
[22:33] <groz> well, by optional local mirror
[22:33] <[mbm]> so then I'd just point it at a common nfs dir
[22:33] <groz> it can span a whole workgroup
[22:34] <groz> even folks that dont have direct nfs availability etc
[22:34] <[mbm]> right, we probably should do both options
[22:34] <groz> well, considering my 'workgrup' includes folks in vancouver
[22:35] <groz> folks in miami
[22:35] <groz> and folks in texas
[22:35] <[mbm]> because the problem with the local server is that now everyone is eating space with copies of the same files
[22:35] <groz> the web option makes most sense for me
[22:35] <groz> local server is optional
[22:35] <[mbm]> where as the nfs would be shared
[22:35] <groz> only if you define an url
[22:35] <[mbm]> right
[22:35] <[mbm]> like I said, both options
[22:35] <groz> nahh, on this machine, i use soft links for dl
[22:36] <groz> hehe, but, hey, we both have different itches, so, we each scratch one
[22:36] <[mbm]> groz: not everyone is going to be building from the webserver
[22:36] <groz> and we now got 2 options
[22:36] <[mbm]> oh .. something else along those same lines
[22:36] <groz> no, but, everybody is going to dl sources from somewhere
[22:36] <groz> at least once
[22:37] <[mbm]> well, my point was that I set dl to /nfs/dl and toss all the sources in there
[22:37] <groz> right
[22:37] <[mbm]> and nobody has to do any downloads, and there's only one copy of the sources
[22:37] <groz> and then they dl once for your network
[22:37] <groz> covers everybody
[22:38] <groz> and i want a web server, cuz, i want consistent versions for folks geographically separated, nfs not an option
[22:38] <[mbm]> yeah, I know why you want your server and I already told you to add it :P
[22:38] <[mbm]> (do we want to go around in circles again?)
[22:38] <groz> so now with both options in place, we have a 'company specific web repository of sources', and then an nfs option for 'office specific'
[22:39] <groz> and voila, whole system works for 'big company lotsa offices'
[22:39] <[mbm]> anyways, something else is that it annoys the hell out of me that the default download location for several of the packages is the slow european mirrors which only go at 20k/s
[22:40] <groz> must be cuz we got all those europeans making package scripts/makefiles
[22:40] <groz> they probly go good for those guys
[22:40] <[mbm]> I'm sure
[22:41] <[mbm]> hmm now this is annoying .. the dhcp6 sources have invalid mtimes
[22:41] <[mbm]> so it always thinks those have changed and rebuilds them
[22:41] <groz> that'll stop in a few hours
[22:41] <groz> when the time zones have rolled over
[22:41] <groz> ie its more than 8 hours since you extracted them
[22:42] Action: groz has seen that in lots of packages
[22:43] <[mbm]> yeah I know .. it's just annoying
[22:43] <groz> a simple workaround, have your local clock gmt
[22:43] <groz> and if you are a pilot like I am, it's not even confusing
[22:43] <[mbm]> you have to understand that the way I'm hunting for corrupted package makefiles is by continuously recompiling and seieng what rebuilds
[22:43] <groz> cuz you are using gmt all the time anyways
[22:43] <[mbm]> my clock already is in utc
[22:44] <groz> ok, then the packages are done the other way, and set your clock to hawaii time
[22:44] <[mbm]> bah, I think a touch * will fix it ;)
[22:45] <groz> oh comon, that's to easy
[22:45] <groz> it's more fun to do things the complicated way
[22:45] <[mbm]> you're damn right .. I'm not about to change my clock just because the idiot that made the zip couldn't tell time
[22:55] <Bartman007> [mbm]: in a few months time I might be able to provide a California based source mirror if desired,
[22:55] <[mbm]> sure
[22:56] <[florian]> I can also provide a mirror if needed
[22:56] <[mbm]> not exactly sure that we need mirrors
[22:56] <[mbm]> so I'm not sure how to approach it
[22:57] <groz> mirrors just mean more headaches to maintain
[22:57] <[mbm]> menas an rsync script, nothing more
[22:57] <[florian]> ok as you want
[22:58] <groz> my desire for a local mirror/source is not so much saving time, but to enforce consistency
[22:58] <[mbm]> yay, I've almost compiled every single package
[22:58] <[mbm]> (and by that I mean without errors)
[22:58] <groz> is there a magic parameter to 'compile them all' ?
[22:58] <[mbm]> yes.
[22:59] <[mbm]> it's the 'select all by default' in menuconfig but it's actual usage is confusing until you understand what that means
[23:00] <groz> i selected that, and they didn't build
[23:00] <[mbm]> exactly
[23:00] <groz> hehe
[23:00] <[mbm]> what that does is change the defaults from N to M
[23:00] <groz> so stuff already N stays N
[23:00] <[mbm]> ah, finally someone who gets it ;)
[23:00] <groz> simple trick
[23:00] <groz> unlink the packages tree
[23:01] Action: [mbm] usually has to explain that a few times
[23:01] <groz> make menuconfig
[23:01] <groz> lose all the options
[23:01] <[mbm]> or just wipe your .config
[23:01] <groz> link it back in, with that
[23:01] <groz> and voila, all in
[23:04] <Bartman007> so it is possbile to just link the packages tree? (if so I feel like an idiot)
[23:04] <CIA-17> florian * r4602 / (13 files in 6 dirs): Add dsl-qos-queue to -ng and whiterussian, closes #690
[23:04] <[mbm]> Bartman007: well, with the exception of the fact ng expects everything as package/*/Makefile and the packages tree is several levels deep
[23:05] <[mbm]> so it's usually something like this: for pkg in ../../packages/*/*; do { ln -sf $pkg .; } done
[23:06] <Bartman007> [mbm]: ok, I thought it was a problem, I was fairly sure I remember it breaking when I tried it the easy way. So I wrote a script to handle it with some visual feedback for new packages
[23:06] <Bartman007> though it's redundant since I read the output when updating.
[23:07] <[mbm]> hmmm has anyone actually gotten peerguardian to compile? I'm just seeing several pages of errors
[23:07] <[mbm]> which suggests that it never wroked
[23:08] <[florian]> [mbm]: I had it compiling
[23:08] <[florian]> let me check
[23:09] <groz> Bartman, save yourself the effort of writing the script, and grab the one in your pm
[23:10] <groz> it handles the nesting and will link into multiple build trees in one go
[23:11] <[mbm]> hmm might be a gcc version issue, switched gcc versions and I'm getting far less errors
[23:11] <groz> you probably didn't apply the magic fairy dust patch to that version of gcc
[23:12] <groz> it never seems to work properly without a few magic fairy dust patches
[23:12] <[mbm]> .. if people knew which end of the fairy that stuff came out of they sure wouldn't be sprinking it over everything ..
[23:12] <Bartman007> groz: I don't see any pm...
[23:13] <[florian]> actually it compiles for me [mbm]
[23:13] <[mbm]> hmm k
[23:13] <Bartman007> besides, my script is done already
[23:13] <groz> ok, guess i'm not identfiied
[23:13] <[mbm]> [florian]: and ipcad?
[23:16] <[florian]> [mbm]: works fine
[23:16] <[mbm]> ok
[23:16] <[florian]> every single package I merged is compiling on the fc4 I use
[23:19] <[florian]> but there may be gcc versions/ distros that cause problems
[23:19] <[mbm]> well, we compile gcc
[23:20] <[florian]> yes, but I don't know if a gcc4 cross-toolchain compiles everything in packages/
[23:20] <[florian]> I only used gcc-3.4.6
[23:21] <[mbm]> I was using 3.4.4 and that broke a few
[23:22] <CIA-17> mbm * r4603 / (78 files in 78 dirs): Fix/clean several hundred package makefiles
[23:22] <[mbm]> large commit in 3 2 1 ...
[23:22] <[mbm]> damn, bot beat me
[23:22] <Bartman007> lol
[23:22] <Bartman007> so CIA-17 announces when the commit is completed?
[23:22] <[mbm]> yep
[23:23] <Bartman007> sweet, because I just started updating as it announced ;-)
[23:23] <[florian]> thanks [mbm] for fixing this
[23:24] <Bartman007> I won't be able to test it until later though, leaving work right now
[23:24] <[mbm]> hmm only 78 packages .. felt like hundreds
[23:24] <Bartman007> damn, more files updated in the past day than in the week before :-)
[23:25] <[mbm]> [florian]: that package from #690, did that get added to the ng todo list?
[23:30] <[mbm]> groz: btw did that devfs_mk_dir ever get fixed?
[23:31] <groz> not yet, on the to-do list still
[23:32] <groz> i beleive its in the sd.o stuff
[23:32] <groz> but i haven't gotten right down in it yet, and, i gotta go flying shortly
[23:32] <groz> so not likely to get there today
[23:32] <[mbm]> thinking it might have been the patch that I pointed out earlier
[23:32] <[mbm]> k
[23:38] <groz> i do want to get that fixed tho, because without the fix, multiple sticks wont work
[23:38] Action: groz thinks it'll be fun to play with a raid of usb sticks
[23:38] <[mbm]> right
[23:39] <[mbm]> it's ticket #666 for when you finally do fix it
[23:39] <groz> oh my, the ticket from hell
[23:39] <[mbm]> ;)
[23:39] Action: [mbm] thinks it's funny how people avoid the number 666
[23:39] <groz> the thing i did to quickly look for a cross comparison
[23:40] <groz> was to recompile with 2.6.15
[23:40] <[mbm]> it's always 6667Mhz
[23:40] <groz> and it had the exact same problem
[23:40] <nbd> [mbm]: 6667 is because of rounding :)
[23:40] <groz> all federal governmnent phone numbers in bc, 604-666-xxxx
[23:40] <groz> i think somebody at bctel was having fun the day they assigned them that
[23:40] <[mbm]> nbd: well, yeah I know it's 666.666 but it's just funnt
[23:41] <nbd> :)
[23:42] <[mbm]> I want a hexium processor running at 666Mhz :/
[23:43] <[mbm]> but no, they had to call it a 'pentium pro' or 'pentium 2'
[23:43] <groz> with 666mb ram, and 666mb flash to
[23:43] <[mbm]> damned marketing
[23:43] <groz> just remember this mbm
[23:43] <groz> apollo 13 blasted off at 13:13 local time
[23:43] <groz> done intentionally
[23:43] <groz> only to blow up on the way
[23:44] <[mbm]> (also done intentionally?)
[23:44] <groz> LOL
[23:44] <groz> so, if i up the packages tree now, they may actually build eh ?
[23:45] <[mbm]> most of them
[23:45] <[mbm]> I still haven't sorted out the gcc/platform issues
[23:45] <groz> you building them for which target ?
[23:45] <[mbm]> I was testing with bcm-2.6
[00:00] --- Sat Aug 19 2006