Btw, simple reminder that all this has zero chance of going upstream
until someone addresses the issue of a proper API for locking down the
device mappings and getting the final block mapping in kernelspace.
On Fri, Jun 04, 2010 at 02:25:06PM -0400, Christoph Hellwig wrote:
> Btw, simple reminder that all this has zero chance of going upstream
> until someone addresses the issue of a proper API for locking down the
> device mappings and getting the final block mapping in kernelspace.
Do you have any more details on the issue? (Reference to a previous
thread?)
My (probably faulty) understanding of the the basic idea of the patches:
a list of block signatures and a description of the desired topology is
passed up to a userspace daemon, and the daemon cobbles together a
device and passes down device major/minor numbers for the result.
Are major/minor numbers the right way to hand off the device? (And what
do you mean by "locking down the device mappings"? Is there a
possibility the device can be destroyed while the kernel's using it?)
--b.
On Fri, 04 Jun 2010 14:25:06 -0400, Christoph Hellwig <[email protected]=
g> =20
wrote:
> Btw, simple reminder that all this has zero chance of going upstream
> until someone addresses the issue of a proper API for locking down th=
e
> device mappings and getting the final block mapping in kernelspace.
Remember our discussion of 2 years ago. :)
>
>
>
--=20
Best Regards
Sorin Faibish
Corporate Distinguished Engineer
Network Storage Group
EMC=B2
where information lives
Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : [email protected]