Bill Studenmund <wrstuden@netbsd.org> writes:

> On Tue, Apr 11, 2006 at 07:51:40AM +1000, Daniel Carosone wrote:
>> On Mon, Apr 10, 2006 at 01:12:54PM -0700, Bill Studenmund wrote:
>> > 3) Make some layer further up the chain do the checking. The idea is that 
>> > devices that support FUA would somehow announce this, and code further up 
>> > the i/o stack will test and flag an error if needed. Issue here is how do 
>> > we announce this. I don't think we annoucne such things now, so this idea 
>> > would mean adding more infrastructure.
>> 
>> As well as the additional infrastructure, 3 sounds like it would need
>> ~as much rototillage as 2, since each driver would still have to know
>> and announce its capability - regardless of whether via an error path
>> or a config-time path.
>
> Not really. If we hook the code into the "right" layer, we can set stuff 
> up on open. And devices that can't do this can just error out however we 
> get the info (probably an ioctl).

My first reaction was that options 2 and 3 were reasonable and it was
a work tradeoff.  But also option 3 means that the next disk option is
easier, whereas option 2 doesn't help that goal.

I think erroring when FUA isn't available and leaving workarounds for
further study is a reasonable plan.  It seems people and programs
using FUA will be in the clueful/paying attention category, and the
program could even use a fallback method of some sort.

-- 
        Greg Troxel <gdt@ir.bbn.com>