> Is there anyone out there who is going to argue against using an fs
> interface when I submit it ? Speak now or forever hold your peace !
>
> If dm now misses the feature freeze deadline due to this extra work,
> is it going to be possible to still place it in 2.5 at a later date ?
> (dm with an ioctl interface is better than no dm at all).
How would the fs based interface work ?
plan9 style echo 'rename foo bla' > /dmfs/command would seem ugly to me
(just look at the horrible parser code for that in mtrr.c)
doing it fully as fs objects (mv /dmfs/volume1 /dmfs/volume2 for rename)
could likely get complicated and it's doubtful that VFS semantics completely
map to DM volumes.
Unless you have a clear and simple way to handle these issues I would
suggest to stay with simple ioctls. They look clean enough.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/