[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] Power-fail handling
Jim Law wrote:
Thanks for the place to look. I'm in the 2.4 kernel, and it looks like
emergency_sync() doesn't exist in linux/fs.h there. But I followed your
clue to look in drivers/char/sysrq.c and I see something that looks like
a earlier attempt at a "do_emergency_sync()" in the driver itself. I'll
study this for a while to see if I can figure out how this function gets
registered to be called back by the bdflush kernel thread.
From a quick scan the mechanism looks like this:
include/linux/sysrq.h defines CHECK_EMERGENCY_SYNC which is a small code
fragment to see if the mergency_sync is enabled, and if so vcalls it.
sysrq.c defines the tested variable and the function, as well as some
The only place in the kernel I find the CHECK_EMERGENCY_SYNC macro
referenced is in kernel/panic.c, basically during a kernel panic it
chekcs and maybe does a sync.
It seems this fairly generic functionality has been centralised in the
2.6 kernel, but you can lift much of the implementation from the sysrq
handler. Note you'll need to tweak the is_local_disk() function to
report that SystemACE is indeed a block device worthy of syncing, in the
kernel it just does IDE and SCSI drives by the look of it.
likely to be interrupt-safe in your opinion?
Honestly very hard to say. do_emergency_sync does grab the kernel lock,
not sure what will happen if that occurs during interrupt context.
Give it a try with non-critical stuff on the CF card, see what happens.
If it's not interrupt safe you'll probably get a BUG() or panic() to
tell you so.
Might also be worth floating this past LKML, although not suer how much
help you'll get on a 2.4-era question. uclinux-dev mailing list might
also be worth a try.
microblaze-uclinux mailing list
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/