mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Eric Piel <eric.piel@tremplin-utc.net>
Cc: Christoph Hellwig <hch@lst.de>,
	dsdt@gaugusch.at, len.brown@intel.com,
	linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>,
	trenn@suse.de
Subject: Re: acpi dsts loading and populate_rootfs
Date: Tue, 12 Feb 2008 06:37:30 +0100	[thread overview]
Message-ID: <20080212053730.GA15347@lst.de> (raw)
In-Reply-To: <47AEE6D1.4070402@tremplin-utc.net>

[skipping the populate_rootfs discussion as it seems you have a better
 handle on that than me]

On Sun, Feb 10, 2008 at 12:58:09PM +0100, Eric Piel wrote:
> >And while we're at it the file reading thing in there is utter crap
> >aswell.  You really should be using the firmware loader which works
> >perfectly fine if you initramfs is set up for it.  So please folks,
> >back to the drawing board, do it properly and send it out to lkml
> >for review please.
> Christoph, if you have seen this part of the code, you have probably 
> also read the big fat warning explaining why this cannot be done by 
> firmware loader (ie: userspace cannot be run at this early time, 
> corresponding to acpi_early_init()). However, you probably know the 
> kernel ten times better than me. Could you explain what I misunderstood 
> when writing this warning, and give me some hints about how to use the 
> firmware loader in this case?

Sorry, I misparsed the comment.  I took it for the usual I'm too lazy
to put something that could load firmware into initramfs excuse.

But thinking about it is there a reason acpi initialization needs to
happen so early that we can't even have userspace in initramfs running?

But if we can't use real userspace this could should at least be written
like the pseudo-userspace in init/do_mounts*.c, using the sys_ syscall
implementations.

As an additional comment the stat + open approach is racy and not a good
idea.  Please just open the file using sys_open, it will tell you
if the file doesn't exist and then use fstat on it to find the
length.  It would also be useful if this kind of code is not hidden
inside acpi but rather done somewhere close to the early init code
because that's where people would expect this kind of nastiness._
syscall
implementations.

As an additional comment the stat + open approach is racy and not a good
idea.  Please just open the file using sys_open, it will tell you
if the file doesn't exist and then use fstat on it to find the
length.  It would also be useful if this kind of code is not hidden
inside acpi but rather done somewhere close to the early init code
because that's where people would expect this kind of nastiness.

  parent reply	other threads:[~2008-02-12  5:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-10  7:12 Christoph Hellwig
2008-02-10  7:14 ` Christoph Hellwig
2008-02-10 11:58   ` Eric Piel
2008-02-11 13:47     ` Sergey Vlasov
2008-02-11 23:41       ` Éric Piel
2008-02-21 19:02         ` [PATCH] Allow populate_rootfs() to be called early (was: acpi dsts loading and populate_rootfs) Éric Piel
2008-02-21 19:04           ` Christoph Hellwig
2008-02-21 21:27             ` [PATCH] Allow populate_rootfs() to be called early Éric Piel
2008-02-23 19:40           ` [PATCH] Allow populate_rootfs() to be called early (resent, with sob) Éric Piel
2008-02-12  5:37     ` Christoph Hellwig [this message]
2008-02-21 18:46       ` acpi dsts loading and populate_rootfs Éric Piel
2008-02-22  8:51         ` Thomas Renninger
2008-02-22  9:05           ` Thomas Renninger
2008-02-22  9:53           ` Andi Kleen
2008-02-23 19:34         ` [PATCH] Use userland-like functions for reading the ACPI table Éric Piel
2008-02-23 20:45           ` Linus Torvalds
2008-02-24  1:31             ` Christoph Hellwig
2008-02-24 19:02               ` Éric Piel

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=20080212053730.GA15347@lst.de \
    --to=hch@lst.de \
    --cc=dsdt@gaugusch.at \
    --cc=eric.piel@tremplin-utc.net \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=trenn@suse.de \
    /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

all inboxes | Powered by JetHome®