Kernel Summit 2006: Embedded systems
Posted Jul 20, 2006 23:44 UTC (Thu) by wookey
Parent article: Kernel Summit 2006: Embedded systems
Is this talk online anywhere? I would be interested to read more. Maybe I should start going to OLS. Willy said he was trying to get them to move it to Cambridge - that would be handy :-)
Part of the problem with embedded developers not being good at contributing back to mainline is that they are usually suffering terribly from being stuck on a product treadmill with high pressure deadlines so tidying up patches to a state adequate for mainline inclusion often gets pushed back down the todo list (and then they are stale so you have to update then now too). At least some of the time developers are also relatively new to the whole thing and are far too embarrassed to show their code to _real_ kernel developers (not realising that if they are any good it will probably be rather more acceptable than they think it is).
They are also often working with super-ancient kernels and code so mainline is not terribly interested in their changes
I have certainly seen all of these effects in action, and I am, myself, an example of the genre: I have been sadly remiss about getting something am (partly) responsible for (YAFFS) into mainline. First it was too new, obscure and experimental, then we did a new version, and then we got stuck in a state where we were out of step with the MTD API for an embarassingly long time (about a year). And of course there is always that pressure of other things people are clamouring to have done, or a dead hard drive or a broken webserver, that mean today is never the week to sort out the current code, check it works with latest MTD and kernel and send it in. We did actually try and get stuff ready for 2.6.18 but missed. So we really might finally make 2.6.19. I hope so, it's been far too long.
YAFFS2 may be helpful with regard to the large flash drives issue, although it too was originally designed when 128MB was a lot of flash (back in 2002), and it currently maxes out at 8GB (per partition) which is probably already too small for some people. It does at least now have checkpointing so if you shut down properly then there is no need to rescan the flash at startup which can improve boot times by about a factor of 100. It is possible to make this work for non-safe shutdowns too, but that is not work that has currently been put into the filesystem, although it has been implemented in proof-of-concept form as descibed in this paper.
I haven't looked recently to see how this compares with current JFFS2/3, which of course I ought to do...Hopefully dwmw2 will be along in a mo to update me
to post comments)