public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: <drobbins@gentoo.org>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Kernel-Modules
Date: Wed Feb  7 16:00:02 2001	[thread overview]
Message-ID: <20010207160001.A5763@cvs.gentoo.org> (raw)
In-Reply-To: <3A80CC65.2BC0D45C@gottinger.de>; from 320095285153-0001@t-online.de on Wed, Feb 07, 2001 at 05:17:42AM +0100

On Wed, Feb 07, 2001 at 05:17:42AM +0100, Achim Gottinger wrote:

> I give you a short information how we want to handle module
> configuration in the future.

The entire concept sounds very good, since it'll allow things to be
more automatic, but at the same time, this plan doesn't alienate
knowledgable users from their modules.conf.

> The modules.* files in /etc/moules can include preprocessor commands
> like
> 
> #IfModule ppp.o
> <definitions here>
> #EndIfModule

Couldn't the filename simply be "mod.ppp", and then the contents would be the
literal definitions to be added to modules.conf?  Then we don't need a parser.
Or do you want to be able to add more advanced functionality, such as nested
conditional statements?  If so, we may want to look into using "cpp" instead
of writing our own macro processor.

> So you can configure your modules dependend on the existance of a module.
> Something similar is planned for /etc/modules.devfs

Explain how you'd like to handle devfs?

> Additionally I will add a script that regenerates /etc/modules.conf in the
> way described above and runs depmod -a after that.  This script can be used
> from the commandline or from within packages pkg_postinst functions.

We could create a script called "mod-update" (companion to env-update and
rc-update).  Eventually, maybe we'll have an administration frontend called
gentoo-update :)

> This way of handling should make it in rc4.
> 
> Sould we make this method triggerable by a line in
> /etc/rc.d/config/basic ?
> 
> MODULES_CONF="yes" <-> MODULES_CONF="no"

We should call the option MOD_UPDATE (yes/no), or create an option called
UPDATE which contains a list of "auto"-features to update, for example:
UPDATE="mod env devfs"

Once the new modules system is working, I think it should be enabled by 
default.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			



      reply	other threads:[~2001-02-07 23:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-06 21:44 [gentoo-dev] Kernel-Modules Achim Gottinger
2001-02-07 16:00 ` drobbins [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010207160001.A5763@cvs.gentoo.org \
    --to=drobbins@gentoo.org \
    --cc=gentoo-dev@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox