Exactly. I think Christoph is comparing it to the original md
architecture thich was more of an evolutionary design on the existing
block layer - it is merely an artifact of this that intermediary
devices were present (and consuming minors) - in a well architected
volume manager, this is not necessary or desirable - not presenting
the intermediary devices is IMHO also a saftey feature preventing
access to devices that shouldn't be accessed.
>> private structures that
>> need hacks to get the access right (pass-through ioctls) and need
>> constant resyncing with the native structures in the case where we
>> have both (the lowest layer).
>
>
> The point of contention is that EVMS does not provide generic access
> (block layer operations) to the components that make up the volume, but
> only to the user/system accessible volumes themselves. EVMS consumes
> (primarily disk) devices and produces volumes. The intermediate points
> are abstracted by the volume manager.
Yes, considering the abstraction (and the futureproofing this provides),
it would not make sense to bind these logical nodes to the orthogonal
block layer - which would probably also make maintenance more complex
in the future. I guess one of the advantages of the EVMS approach
is the ability for the core code to fit more easily with less changes
into kernels with differing block layers (2.4,2.5,future).
~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/