All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Aloni <da-x@monatomic.org>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>,
	Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] allow kernel module exclusion on load
Date: Sun, 13 May 2007 21:22:26 +0300	[thread overview]
Message-ID: <20070513182226.GA8658@localdomain> (raw)
In-Reply-To: <46475324.7050303@msgid.tls.msk.ru>

On Sun, May 13, 2007 at 10:04:20PM +0400, Michael Tokarev wrote:
> There are two issues (IMHO anyway), both are userspace.
> 
> First is the ability blacklist the given module from bootloader.
> My initramfs has it since the beginning - it allows a noload=xxx
> paramerer (comma-separated list of module patterns, cumulative),
> for exactly this purpose.  I implemented modprobe in shell (not
> using a binary from module-init-tools) for initramfs (it's some
> 20 lines of shell code).  Because of exactly that reason - on
> certain systems i had a problem with certain drivers, resulting
> in boot failures.  Later on, this set of modules gets transformed
> into a modprobe blacklist list.  It's trivial to do.
> 
> And second is what to do with direct insmod invocations in minimal
> embedded system startup sequence.  Well, minimal it or not, but
> shell is present anyhow, so I don't see any problem with that,
> either...

Yes, I guess a shell script can always look at /proc/cmdline with
relatively minimal complexity.

Anyway, it all boils down to whether there's a developer demand 
for a userspace-independent way of blacklisting modules. Let's see 
if more people post their opinion so we can determine.

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il

  reply	other threads:[~2007-05-13 18:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-13 13:25 [PATCH] allow kernel module exclusion on load Dan Aloni
2007-05-13 16:23 ` Stephen Hemminger
2007-05-13 17:05   ` Nikita V. Youshchenko
2007-05-13 17:15   ` Dan Aloni
2007-05-13 18:04     ` Michael Tokarev
2007-05-13 18:22       ` Dan Aloni [this message]
2007-05-13 18:32         ` Michael Tokarev
2007-05-13 18:20   ` Christoph Hellwig
2007-05-13 18:39     ` Michael Tokarev
2007-05-15  8:23     ` Pavel Machek
2007-05-16 16:51       ` Dan Aloni
2007-05-16 19:33         ` Pavel Machek
2007-05-16 21:09           ` Dan Aloni
2007-05-16 22:00             ` Randy Dunlap
2007-05-15 13:07     ` Andi Kleen
2007-05-14 20:23 ` Valdis.Kletnieks
2007-05-15  8:48   ` Dan Aloni

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=20070513182226.GA8658@localdomain \
    --to=da-x@monatomic.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    --cc=shemminger@linux-foundation.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.