Message-ID: <003c01c1cddf$f9fdb780$7e0aa8c0@bridge>
From: "Jeremy Jackson" <jerj@coplanar.net>
To: <linux-kernel@vger.kernel.org>
Subject: New commandline parsing framework
Date: Sun, 17 Mar 2002 10:17:16 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

Hi linux-kernel,

In looking through the IDE hotswap support (2.5.6), it occurred to me that
having a static array big enough to hold all possibly interfaces, is,
um, inelegant, when you start adding and removing devices.  This is common
with many things.

Looking furthur, I see that this is because the structures must
exist when the command line is parsed, and that's done ahead
of the IDE module's init, before kmalloc is available.

__setup("",ide_setup); is called by __parse_options() in main.c by
start_kernel()

Of course the mm subsys needs access to cmdline args.  But *most* other
sys don't.  So they shouldn't *have* to be able to parse here.  Forcing them
to means they must use fixed sized arrays in bss segment, not kmalloc et al.

I have almost completed a patch which moves the IDE module's cmdline
parsing into the module's init routine, allowing the hwif structure to
become an linked list of hwif_t structures, kmalloced or slab
construced/freed as needed.  It simply copies the options it's given into an
__initdata
buffer, delaying parsing them until ide.c:init_ata().  Of course it could
just
use the saved_command_line[], as could everyone.

Question: are there any problems with using this approach in general?

* extra pointer derefrence (linked list vs static array indexing)
performance issue?

Perks:

* slab cache constructor could fill in what's currently initialized data
* backwards compatibility is easy to provide
* may be incrementally/optionally adopted in drivers in kernel tree and
outside
* old interface may be removed easily at some time in future
* drivers can unify boot cmdline and module load options parsing,
   reducing complexity and code size
* eases removal of legacy support (ie don't probe, just use PCI config
  data and allocate one hwif for each one found)
* each subsys is more self-contained. cleaner code.

I propose to create a patch which makes main.c:checksetup() more of a
library function, with __setup being used only by subsystems that
require
command line parsing at the current early point.  Others can call
checksetup(saved_command_line, __setup-like-list-of-my-argnames);
in their main init routine.  the /sbin/init env/arg construction could
be
delayed until the init thread is started.

things like serial driver (when serial console support is selected)
could simply start their linked list with one statically allocated,
and add others in later, so they can still be initialized early on.

I think I've figured out the side effects but I'm looking for some more
experienced advice.

Thanks,

Jeremy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/