XIP kernel + MTD polling interest

[Shane Nay]

> 
> How do you deal with calls to schedule()?  If you can't schedule you must
> poll the flash for termination and block all interrupts and say goodbye
> to
> low latency response from the kernel.  If that's not a problem for you
> then
> you might as well get rid of all the state machine code which is there
> only
> for concurent flash access which is impossible in your case since you
> need
> atomic flash operations.  Thus the code can become extremely simple.

Schedule? :-) Obviously can't do it, as you noted.  Yes, latency goes down
the drain, the flash chips are actually pretty fast on write, and okay on
erase.  Basically the plan is to kill any erasing of blocks, and have a
cleanup program that re-does the entire thing in one locked up motion.

> IMHO you are better to fork all relevant functions and have the chance to
> simplify them rather than trying to stretch the existing code which is
> really not designed for such purpose.

Well, we've come up with a better way (well, Mike Klar did from linux-vr)
to take care of weird c code, and allow everything to be normal.  (Special
elf sections, and twiddling with the linker script)  But in terms of
skipping around schedule.., it's not really a big deal.  You're right
though, it is an opportunity to slim down the code, and keep weird macros
out of MTD.  I was just thinking XIP kernel with flash stuff might be
usefull for MTD as a general thing, because people might want to take this
tact with various types of chips, etc.  I'm just going to finish the code,
and let you guys decide whether it's worth it to have it in MTD.  If it's
not worth it to have it as part of the files that are already in MTD, then
I can submit a seperate set of XIP versions of probing, etc.

Thanks,
Shane.



To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org