The User Level Functionality can make use of an interface to this kernel Module, like an file. This is much more efficient as it o(1) rather than An nxo(n) like yours.
I guess if you can repost this project it will be much better with some Added documentation on the linux part of it. Thx, Sujit K M -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cyril Plisko Sent: Friday, December 07, 2007 12:46 AM To: Sujit Karataparambil Cc: [email protected] Subject: Re: [storage-discuss] FW: Project Proposal: Device Mapper 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
