I guess it boils down to differentiation between architectural flaws
and more trivial code cleanup. I guess the thing that drew me to Christoph's
particular criticism was whether or not it is a flaw or a feature for
remapping layers to just be remapping layers and not also block devices.
If it is the concensus that remapping layers should also be block devices
then i concede. Although clearly there needs to be a little more reason
than having a device node to do an ioctl on.
> I have seen major subsystem rewrites. I have done several myself.
> I have also done more than a bit of wading through "yet another drivers".
> EVMS in its current state shows a lot of signs promising very painful
> work on cleanups and intergration. "Few cleanups after the freeze" doesn't
> come anywhere near the impression I'm getting from it and I would bet a lot
> on that particular impression.
Okay. It's just not clear which criticism are of the trival post merge
code cleanup kind, which are true architectural problems, and which are
singly held opinions on architectural requirements.
Can we have some concensus on whether intermediate remapping layers also need
to be exposed as block devices as this requiement would have a large impact
on the code.
From the discussion so far:
Pros
* Simplify ioctl routing to plugins
Cons
* Chew up a minor
* Get a block device we don't need or want (ie. we can still easily
directly access the underlying physical block devices)
* loose purely logical remapping abstraction in plugins
* Complicate mapping of request queues to devices (ie. shouldn't only
the top level volume device and the underlying physical devices need
request queues)
~mc
-
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/