On Dec 6, 2007 5:54 AM, Sujit Karataparambil
<[EMAIL PROTECTED]> wrote:
>
> Why Do it as an ioctl is my question? That is do it at the driver level.
> This is not feasible, as the Volume Manager for interoperability with
> LVM
> Or for any other Volume Manager would require you to Have Generic set of
> Interfaces to it.
ioctl()-based interface is a traditional way of exporting non-standard kernel
functionality to the user-land. Since the goal of this project is to have
a compatible or similar interface to Linux device-mapper facility ioctl
seems to be natural choice.
> This can be done in a much more efficient way by
I really do no agree with "much more efficient" part.
> 1. Having an Kernel Level Structure and Register Functionality.
> a. struct io_device_map{//}
> b. register_device_name() function
> c. register_device_type() function
> d. export_device_name() function
> e. export_device_type() function
> f. un_register_device_name() function
> g. un_register_device_type() function
> 2. Register the Filesystem and Related Driver with these
> functionalities.
> 3. get device name or type from an Kernel Module.
What kind of consumer would be for such an API ?
I mean you would still need some user-level controlling
API at the other end. So why have an intermediate layer
at all ?
--
Regards,
Cyril
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
