On Mon, 2011-02-07 at 16:02 +0100, Emmanuel Florac wrote: > Le Mon, 07 Feb 2011 08:41:49 -0600 > James Bottomley <James.Bottomley@xxxxxxx> Ãcrivait: > > > I think the overall philosophical point here, and it's a good one > > because I've heard it from several sources, is that it's not possible > > to separate configuration from status completely. > > This would be true only if the machines weren't ever rebooted. Out of > this uncommon case, this is even worse than the previous state of the > matter : instead of having a (eventually nice, human readable) > configuration file, you need a real program to create dynamically the > devices at boot time, which is therefore your ACTUAL configuration > file. So all you're achieving with this philosophy is replacing data > files by programs -- anyone but kernel programmers will find this a > terrible idea. > > Then to avoid the hassle, someone will have the clever idea to build a > way to load an INI file into configfs through a specially crafted > program living in /etc/init.d, and we'll have been going full circle. > Slow clap... This is the most brain-dead idea I've heard of in a long > time. > Sorry, but I have no idea what you are talking about. We use direct configfs mkdirs and symlinks in our configuration files. There are special cases where we use lio-utils.git python code to load additional backend device specific metadata (like T10 WWN, persistent reservations APTPL, ALUA multipath secondary port state, etc) The whole idea is that configfs re-presents the parent/child relationships of data structures who's creation/deletion is driven by userspace. Having python code walk this layout and output the exact running configuration is how we save -> reinstate the running config, and it's really quite trivial with configfs. But that is just the simple stuff, where configfs really shines is with a object oriented library and high level interactive shell that allows the configfs hierarchy to be fully utilized by application level programmers and end-user administrators. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
