--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Ok, so I would like input on one more aspect of letting userland request=20
FUA. What do we do if the device/bus interface doesn't understand FUA?

Now for SCSI, we will just set FUA in the CDB. If the device doesn't=20
support it, it will (well, should) reject the command.

The question is what do we do with busses (like ATA) that, AFAIK, don't
natively understand FUA. In addition to ATA, another candidate would be
RAID cards where you can't request FUA functionality.

I see three options:

1) We don't worry about it. This point isn't so good as userland wanted=20
FUA, and didn't get it. Yet it was told the operation conpleted. So we're=
=20
lying. :-)

2) Make every device driver know about FUA and report an error if it's set=
=20
and not supported. Drawback is it's a lot of rototilage.

3) Make some layer further up the chain do the checking. The idea is that=
=20
devices that support FUA would somehow announce this, and code further up=
=20
the i/o stack will test and flag an error if needed. Issue here is how do=
=20
we announce this. I don't think we annoucne such things now, so this idea=
=20
would mean adding more infrastructure.

Take care,

Bill

--y0ulUmNC+osPPQO6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEOrxGWz+3JHUci9cRAgK/AKCS5y5dQT/q090YwnqA3FrHB/rVZgCfX2QV
N2kmBrNFkQ/JIsSAvB9UbR8=
=I5BR
-----END PGP SIGNATURE-----

--y0ulUmNC+osPPQO6--