I can't test that, so safe answer is to refuse to arm the oopser.
Since LBA is most common, that's my first priority.
> > The code always does a read sector then a write: if the sector doesn't
> > contain the right magic, it stops. But the more robust the better.
> You need a read-modify-write caller.
> You need to remember setfeatures need to be hammered on flushcache and
> writecache disabled.
> You need to be able to walk your buffer and best only if you do single
> sector transactions and not multimode.
> > Patches appreciated 8)
> I'll try, but time is tight for me.
Me too 8(. The oopser is allowed to (a) refuse to arm at arming time,
or (b) refuse to dump at dumping time, but it'd be nice if it worked
on the widest range of stuff possible (ie. CHS and LBA48 at least).
Of course, it can't use any external routines, and must be small too.
The IDE layer does a great job (on my hardware) from recovering after
we rudely steal the device from it, but no doubt the oopser could be
nicer about it.
Thanks for reading,
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/