Re: [Qemu-devel] [PATCH] functional ARM semihosting under GDB

[Peter Maydell]

On 17 November 2014 14:32, Liviu Ionescu <address@hidden> wrote:
> On 17 Nov 2014, at 14:32, Peter Maydell <address@hidden> wrote:
>
>> that it's combining six different features and bug fixes into a
>> single commit. Could you separate them out into their own patches?
>
> sure. in practical terms, this requires separate branches and each be
> applied to master, right?

Not necessarily. You could have one branch with six commits
on it, rebase that branch on master, and just send the patch or
two at the "bottom" of the stack to the mailing list.

> my experience with git is not as good as I would like (but improving),
> and, considering all changes are now in a single branch, could you
> suggest a simple way to do this?

Personally I use "stgit" as my tool for patch-management,
but plain git will also work fine here. You want to do an
interactive rebase, and you can then use the "edit" action
in the rebase for splitting the commit. This looks like
a decent explanation of how to do it:
http://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Splitting-a-Commit

Note that 'git add' has options for adding only some patch
hunks to a commit (rather than the default of adding all
the changes made to a file into the commit); see the man
page's section on "interactive mode" and the "--patch" option.

>>> A more generic option was added to specify the application file to be 
>>> emulated
>>>
>>>    -image file-path
>>
>> I'm pretty wary about this one, because we already have several image
>> loading options (-kernel, -bios) with complicated semantics that may
>> not be the same on different target architectures. What does your
>> "-image" option do that's different from the existing "-kernel" ?
>
> there are two issues here:
>
> - try to completely ignore your use case of qemu; you have a simple embedded 
> application, or a unit test, that you want to run under qemu, in a similar 
> way you run it on the physical board; you read the qemu manual and you find 
> out that you need to load a linux kernel; this makes absolutely no sense, the 
> small elf you want to run has absolutely nothing to do with any kernel. the 
> -kernel option is also accompanied by several other options, like -initrd, 
> etc that also make no sense for regular embedded applications.

This is basically saying "the -kernel option is not a great name
for that switch", right? If you pass it an ELF file it will do
the right thing, it's just not obvious (and possibly not documented)
that it will.

I'm sympathetic to the desire to clean up our argument handling
here, but we already have a confusing mess of options which have
different semantics in different situations, and it's going to
need real care to avoid just making the situation worse by
adding yet another option to the mess.

thanks
-- PMM