[PATCH] nvmet: support reservation feature

[Keith Busch]

On Wed, Jan 10, 2024 at 11:19:20AM +0800, Guixin Liu wrote:
> 在 2024/1/10 01:01, Keith Busch 写道:
>
> > User space could be listening for them. The driver doesn't have any
> > particular action to take on a PR event just send a uevent.
>
> I will analyze which uevents need to be send and implement the
> notifications.

Sorry, there's a part missing from my reply. I mean the host driver
sends a uevent for unhandled AEN responses. The target doesn't do the
uevent; it just needs to send an appropriate AEN when applicable.

> > You're checking opcodes that we don't even support. I suggest we stash
> > the Command Effects Log in our target and trust what that reports to
> > deterimine if a command violates a reservation so that this function
> > doesn't need to be kept in sync as new opcodes are created.
> 
> You mean I should check the opcode is whether supported?
> 
> If I put the checking after validating the opcode, is this still needed？

What I meant was using effects to see if a command would violate a
reservation. For example, instead of explicitly defining a case for
opcode nvme_write_cmd, you can check the log page for the LBCC
attribute.