On Wednesday 09 July 2008 12:58:15 Carsten Haitzler wrote: > On Wed, 09 Jul 2008 07:54:00 +0100 Andy Green <[EMAIL PROTECTED]> babbled: > > Did you see the last bootchart? Is everyone focused on the 6 seconds > > possible flab in kernel and kneecapping the device therefore because of > > the sheer impossibility of doing anything else about the other two > > minutes bringing userspace stuff up? > > yes - i did. say both of them. our kernel takes as long to just start init > as my motorola rokr e6 (also linux using qt embedded) takes to boot all the > way to the gui. that alone says to me "my god we have a lot of fat to cut > in the kernel). just putting everything in a monolithic kernel is a huge > reason for this.
If breaking boot from SD support only gains us 6 seconds I'd vote no. > of course we will look at the rest of userspace, but that doesn't mean we > should just ignore the kernel. I dont know the motorola rokr but a large part of the speed increase is probably because a lot of the base services and the GUI are thrown into one large statically linked binary, a static /dev, no dbus.. (correct me if I'm wrong) > > I guess I failed to check if you did it before I started doing it months > > ago and found it was nice. I explained a very strong reason ---> > > i know you do it. this is one of the reasons our production systems will > never improve - you never feel the pain of them as you always are doing > something different. if you had to suffer from the same boot time as the > rest of us every day... many times a day, you'd be thinking differently > about the sdio driver built into the kernel - along with everything else. > i'm just trying to point out that we should be optimising for the > production use-case, not for a debug/kernel hacker mode. if we can get sdio > up in much less time, then it's not much of a harm to still be there. A 'normal' user will probably seldom reboot. I assume most of the time they will suspend/resume, So is boot time really such a big issue? grtz, Sander
