RE: RFC: top level compatibles for virtual platforms
From: Yoder Stuart-B08248 <hidden>
Date: 2011-07-11 17:41:26
-----Original Message----- From: Wood Scott-B07421 Sent: Monday, July 11, 2011 11:24 AM To: Tabi Timur-B04825 Cc: Yoder Stuart-B08248; Grant Likely; Benjamin Herrenschmidt; Gala Kumar=
-B11780; Wood Scott-
B07421; Alexander Graf; linuxppc-dev@ozlabs.org Subject: Re: RFC: top level compatibles for virtual platforms =20 On Mon, 11 Jul 2011 10:45:47 -0500 Timur Tabi [off-list ref] wrote: =20quoted
quoted
quoted
Also, if these are KVM creations, shouldn't there be a "kvm" in the compatible string somewhere?There is nothing KVM specific about these platforms. Any hypervisor could create a similar virtual machine.True, but I think we're on a slippery slope, here. Virtualization allows us to create "virtual platforms" that are not well defined. Linux requires a unique compatible string for each platform.=20 The device tree is supposed to describe the hardware (virtual or otherwis=
e), not just supply
what Linux wants. Perhaps there simply shouldn't be a toplevel compatibl=
e if there's nothing
appropriate to describe there -- and fix whatever issues Linux has with t=
hat.
But there is a concept in Linux of a platform 'machine':
define_machine(p4080_ds) {
.name =3D "P4080 DS",
.probe =3D p4080_ds_probe,
.setup_arch =3D corenet_ds_setup_arch,
.init_IRQ =3D corenet_ds_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus =3D fsl_pcibios_fixup_bus,
#endif
.get_irq =3D mpic_get_coreint_irq,
.restart =3D fsl_rstcr_restart,
.calibrate_decr =3D generic_calibrate_decr,
.progress =3D udbg_progress,
};
Right now p4080_ds_probe needs something to match on to determine
whether this is the machine type. How would it work if=20
there was no top level compatible to match on? Some=20
platforms (e.g. e500v2-type) need mpc85xx_ds_pic_init(),
others need corenet_ds_pic_init(). We need a way to
select the machine.
Stuart