| davidm | lool, OK that makes sense, I guess it means making a new image and having stevenk upload it too. | 00:05 |
|---|---|---|
| persia | IF a new image is made, could update-initramfs -u be run to avoid the modules.dep warnings at boot time? | 02:27 |
| === cprov is now known as cprov-away | ||
| persia | AnAnt: So, Ubuntu Mobile is an OS, but not really for phones. | 09:30 |
| AnAnt | persia: I didn't know of this channel, sorry | 09:30 |
| persia | Some of the parts that are missing are things like dialing applications. | 09:30 |
| persia | Speaking as someone who has a "Internet Mobile Tool" from sharp (not running Ubuntu Mobile), I say that not having a easy interface for dialing is a huge shortfall in a phone. | 09:31 |
| persia | Now there are a couple "phones" that might run Ubuntu Mobile, in that they are advertised as Atom processors, but they are large, and most aren't in shops yet, and it wouldn't be a very convenient phone. | 09:32 |
| persia | In terms of Phone OS's based on Linux, I think OpenMoko is likely the most mature, although there are some Qtopia phone apps that a few companies sell. | 09:32 |
| persia | There's also a bunch of relatively closed linux phones, but those aren't as much fun (Panasonic has several) | 09:33 |
| AnAnt | closed linux phones ? | 09:33 |
| persia | Well, open kernel, closed apps, not easy to hack. | 09:34 |
| AnAnt | Qtopia is a phone ? | 09:35 |
| persia | No, it's TrollTech's mobile stack. | 09:36 |
| AnAnt | oh, application platform | 09:36 |
| AnAnt | so, no phones yet running OpenMoko ? | 09:36 |
| persia | I'm not sure, at least not sold here. | 09:36 |
| suihkulokki | AnAnt: for example, the recent motorola linux phones: http://wiki.openezx.org/MotoMAGX_Security | 09:37 |
| AnAnt | are there plans for Ubuntu Mobile to target cell phones ? | 09:38 |
| persia | AnAnt: No, although there's nothing that says there won't be another Ubuntu derivative that does. | 09:39 |
| persia | Ubuntu Mobile is more about handhelds. Some people call these "Mobile Tools", some people call these "Mobile Internet Devices", and the really old ones were called "Palmtops". | 09:39 |
| AnAnt | ok | 09:40 |
| === asac_ is now known as asac | ||
| lool | davidm: Sorry, I pinged you instead of davmor2 | 10:53 |
| lool | persia: I'm not sure, doesn't it come from /etc/initramfs/modules? | 10:53 |
| persia | lool: It should, but the last image didn't have it, so there were boot errors. stgraber reported that running `update-initramfs -u` in a bare image fixed it. | 10:55 |
| stgraber_ | nope didn't fix it, I tried that though | 10:59 |
| persia | stgraber_: Oh. Sorry. I thought it did fix it from what you said. Hrm. | 11:00 |
| stgraber_ | modules.dep aren't copied to the initrd so you still get the error message :( | 11:00 |
| ogra | <persia> IF a new image is made, could update-initramfs -u be run to avoid the modules.dep warnings at boot time? | 12:07 |
| ogra | persia, no, you need to handle all the hardcoded modprobe calls | 12:07 |
| ogra | we need a NO_MODULES=True or something in initramfs.conf, so we can add if or case statements in the code so they get not executed | 12:08 |
| ogra | the errors you see are likely all from such hardcoded cases | 12:09 |
| persia | ogra: But there are apparently 197 kernel modules present. Do we really want NO_MODULES=True? | 12:17 |
| ogra | we apparently dont use any modules in the initramfs | 12:18 |
| ogra | they are still present in / after mounting the rootfs and will be used then | 12:19 |
| ogra | (withur modules.dep they wont load anyway, NO_MODULES=True would just be a consmetical fix to activate wrappers for the hardcoded calls) | 12:19 |
| ogra | *without | 12:20 |
| ogra | /usr/share/initramfs-tools/scripts/local has cals for loop and the filesystem ... /usr/share/initramfs-tools/scripts/functions forcefully tries to load i8042 and atkbd ... /usr/share/initramfs-tools/scripts/init-top/usplash acually tries the same again | 12:22 |
| ogra | /usr/share/initramfs-tools/scripts/init-top/all_generic_ide tries to load ata_generic and /usr/share/initramfs-tools/scripts/init-top/framebuffer loads fbcon | 12:22 |
| ogra | if you wrap these clls the boot will be quiet | 12:23 |
| ogra | *calls | 12:23 |
| ogra | (there might be more i missed though, thats just a simple grep modprobe on the initramfs scripts) | 12:23 |
| ogra | as i understood amit we have the modules we need compiled into the kernel now | 12:24 |
| ogra | so all these cals are moot | 12:24 |
| ogra | *calls | 12:24 |
| persia | Ah. OK. I see it now. Thanks for the detailed explanation. | 12:25 |
| persia | That's more hacking than I think has value for the Hardy final VM image, but it might make sense if the intrepid kernel is also to have such a model. | 12:25 |
| ogra | well, i wouldnt do that model at all | 12:25 |
| persia | On the other hand, I expect there will be a wider variety of supported devices for intrepid, so it may be that we'll want those calls back again. | 12:25 |
| ogra | just keep the modules, and have a huge blacklist from which you only exclude the ones you actually need would be my variant | 12:26 |
| persia | Hmm. I guess, although I don't prefer board-specific solutions. | 12:27 |
| ogra | and this blacklist can be generated based on image build profiles for specific devices ... if you dont have critical boot time constraints the blacklist wont be used (for a totally eneric image that works everywhere) | 12:27 |
| ogra | *generic | 12:27 |
| ogra | so what we built would be the generic image and a tool to maintin the blacklists .... the USG guys then could generate device specific images in an identical way | 12:28 |
| persia | Maybe module loading could be two-stage? Have a base set in initramfs for the key bits (e.g. disk), and then load others as required as the normal userspace is coming up. One rarely needs the keyboard enabled prior to X (although it's nice for debugging( | 12:28 |
| ogra | that two stage thin is exactly what we do atm :) | 12:28 |
| ogra | and thats why you see the modules.dep errors | 12:29 |
| persia | In that case, why does the modules list affect boot time? Maybe our measurement isn't of the right metric. | 12:29 |
| ogra | because there are still scripts forcing the call of modprobe :) | 12:29 |
| ogra | and the first thing modprobe does is to look up the module deps in modules.dep ;) | 12:30 |
| persia | OK. I'm understanding then. | 12:30 |
| ogra | whi doesnt exist | 12:30 |
| persia | And you think it's better to blacklist in initramfs rather than looking at a generic solution? | 12:30 |
| persia | I'd think a more generic model would have positive impact on boot speed for other applications as well (desktop, server, etc.) | 12:31 |
| ogra | well, what other generic solution would be there part from using monolithic kernels | 12:31 |
| persia | I thought you didn't like the two-stage module loading model. | 12:31 |
| ogra | we can have full monolithic, half monolithic as we do now (initramfs has no modules, userspace has) or use the full odule driven approach | 12:31 |
| persia | Ah. I see. | 12:32 |
| ogra | i would go with the full module driven way | 12:32 |
| ogra | as we do in the main distro | 12:32 |
| persia | And just put in a blacklist if there is known target hardware. | 12:32 |
| ogra | but maintain blacklists instead of whitelists ... the blacklisted modules wont be attempted to be loaded .... | 12:32 |
| ogra | if you work with whitelists i think the attepts will be made | 12:33 |
| ogra | the blacklisting way saves you FS access time | 12:33 |
| persia | Hmm. OK. What about pluggable device support? That oughtn't be on the blacklist, but isn't likely needed until userspace. | 12:33 |
| ogra | but i have to look deeper into that to make sure my assumptions arent wrong here | 12:34 |
| ogra | i just noticed that blacklisting seemed faster in the past | 12:34 |
| ogra | rightt, really only have the modules used in initramfs that are needed for bare booting | 12:34 |
| ogra | then let the userspace handle the whole rest | 12:35 |
| ogra | what you need will be the device specific frambuffer, all you need to get to the rootfs and thats it | 12:35 |
| persia | So there needs to be something in update-initramfs that restricts the copied module set? | 12:35 |
| ogra | likely not more than three four modules | 12:35 |
| persia | Well, depends on the hardware. I'd likely want more in my workstation. | 12:36 |
| ogra | ah, weell, less modules wil make the uncompressing faster | 12:36 |
| ogra | but we can have all modules in the initramfs | 12:36 |
| ogra | just not load them or make atempts to do so | 12:36 |
| ogra | you run UME or UNR on your workstation ? | 12:37 |
| persia | This would be a different blacklist in initramfs than in userspace? | 12:37 |
| ogra | exactly | 12:37 |
| ogra | that functionallity is already there | 12:37 |
| ogra | we just need to use it | 12:37 |
| persia | I don't run UME on my workstation, but if this is actually a sane way to reduce boot time, it would be useful there. | 12:37 |
| persia | Also, I expect a wide variety of UME hardware to be available after the intrepid release, so prefer something generic. | 12:38 |
| ogra | well, the profile mode (not sure you know it) should get some enhancement to handle modules | 12:38 |
| ogra | that would be appropriate | 12:38 |
| persia | I don't know it. Is this "kernel profiling"? | 12:38 |
| ogra | nope | 12:38 |
| ogra | fliesystem access profiling | 12:38 |
| ogra | it generates the readahead lists in a device specific way | 12:39 |
| ogra | its a bootoption, boot your workstation with it | 12:39 |
| persia | Ah. That's Keybuk's new readahead replacement plan? | 12:39 |
| ogra | it will be faster on the subsequent boots until you install new software | 12:39 |
| ogra | no, Keyuk wants to replace readahead completely by prefetch | 12:40 |
| ogra | but prefetch needs some massive changes | 12:40 |
| ogra | not sure that will happen in time fo intrepid | 12:40 |
| ogra | and readahead has the disadvantage of not being able to andle stacked filesystems | 12:40 |
| ogra | i.e. unionfs | 12:40 |
| ogra | i havent tested with aufs yet which wil be what intrepid uses as unionfs replacement | 12:41 |
| persia | Right, and we like stacked filesystems because of compression. | 12:41 |
| ogra | right | 12:42 |
| ogra | i heard good things about aufs though | 12:42 |
| ogra | but hanvent played with it myself | 12:42 |
| ogra | (in the readahead+unionfs setup the unionfs module oopsed, it wasnt readahead that broke ;) ) | 12:46 |
| ogra | so there are chances it could work with aufs | 12:47 |
| ogra | and readahead is actually speeding up things a lot | 12:47 |
| persia | Perhaps. Looking at upstream seems to indicate that aufs oughtn't be used. | 12:47 |
| ogra | ... if it works :) | 12:47 |
| ogra | which upstream ? | 12:47 |
| ogra | kernel.org ? | 12:48 |
| * persia needs to re-profile the workstation for both initial boot and login | 12:48 | |
| persia | aufs.sourceforge.net | 12:48 |
| persia | Might just be extra modesty though | 12:49 |
| ogra | yeah | 12:50 |
| ogra | unionfs isnt really maintained | 12:50 |
| ogra | its a UNI project | 12:50 |
| persia | I think aufs as well, but more actively so. | 12:50 |
| ogra | so you dont really have people jumping at bugs | 12:50 |
| ogra | right | 12:50 |
| ogra | i think that was the initial reason for aufs | 12:51 |
| ogra | unionfs was always rather a proof of concept | 12:52 |
| === stgraber_ is now known as stgraber | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!