qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 2/3] hw/pci: Introduce pci_requester_id()


From: Pavel Fedin
Subject: Re: [Qemu-devel] [PATCH v4 2/3] hw/pci: Introduce pci_requester_id()
Date: Thu, 15 Oct 2015 11:54:57 +0300

 Hello!

> > diff --git a/stubs/pci.c b/stubs/pci.c
> > new file mode 100644
> > index 0000000..3b13000
> > --- /dev/null
> > +++ b/stubs/pci.c
> > @@ -0,0 +1,16 @@
> > +/*
> > + * QEMU architecture-specific PCI functions
> > + *
> > + * Copyright (c) 2015 Samsung Electronics Co., Ltd.
> > + * Written by Pavel Fedin
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or 
> > later.
> > + * See the COPYING file in the top-level directory.
> > + *
> > + */
> > +#include "hw/pci/pci.h"
> > +
> > +uint16_t pci_requester_id(PCIDevice *dev)
> > +{
> > +    return 0;
> > +}
> 
> OK this is now wrong. You should move the logic back here
> from target-arm.

 Thank you very much for quick responses and cooperation, but... Could we 
discuss a little bit, what you actually want as a result?
This starts to be very inefficient and time-consuming. Every time i redo the 
whole thing only to hear that "this single line is now
wrong".
 So far, previously you told me that since requester ID is 
architecture-specific, if should be moved to arch code. Now you tell me
that you want it in stubs... Why? Stubs are something to be replaced. And we 
won't have the replacement anywhere, because nowadays
no architecture except ARM uses it. And probably it will stay this way forever. 
The function is very small, and even if we add more
bits for root complex ID, it will stay very small. Why not to have it as inline 
in include/hw/pci.h? If we ever need to replace it
in future, then we'll move it to stubs and override in target-XXX.
 And, what with other two patches? Actually, all three are independent, i 
combined them into one series only because they are part
of original bigger series. You didn't have any comments on them, could you ACK 
them finally in order to simplify things down?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia





reply via email to

[Prev in Thread] Current Thread [Next in Thread]