qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Fisher" <desnotes@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Hardware Detection in Qemu
Date: Mon, 9 Jul 2007 09:15:52 -0400	[thread overview]
Message-ID: <3461d5200707090615l2b550972h81523a5f9a62ac77@mail.gmail.com> (raw)
In-Reply-To: <46d6db660707090509k52697238tb937ead7111c34a1@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2068 bytes --]

Thanks...I am working with a couple of distros I want to modify so they will
boot faster on QEMU and also utilize persistence. Customizing the
/etc/init.d/* scripts will be my next step.

On 7/9/07, Christian MICHON <christian.michon@gmail.com> wrote:
>
> On 7/8/07, Michael Fisher <desnotes@gmail.com> wrote:
> > I have run various live Linux CD distributions (Knoppix, DSL, Ubuntu,
> etc.)
> > under QEMU and was wondering if there is really a need to run the
> various
> > hardware detection scripts in the live CDs? Obviously, a script for
> getting
> > an IP address is needed but if I know I am running the distro under
> QEMU, do
> > I need to check for USB, SCSI, AGP, PCI and the other detection scripts?
> >
>
> in short: no, you don't need so much hardware detection.
>
> > If QEMU is already doing that, can't I just tweak the live distro to
> match
> > QEMU and then let QEMU do the work when it is placed on various host
> > computers?
>
> if you're targetting a specific version of qemu, on which hardware's list
> is specified/frozen, then yes, it's best to custom each of your linux
> guest to speed up the boot sequence.
>
> I see 3 ways:
>
> 1) by command line: you can add parameters like noacpi, tweak the
> ide probes, etc... slax and dsl give you quite a good list to start
> with...
>
> 2) by customizing the /etc/init.d/* scripts, and re-authorizing the iso
> If you do this, you've to keep in mind the new iso is for your guests
> only...
>
> 3) use DetaolB. It's one of the many reasons why I created it. :)
> Seriously, you create your own distro. The trick is in getting the
> init scripts to as little as possible, and putting all needed hardware
> modules *only* in your vmlinux, thus removing modprobing, which
> actually takes quite a lot of time when inside qemu.
>
> > Currently, most of my testing is done using Win XP as the host but in
> the
> > future I will be looking at Linux and Macs as hosts also.
>
> I'm in the same situation.
>
> --
> Christian
> --
> http://detaolb.sourceforge.net/, a linux distribution for Qemu
>
>
>

[-- Attachment #2: Type: text/html, Size: 2649 bytes --]

  reply	other threads:[~2007-07-09 13:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-08 12:34 [Qemu-devel] Hardware Detection in Qemu Michael Fisher
2007-07-09 12:09 ` Christian MICHON
2007-07-09 13:15   ` Michael Fisher [this message]
2007-07-09 13:38     ` Christian MICHON
  -- strict thread matches above, loose matches on Subject: below --
2007-07-09 13:33 wangji
2007-07-09 13:39 ` Christian MICHON

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=3461d5200707090615l2b550972h81523a5f9a62ac77@mail.gmail.com \
    --to=desnotes@gmail.com \
    --cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).