Le Mon, 07 Feb 2011 12:09:39 -0800 vous Ãcriviez:
> Sorry, but I have no idea what you are talking about.
Sorry too, I'm just a typical target user, and I'm pretty confused.
> 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 configuration files are actually programs, because even a simple
bash script is a program. I'm getting uneasy. These are not your
regular, non executable config files.
> The whole idea is that configfs re-presents the parent/child
> relationships of data structures whose creation/deletion is driven by
> userspace.
Yes, this is the really good part, and I'll be eternally grateful for
this. Thank you.
> 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.
Please understand that at this point, anybody lacking a deep
understanding of kernel innards like me or 99.9% of linux system
admins or users, really don't give a fsck. I actually understand the
problem with using sysfs for that, but the fact is that from a
usability point of view this doesn't make a frigging difference, except
that we have another unfathomable virtual filesystem. We could do just
the same with /proc or /sys, and a startup script for either ietd or
scst or stgt, from the user POV.
So as long as the config is not really, completely automagically made
persistent by some in-kernel mechanism, this isn't any better than a
daemon loading a config file. In fact, it's worse, because it's more
unusual.
> 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.
You know, my first reaction was :
Aaaaargh. Are you trying to convince me that you've done the windows
registry right this time? I don't want no stinking object oriented
library to manage my scsi targets.
But finally, OK, I see the point for infrastructure. Now tell me, could
we avoid more virtual fs creep in the future ?
What bothers me is that I'm not sure you can make a Ferrari by bolting
new parts onto a Ford, or in this particular case importing Plan9
architectural features into the Linux kernel.
--
------------------------------------------------------------------------
Emmanuel Florac | Direction technique
| Intellique
| <eflorac@xxxxxxxxxxxxxx>
| +33 1 78 94 84 02
------------------------------------------------------------------------
--
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
