public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: David Lang <david.lang@digitalinsight.com>
Cc: Alexander Viro <viro@math.psu.edu>,
	Kevin Corry <corryk@us.ibm.com>,
	linux-kernel@vger.kernel.org, evms-devel@lists.sourceforge.net,
	torvalds@transmeta.com
Subject: Re: EVMS Submission for 2.5
Date: Thu, 3 Oct 2002 10:27:28 -0700	[thread overview]
Message-ID: <20021003172728.GD403@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0210030953130.30836-100000@dlang.diginsite.com>

On Thu, Oct 03, 2002 at 10:00:29AM -0700, David Lang wrote:
> Greg, please note that while there are people planning to change the
> kernel to require an initramfs to boot on any machine, there are a number
> of people who disagree with this approach, since the initramfs changes to
> make it possible to be mandatory are not in the kernel yet (let alone the
> flame war^H^H^H^H^H^H^H^H^Hdiscussion that will take place before
> initramfs is made mandatory) you can't tell Kevin to build his code in
> such a way that it only works if you have it.
> 
> once initramfs is to the point where it can be made mandatory, then if
> Linus states that he wants to mandate drivers as modules useing initramfs,
> then you can tell new drivers they can't be compiled in and can depend on
> userspace tools like /sbin/hotplug.

Hm, I think you're a bit confused here.

/sbin/hotplug has nothing to do with modules.  It works just fine with a
kernel with everything built in.  /sin/hotplug is getting called when
anything in the system changes, like a device is discovered or removed.

Now the fact that the current hotplug package that implements a version
of /sbin/hotplug only really handles loading new modules for devices
that do not currently have drivers bound to them, is only an
implementation detail.  The hotplug package will start to change soon,
based on the new information that is being spit out by your kernel.

> given that we had a patch a week or so ago to change how modules get
> loaded into memory to avoid a 'several percentage point' speed difference
> between modules and built-in and that the people pushing 'do everything in
> initramfs' have been saying for years that there is no performance
> difference I for one am not convinced that mandating initramfs is a good
> thing.

initramfs and "everything must be a module" are two different
discussions.  Only after the first happens can we even start talking
about the second.

And even if we don't ever agree that everything has to be a module, the
initramfs implementation moves a whole lot of crap out of kernel space,
and into userspace, that I can't see any good reason not to have it.

But let's wait for Al's latest initramfs patches to start talking about
that topic, I thought this thread was about evms :)

thanks,

greg k-h

  reply	other threads:[~2002-10-03 17:25 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-02 21:33 EVMS Submission for 2.5 Kevin Corry
2002-10-02 22:14 ` Alexander Viro
2002-10-02 22:03   ` Kevin Corry
2002-10-02 23:02     ` Alexander Viro
2002-10-03 13:04       ` Kevin Corry
2002-10-03 14:51         ` Alexander Viro
2002-10-03 14:53           ` Kevin Corry
2002-10-03 15:37             ` Alexander Viro
2002-10-03 16:13           ` Greg KH
2002-10-03 16:21             ` Alexander Viro
2002-10-03 16:30               ` Greg KH
2002-10-03 17:00                 ` David Lang
2002-10-03 17:27                   ` Greg KH [this message]
2002-10-03 19:52                 ` [Evms-devel] " Oliver Neukum
2002-10-03 21:37                   ` Greg KH
2002-10-03 21:02                     ` Oliver Neukum
2002-10-03 22:56                       ` Greg KH
2002-10-03 23:03                         ` Alexander Viro
2002-10-04  8:07                         ` Oliver Neukum
2002-10-05  0:06                           ` Greg KH
2002-10-03 16:55           ` Patrick Mochel
2002-10-03 19:24           ` Linus Torvalds
2002-10-02 22:27   ` Shawn
2002-10-02 22:19 ` Shawn
2002-10-02 22:43 ` Greg KH
2002-10-03 12:13   ` Kevin Corry
2002-10-03 16:23     ` Greg KH
2002-10-03 16:51       ` Linus Torvalds
2002-10-03 21:56   ` Kevin Corry
2002-10-03 23:07     ` Greg KH
2002-10-04  0:39       ` Kevin Corry
2002-10-04 13:06         ` Alan Cox
2002-10-04 13:07           ` [Evms-devel] " Kevin Corry
2002-10-04 17:29             ` Kai Henningsen
2002-10-03 14:32 ` Christoph Hellwig
2002-10-03 14:59   ` [Evms-devel] " Michael Clark
2002-10-03 15:08     ` Christoph Hellwig
2002-10-03 15:03   ` Shawn
2002-10-03 15:31     ` Christoph Hellwig
2002-10-03 15:41       ` [Evms-devel] " Mike Tran

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=20021003172728.GD403@kroah.com \
    --to=greg@kroah.com \
    --cc=corryk@us.ibm.com \
    --cc=david.lang@digitalinsight.com \
    --cc=evms-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    --cc=viro@math.psu.edu \
    /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