All of lore.kernel.org
 help / color / mirror / Atom feed
* paravirt-dom0: ACPI_PROCESSOR_XEN (bool) depends on ACPI_PROCESSOR (tristate)
@ 2009-10-05  2:16 Bastian Blank
  2009-10-08 15:25 ` Bastian Blank
  0 siblings, 1 reply; 3+ messages in thread
From: Bastian Blank @ 2009-10-05  2:16 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: xen-devel

Hi

The paravirt-dom0 kernel currently fails to build if ACPI_PROCESSOR is a
module, like in the Debian kernels.

I see three possibilities to fix that:
- Convert to tristate and have the load the module if needed.
- Convert to tristate and have userspace load it via an alias.
- Use select instead of depends and force ACPI_PROCESSOR in.

As Xen dom0 needs a lot of setup anyway, I would prefer the first.

Bastian

-- 
Each kiss is as the first.
		-- Miramanee, Kirk's wife, "The Paradise Syndrome",
		   stardate 4842.6

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: paravirt-dom0: ACPI_PROCESSOR_XEN (bool) depends on ACPI_PROCESSOR (tristate)
  2009-10-05  2:16 paravirt-dom0: ACPI_PROCESSOR_XEN (bool) depends on ACPI_PROCESSOR (tristate) Bastian Blank
@ 2009-10-08 15:25 ` Bastian Blank
  2009-10-08 18:27   ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 3+ messages in thread
From: Bastian Blank @ 2009-10-08 15:25 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: xen-devel

On Mon, Oct 05, 2009 at 04:16:23AM +0200, Bastian Blank wrote:
> I see three possibilities to fix that:
> - Convert to tristate and have the load the module if needed.
> - Convert to tristate and have userspace load it via an alias.

This does not work, because it produces recursive dependencies.

Haven't you been asked to _NOT_ do such xen-only changes to core
subsystem code by several people? Somehow I begin to understand why they
tend to ignore you.

Bastian

-- 
You!  What PLANET is this!
		-- McCoy, "The City on the Edge of Forever", stardate 3134.0

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: paravirt-dom0: ACPI_PROCESSOR_XEN (bool) depends on ACPI_PROCESSOR (tristate)
  2009-10-08 15:25 ` Bastian Blank
@ 2009-10-08 18:27   ` Jeremy Fitzhardinge
  0 siblings, 0 replies; 3+ messages in thread
From: Jeremy Fitzhardinge @ 2009-10-08 18:27 UTC (permalink / raw)
  To: Bastian Blank; +Cc: xen-devel, Yu, Ke

On 10/08/09 08:25, Bastian Blank wrote:
> Haven't you been asked to _NOT_ do such xen-only changes to core
> subsystem code by several people? Somehow I begin to understand why they
> tend to ignore you.
>   

Sigh.  These patches have not been submitted to upstream, and definitely
need to be refined before I would consider upstreaming them.  But the
purpose of this branch is to accumulate all the work people have been
doing as it currently stands, to provide the most functionality for Xen
users.

Ke Yu is the maintainer of this code, and he's aware of this config
dependency problem.  I'm looking forward to an appropriate fix from him.

    J

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-10-08 18:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-05  2:16 paravirt-dom0: ACPI_PROCESSOR_XEN (bool) depends on ACPI_PROCESSOR (tristate) Bastian Blank
2009-10-08 15:25 ` Bastian Blank
2009-10-08 18:27   ` Jeremy Fitzhardinge

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.