forgive the lack of threading, I missed this yesterday and just found this via
the LWN article.
I like the general approach that you are taking of simplifying the interface,
however in your interest of making it easy to write C code for you are making
the new interface difficult to script for. is it really that painful to to make
everything file based so that it can be scripted as well?
frankly, most sysadmins do a lot of scripting and almost no C coding, so while
a nice C interface is useful for creating tools, a good scripting interface is
critical for good, flexible use by sysadmins.
David Lang
On Wednesday 05 March 2008 18:30, you wrote:
> forgive the lack of threading, I missed this yesterday and just found this
> via the LWN article.
>
> I like the general approach that you are taking of simplifying the
> interface, however in your interest of making it easy to write C code for
> you are making the new interface difficult to script for. is it really
> that painful to to make everything file based so that it can be scripted
> as well?
>
> frankly, most sysadmins do a lot of scripting and almost no C coding, so
> while a nice C interface is useful for creating tools, a good scripting
> interface is critical for good, flexible use by sysadmins.
Hi David,
Scripting is already taken care of by the ddsetup utility (a compatible
rewrite of dmsetup) which is just a shell to the ddlink interface. You
would not want to put the "value add" of dmsetup into kernel. All that
parsing and massaging belongs in user space. If there are more scripting
features you need, they should be added to dmsetup/ddsetup, not to the
kernel.
Scripting device mapper has never actually posed a problem. The real
problem is, there is no nice way to write a C program to do fancy
volume management, so we don't see the advanced features appearing on
Linux at anything like the rate they have appeared on Solaris.
Daniel