[dm-devel] [RFC] Message ioctl direct to device

[Daniel Phillips]

On Friday 09 July 2004 17:05, Alasdair G Kergon wrote:
> On Fri, Jul 09, 2004 at 04:16:32PM -0400, Daniel Phillips wrote:
> > Let's work though this nice and slowly please.  You're saying that
> > LVM2 can go change the table, e.g., by inserting a mirror for
> > pvmove, at any time.
>
> Yes.  Applications like LVM2 should be free to insert new layers &
> split targets up whenever they want.
>
> > But if that happens, we can end sending the message to the wrong
> > target (e.g., a temporary mirror instead of the snapshot target)
>
> This is one of the complexities still to be worked out: how we
> see that the message (ie the ioctl "payload") gets passed on down
> to the right layer.
>
> If it's done by index and there are multiple layers - no chance.
> If it's done by sector, I think it's possible.
> And it probably requires that the "payload" strings conform to a
> standard too, so that the right target knows to intercept them.
>
> [There are alternative approaches; intend to explore each of them
> before making decisions.]

OK, we're on the same page now.  The answer is: neither works, back to 
the drawing board.  I'll throw out a couple of suggestions:

  1) libdevmapper tells kernel dm about any temporary changes it makes,
     so that dm can automatically route a message to the correct target.
     The application indexes the target as now (index or sector,
     whichever ultimately wins the good taste sweepstakes); libdevmapper
     and dm cooperate to figure out what that is really supposed to
     mean.

  2) Each _target_ has a unique handle which an application can get
     hold of at create time and use later to message the target.

There are structural reasons why we might prefer the latter.  Each 
target is really trying to be a for-real block device internally, and 
in that direction lies great promise for further simplification of the 
dm kernel component.  I have a feeling that the second approach will 
win by a wide margin in terms of code size and robustness.

Regards,

Daniel