All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Sokolovsky <pmiscml@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC] Revamp module handling in OE
Date: Tue, 24 Jul 2007 00:54:33 +0300	[thread overview]
Message-ID: <86855446.20070724005433@gmail.com> (raw)
In-Reply-To: <77326513.20070720105101@gmail.com>

Hello OpenEmbedded,

Friday, July 20, 2007, 10:51:01 AM, you wrote:

> Hello openembedded-devel,

>   We have few issues with kernel module handling in OE which I'd like
> to bring to attention and discuss ways to resolve.

> 1. Module config option handling was not upgraded since 2.4.

> This is known issue, it surfaced several times already, and we
> discussed ways to solve it with Graeme Gregory on IRC recently. The
> issue is that OE currently writes module config options where 2.4
> modutils expect them (/etc/modutils/*.conf), not where 2.6
> module-init-tools do (/etc/modprobe.d/*.conf). The patch is at
> http://bugs.openembedded.org/show_bug.cgi?id=2669

  I got confirmation from Graeme that it works ok, so I'd like to
commit this tomorrow night.


> 2. Location of module autoload config.

> Module autoload is rather different feature. It actually never was
> part of modutils/module-init-tools, but is done via adhoc scripts per
> some distro's convention. Relatively randomly OE uses the same
> /etc/modutils dir to store that info (just in files w/o extension).
> Per-module data is then collated into /etc/modules file, and *that*
> file is Debian convention. But AFAICT, that file is supposed to
> contain local user's selection of autoload modules, whereas OE
> automatically overwrites it. Of course, this information rather be
> checked by people with more Debian background. Either way, at least
> following issues can be identified:

> 1. Location of per-module autoload data: /etc/modutils/ is rather
> confusing place for this, especially if we switch to 2.6 way.
> 2. /etc/modules is supposedly a user file.

> One of the possible solutions: if a file is named /etc/modules, then
> it's natural to name dir /etc/modules.d/ . If data from it would need
> to be collated, that would go to some /etc/modules.foo, leaving
> /etc/modules intact. FInally, both contents of files and dri would be
> taken into account.


  I hope that people are fully back from GUADEC now and can give this
some thought ;-).


> Thoughts?




-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com




      reply	other threads:[~2007-07-23 21:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-20  7:51 [RFC] Revamp module handling in OE Paul Sokolovsky
2007-07-23 21:54 ` Paul Sokolovsky [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=86855446.20070724005433@gmail.com \
    --to=pmiscml@gmail.com \
    --cc=openembedded-devel@lists.openembedded.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.