>From my understanding of fs/proc/array.c, the array_read function grabs a
page of memory with the call to __get_free_page. This says to me that all
of the buffers handled in that manner can only contain one page of data.
> > quite some time. My implementation goes a step further and actually
> > implements file operations for this which can handle arbitrarily large
> > files, as you'll see in #2). As more and more features get added, this
> > may be an issue eventually.
>
> But my full config < 1K. You are preparing for more than 4 times that?
> Surely this is something to mend later, not now.
I don't know if I agree with that. Not being familiar with the number of
configuration options on all of the platforms and seeing how much things
have changed in the past 2 years (just look at the number of network
config items!), I'd rather have something in place from the get-go that is
less likely to break as more and more configuration options are added.
> > 2) My implementation also copies into itself the System.map *ONLY* if it
> > is compiled as a module.
>
> I can't see any sense in using a module for the config functionality,
> unfortunately. The module may not match the kernel.
True. On retrospect that may be something that I remove completely for
that reason -- I am going to be doing some tests to see if that can be
fixed in the module or not.
> Whilst this is good stuff, as an engineer I'd say "keep it simple to
> start with". Put these extra things in later, only if you need to. At
> the moment this all sounds heavyweight.
Well, I'd say that if the consensus is that each architecture's
configuration options won't exceed that same arch's page size when
compressed, then go with the other implementation for its simplicity.
If the ability to free up that memory after boot is desired, then I
believe that an implementation similar to mine will need to be used -- I
did not see any easy way to free up the memory using the array_read style
entries.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Andrew Anderson http://amelia.db.erau.edu/~andrew/
if(!(family_tree=fork())){redneck=TRUE;}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu