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.
This can be done in a much more efficient way by
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.
Thanks for some suggestions,
Sujit K M
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Cyril Plisko
Sent: Thursday, December 06, 2007 2:22 AM
To: Sujit Karataparambil
Cc: [email protected]
Subject: Re: [storage-discuss] FW: Project Proposal: Device Mapper
Sujit,
On Dec 4, 2007 2:19 PM, Sujit Karataparambil
<[EMAIL PROTECTED]> wrote:
>
> Actually in Solaris(8/9/10) We have Something an Modular Kernel/Multi
> Threaded Kernel That Allows File Systems to be stacked over an Volume
> Manager. So we Have something for example like Veritas Volume Manager
> In the case of Certain Storage Device Based on an particular vendor.
> What clarification requirement for this proposal is that is it an
> Generic
> Interface to be added as C/C++ routine, Which would solve the problem
> Of an Modular/Multithreaded kernel or an hands modification of each of
> These volume managers.
Frankly speaking I am not sure I completely understand your question,
but let us see.
The current plan is to have
1. kernel device mapping facility which exports standard interface
(ioctl)
to the user-land.
2. user-land library which consumes said ioctl interface and provides a
C API.
3. utility which provides command line access to device mapper facility
Does that answer your question ?
--
Regards,
Cyril
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
