Il 17/10/2013 15:09, Alexey Kardashevskiy ha scritto:
>> In general, try to make QEMU produce SLOF APIs by modifying the devices
>> that instantiate the buses.
> 
> "channel@0" -> ""? This is a generic scsi bus, cannot change this.
> "disk@3,2" -> "disk@8302000000000000"? This is a generic scsi-cd, cannot
> change this either

Yes, I was referring more to the vio cases.

>> On top of this, fix the remaining QEMU->OF differences using a callback
>> in QEMUMachine.  This callback would be called by
>> qdev_get_fw_dev_path_helper and, if it returns something non-NULL, the
>> result would be used instead of calling bus_get_fw_dev_path.
> 
> A single machine callback which will recognize all possible bootable
> devices and replace things like "disk@3,2" -> "disk@8302000000000000"? Hm.
> 
> I mean I can do all of that but is it still kosher? :) Or I am missing the
> point, again.

No, a machine callback that will recognize SCSI disks and return
disk@8302000000000000.  This will replace the "channel@0/disk@3,2" path
returned by default.

>>> btw what format does qdev_get_fw_dev_path() use? This is not OF1275 so what
>>> is it?
>>
>> It is based on open-firmware.  For SCSI however openfirmware had
>> "disk@TARGET,LUN" but that does not include the channel.
> 
> I am confused now. What standard/format/spec defines this "channel@" thingy
> or it is made up by QEMU and the x86 bios shipped with QEMU? "open
> firmware" == IEEE1275, right?

It's made up.

Paolo


Reply via email to