Joel wrote:
> Sure, no dispute here. My argument point isn't that "vector of
> scalars is inherently evil" (I'll leave that aside), it's that a
> facility allowing or encouraging the format change or blowup is
> unhealthy.
Ok ... yes simply extending the size is changing the protocol
at too low a level ... an invitation to future abuse. I'll agree
somewhat with your concern there.
Is there some way to accept an array of scalars? Some change
in the API that configfs presents to the kernel code using it,
that would let that code say "here's an array of u32, of length
so-and-so?"
Hmmm ... having spouted off for three messages now ... decided to
actually look at this ;).
Let me consider a different approach ...
At the top of Documentation/filesystems/configfs/configfs.txt,
I see:
configfs is a ram-based filesystem that provides the converse of
sysfs's functionality. Where sysfs is a filesystem-based view of
kernel objects, configfs is a filesystem-based manager of kernel
objects, or config_items.
I guess this means that sysfs presents the gauges, and configfs
the knobs.
This seems like a bit of an artificial split to me - view (mostly
read) here, and manage (mostly write) here.
Not entirely surprisingly, I'm fond of the cpuset approach -- all
things cpuset-related in one place, both viewing and managing.
Similarly, /proc is a repository for all things task related, and
/dev for all devices (well, with various exceptions, contradictions,
confusions, and historical raisins ...)
There should indeed be a place for various kernel guages and knobs that
don't merit having their own entire file system. And since we already
have a separate sysfs and configfs, better to leave that aspect be, as
two separate name spaces ... despite my rant about this being an
artificial split a few lines above.
And if configfs wants to (continue to) impose a rule that there is a
single, simple scalar per file, that may well fit its needs and guide
its future extensions in the best way.
But if something like Resource Groups comes along, I'd think it deserves
its own file system name space (though sometimes I am sympathetic to
suggestions to merge this one into the cpuset name space -- not sure.)
Underneath each of these filesystems, sysfs, configfs, cpuset, resource
groups, ... it would seem ideal if we had a single kernel file system
infrastructure. Actually, we're only a half a layer from having that,
with vfs. It just takes a fair bit of glue to construct any of these
file systems out of vfs primitives.
I wonder if there might be someway to share that glue? I am envisioning
a new glue layer, mostly in the kernel internal headers and lib
directory, that sits on top of the current vfs, and makes it easy for
virtual file system presenters such as sysfs, configfs, cpusets and
resource groups to construct the particular virtual file system they
require.
I would expect this glue layer to support vectors of scalars, even if
some of its users, such as configfs, chose not to expose that
possibility. Arguments between configfs and resource group developers
over the value of presenting vectors suggest we've gone astray -
enforcing commonality where it is not beneficial to do so.
I would not expect such a change to using common vfs glue to change
much, if at all, existing client kernel code that uses configfs or
sysfs (or cpusets.) The configfs example code in:
Documentation/filesystems/configfs/configfs_example.c
should continue to work, as is.
I would expect to reduce a little some cut and paste code duplication,
hence reduce the kernel text size and reduce kernel maintenance and
improve a little the ease with which future features (Resource Groups,
say) can add their own virtual file system hierarchies.
This means creating a new kernel internal API, by which the various
clients (sysfs, configfs, cpusets, ...) of this common glue layer can
represent the particular instance of such a virtual file system that
they require, and hook in their operational methods. Then it means
porting the existing such virtual file systems, such as configfs, sysfs
and cpusets, to this common glue infrastructure.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
