On Dec 27, 2013 10:24 AM, "Li Guang" <lig.f...@cn.fujitsu.com> wrote:
>
> Peter Maydell wrote:
>>
>> On 26 December 2013 19:40, Hans de Goede<hdego...@redhat.com>  wrote:
>>
>>>
>>> I'm one of the linux-sunxi developers, the only reason we've
>>> this fex file abomination, is because we've inherited it
>>> from the android-allwinner sources.
>>>
>>
>> Thanks for the clarification; I suspected that might be the case.
>>
>>
>>>
>>> Currently most of the linux-sunxi developers are no longer
>>> focusing on the 3.4 android/allwinner derived sources we
>>> maintain. They are currently in a "good enough for everyday
>>> use" state.
>>>
>>> So now most of us are focusing on getting *proper* sunxi
>>> SoC support upstream. This is using device-tree. Currently
>>> we've working timers, interrupt-controller, uarts, mmc,
>>> sata, nic (both 100mbit and Gbit variants), ehci controller
>>> and builtin rtc support with upstream kernels. Which I
>>> believe likely covers everything the qemu emulation offers
>>> atm. For those interested, see:
>>> https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-devel
>>>
>>> And the mailinglist reports about progress in that branch.
>>>
>>>  From the linux-sunxi pov fex files are a legacy thing which
>>> will go away in the future.
>>>
>>
>> Given that, my preference would be to not support fex
>> file loading in QEMU.
>>
>>
>>
>
>
> that means we don't care legacy script which already be used
> in most of cases?
>

Your bootstrap process is just "blob this file at this address" which to me
is legitimate generic functionality. If you implement arbitrary file
blobbing on Cmd line there are many applications across all archs and
plats. and you fex case can be done without any allwinnerisms in tree.

I have use cases for this myself (mainly for emulating handoff in AMP
systems - two guests).

Regards
Peter

>
>

Reply via email to