On 11/29/2010 03:44 PM, Anthony Liguori wrote:
But really, let's defer this discussion for when patches are
available. I understand your objections but I'm pretty convinced that
the code will speak for itself when it's ready.
It will, but everyone will hear something different.
--
error
On 11/29/2010 02:04 AM, Michael S. Tsirkin wrote:
On Sun, Nov 28, 2010 at 05:13:41PM -0600, Anthony Liguori wrote:
On 11/28/2010 04:28 PM, Michael S. Tsirkin wrote:
But rather need to use ugly factory functions with all sorts of
DO_UPCAST. This is really unfriendly especially
On 11/29/2010 05:26 AM, Michael S. Tsirkin wrote:
On Mon, Nov 29, 2010 at 12:52:29PM +0200, Avi Kivity wrote:
The default is duplication. With C++ your default is
tr1::unordered_map<> and you can optimize it later if you like.
BTW not relevant to kvm, but for qemu, some people seem
On Mon, Nov 29, 2010 at 12:52:29PM +0200, Avi Kivity wrote:
> The default is duplication. With C++ your default is
> tr1::unordered_map<> and you can optimize it later if you like.
BTW not relevant to kvm, but for qemu, some people seem to care about
building with an old migw compiler in Debian s
On 11/29/2010 12:47 PM, Michael S. Tsirkin wrote:
On Mon, Nov 29, 2010 at 11:22:44AM +0200, Avi Kivity wrote:
> >> No need for an additional toolchain.
> >
> >It's a feature :) This way you are not forced to rewrite all code each
> >time you realize you need an extra check, and checks can
On Mon, Nov 29, 2010 at 11:22:44AM +0200, Avi Kivity wrote:
> >> No need for an additional toolchain.
> >
> >It's a feature :) This way you are not forced to rewrite all code each
> >time you realize you need an extra check, and checks can be added
> >gradually without breaking build.
>
> You ca
On 11/28/2010 04:49 PM, Michael S. Tsirkin wrote:
On Sun, Nov 28, 2010 at 03:15:52PM +0200, Avi Kivity wrote:
> On 11/28/2010 01:49 PM, Michael S. Tsirkin wrote:
> >> +++ b/api/kvmxx.cc
> >> @@ -0,0 +1,168 @@
> >> +#include "kvmxx.h"
> >> +#include
> >> +#include
> >> +#include
On 11/28/2010 04:40 PM, Michael S. Tsirkin wrote:
On Sun, Nov 28, 2010 at 03:14:17PM +0200, Avi Kivity wrote:
> On 11/28/2010 01:44 PM, Michael S. Tsirkin wrote:
> >On Sun, Nov 28, 2010 at 11:54:26AM +0200, Avi Kivity wrote:
> >> On 11/28/2010 11:50 AM, Michael S. Tsirkin wrote:
> >> >>
On 11/28/2010 06:57 PM, Michael S. Tsirkin wrote:
> >
> >sparce lets you solve C problems that C++ inherited as is.
> >E.g. if you have a pointer you can always dereference it.
>
> It's the other way round.
>
> For example __user cannot be done in C. It has to be done as an add-on.
>
> In
On Sun, Nov 28, 2010 at 05:13:41PM -0600, Anthony Liguori wrote:
> On 11/28/2010 04:28 PM, Michael S. Tsirkin wrote:
> >
> >>But rather need to use ugly factory functions with all sorts of
> >>DO_UPCAST. This is really unfriendly especially for writing test
> >>cases.
> >Yes, I agree. Just moving
On 11/28/2010 04:28 PM, Michael S. Tsirkin wrote:
But rather need to use ugly factory functions with all sorts of
DO_UPCAST. This is really unfriendly especially for writing test
cases.
Yes, I agree. Just moving memory allocation out of there
will fix most of the ugliness.
So here
On Sun, Nov 28, 2010 at 04:04:34PM -0600, Anthony Liguori wrote:
> >To create an object on the stack, you must have the class definition in
> >a public header and a public constructor/destructor.
> >This is exactly the same in C.
>
> It's really more of a design statement than a statement about C+
On 11/28/2010 08:40 AM, Michael S. Tsirkin wrote:
This code is not reusable. Everywhere you use an fd, you have to
repeat this code.
But that's not a lot of code. And you can abstract it away at a higher
level. For example kvm_init and kvm_cleanup would setup/cleanup
state in a consiste
On 11/28/2010 06:27 AM, Michael S. Tsirkin wrote:
On Wed, Nov 24, 2010 at 08:41:26AM -0600, Anthony Liguori wrote:
On 11/24/2010 06:59 AM, Alexander Graf wrote:
On 24.11.2010, at 11:52, Avi Kivity wrote:
Introduce exception-safe objects for calling system, vm, and vcpu ioctl
On Sun, Nov 28, 2010 at 04:34:39PM +0200, Avi Kivity wrote:
> On 11/28/2010 03:57 PM, Michael S. Tsirkin wrote:
> >On Sun, Nov 28, 2010 at 03:02:18PM +0200, Avi Kivity wrote:
> >> On 11/28/2010 01:59 PM, Michael S. Tsirkin wrote:
> >> >>
> >> >>
> >> >> FWIW, I still disagree with C++ and bel
On Sun, Nov 28, 2010 at 03:15:52PM +0200, Avi Kivity wrote:
> On 11/28/2010 01:49 PM, Michael S. Tsirkin wrote:
> >> +++ b/api/kvmxx.cc
> >> @@ -0,0 +1,168 @@
> >> +#include "kvmxx.h"
> >> +#include
> >> +#include
> >> +#include
> >
> >I just realized this is wrong: I think you should wrap
>
On Sun, Nov 28, 2010 at 03:14:17PM +0200, Avi Kivity wrote:
> On 11/28/2010 01:44 PM, Michael S. Tsirkin wrote:
> >On Sun, Nov 28, 2010 at 11:54:26AM +0200, Avi Kivity wrote:
> >> On 11/28/2010 11:50 AM, Michael S. Tsirkin wrote:
> >> >> >
> >> >> >Another problem is that there seem to be tw
On 11/28/2010 03:57 PM, Michael S. Tsirkin wrote:
On Sun, Nov 28, 2010 at 03:02:18PM +0200, Avi Kivity wrote:
> On 11/28/2010 01:59 PM, Michael S. Tsirkin wrote:
> >>
> >>
> >> FWIW, I still disagree with C++ and believe this code to be hardly
readable.
> >
> >A major issue is existing t
On Sun, Nov 28, 2010 at 03:02:18PM +0200, Avi Kivity wrote:
> On 11/28/2010 01:59 PM, Michael S. Tsirkin wrote:
> >>
> >>
> >> FWIW, I still disagree with C++ and believe this code to be hardly
> >> readable.
> >
> >A major issue is existing tools.
> >
> >Using C++ would prevent us from using spa
On 11/28/2010 01:49 PM, Michael S. Tsirkin wrote:
> +++ b/api/kvmxx.cc
> @@ -0,0 +1,168 @@
> +#include "kvmxx.h"
> +#include
> +#include
> +#include
I just realized this is wrong: I think you should wrap
the headers in extern "C". Same for other headers.
I think system headers already do
On 11/28/2010 01:44 PM, Michael S. Tsirkin wrote:
On Sun, Nov 28, 2010 at 11:54:26AM +0200, Avi Kivity wrote:
> On 11/28/2010 11:50 AM, Michael S. Tsirkin wrote:
> >> >
> >> >Another problem is that there seem to be two memory allocations and a
> >> >copy here, apparently just to simpli
On 11/28/2010 01:59 PM, Michael S. Tsirkin wrote:
>
>
> FWIW, I still disagree with C++ and believe this code to be hardly readable.
A major issue is existing tools.
Using C++ would prevent us from using sparce for static code checking.
C++ static checking is way better than anything sparse
On Wed, Nov 24, 2010 at 08:41:26AM -0600, Anthony Liguori wrote:
> On 11/24/2010 06:59 AM, Alexander Graf wrote:
> >On 24.11.2010, at 11:52, Avi Kivity wrote:
> >
> >>Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
> >>
> >>Signed-off-by: Avi Kivity
> >
> >FWIW, I still di
On Wed, Nov 24, 2010 at 01:59:14PM +0100, Alexander Graf wrote:
>
> On 24.11.2010, at 11:52, Avi Kivity wrote:
>
> > Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
> >
> > Signed-off-by: Avi Kivity
>
>
> FWIW, I still disagree with C++ and believe this code to be ha
On Wed, Nov 24, 2010 at 12:52:11PM +0200, Avi Kivity wrote:
> Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
>
> Signed-off-by: Avi Kivity
> ---
> api/kvmxx.cc | 168
> ++
> api/kvmxx.h | 80 +
On Sun, Nov 28, 2010 at 11:54:26AM +0200, Avi Kivity wrote:
> On 11/28/2010 11:50 AM, Michael S. Tsirkin wrote:
> >> >
> >> >Another problem is that there seem to be two memory allocations and a
> >> >copy here, apparently just to simplify error handling. It might be fine
> >> >for this test b
On 11/28/2010 11:50 AM, Michael S. Tsirkin wrote:
> >
> >Another problem is that there seem to be two memory allocations and a
> >copy here, apparently just to simplify error handling. It might be fine
> >for this test but won't scale for when performance matters.
>
> When it matters, we ca
On Sun, Nov 28, 2010 at 11:31:09AM +0200, Avi Kivity wrote:
> On 11/28/2010 10:58 AM, Michael S. Tsirkin wrote:
> >On Sat, Nov 27, 2010 at 11:12:58AM +0200, Avi Kivity wrote:
> >> On 11/26/2010 12:16 PM, Michael S. Tsirkin wrote:
> >> >On Wed, Nov 24, 2010 at 12:52:11PM +0200, Avi Kivity wrote:
>
On 11/28/2010 10:58 AM, Michael S. Tsirkin wrote:
On Sat, Nov 27, 2010 at 11:12:58AM +0200, Avi Kivity wrote:
> On 11/26/2010 12:16 PM, Michael S. Tsirkin wrote:
> >On Wed, Nov 24, 2010 at 12:52:11PM +0200, Avi Kivity wrote:
> >> Introduce exception-safe objects for calling system, vm, and v
On Sat, Nov 27, 2010 at 11:12:58AM +0200, Avi Kivity wrote:
> On 11/26/2010 12:16 PM, Michael S. Tsirkin wrote:
> >On Wed, Nov 24, 2010 at 12:52:11PM +0200, Avi Kivity wrote:
> >> Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
> >>
> >> Signed-off-by: Avi Kivity
> >
> >
On Wed, Nov 24, 2010 at 12:52:11PM +0200, Avi Kivity wrote:
> Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
>
> Signed-off-by: Avi Kivity
ioctlp calls below ignore possible errors.
Somre more comments below.
> ---
> api/kvmxx.cc | 168
> +++
On 11/24/2010 04:29 PM, Avi Kivity wrote:
+kvm_msrs* vcpu::alloc_msr_list(size_t nmsrs)
+{
+size_t size = sizeof(kvm_msrs) + sizeof(kvm_msr_entry) * nmsrs;
+kvm_msrs* ret = static_cast(malloc(size));
+if (!ret) {
+throw ENOMEM;
+}
+return ret;
+}
malloc?
Mixing C and C+
On Wed, Nov 24, 2010 at 12:53:00PM -0600, Anthony Liguori wrote:
> On 11/24/2010 12:34 PM, Gleb Natapov wrote:
> Right, and real HW does composition in the PIIX3 device. So let's
> not regret making everything an ISA device later.
>
> >>>You design by packaging not functionality?
> >>N
On 11/24/2010 09:29 PM, Jes Sorensen wrote:
>> >
>> Bug can still be yours but all this virtual inheritance make it much
>> harder to understand what happens.
>
> No, it's easier, since there's a lot less code to chase.
>
> Of course, you have to learn the pattern in the language, but you do
On 11/24/10 19:55, Avi Kivity wrote:
> On 11/24/2010 08:10 PM, Gleb Natapov wrote:
>> On Wed, Nov 24, 2010 at 07:50:44PM +0200, Avi Kivity wrote:
>> > On 11/24/2010 07:43 PM, Gleb Natapov wrote:
>> > >> Implicit code means that you don't need to debug it. The
>> compiler
>> > >> gets it rig
On 11/24/2010 08:01 PM, Anthony Liguori wrote:
So I take it you avoid switch statements, while, or for loops in your C
code.
Those map easily to assembly code and gdb.
The mapping is definitely not simply especially after a couple rounds
of loop unrolling and code motion.
You're discounting
On 11/24/2010 08:10 PM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 07:50:44PM +0200, Avi Kivity wrote:
> On 11/24/2010 07:43 PM, Gleb Natapov wrote:
> >> >Explicit code means you know what is going on, it means you can debug
it
> >> >in gdb and match it. That is a *good* thing!
> >>
>
On 11/24/2010 12:34 PM, Gleb Natapov wrote:
Right, and real HW does composition in the PIIX3 device. So let's
not regret making everything an ISA device later.
You design by packaging not functionality?
No, if you want the ability to remove devices from the PIIX3, fine,
but d
On 11/24/2010 08:23 PM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 07:50:06PM +0200, Avi Kivity wrote:
> On 11/24/2010 07:41 PM, Gleb Natapov wrote:
> >On Wed, Nov 24, 2010 at 07:39:39PM +0200, Avi Kivity wrote:
> >> On 11/24/2010 07:33 PM, Gleb Natapov wrote:
> >> >>
> >> >>But I
On Wed, Nov 24, 2010 at 12:17:00PM -0600, Anthony Liguori wrote:
> On 11/24/2010 11:33 AM, Gleb Natapov wrote:
> >On Wed, Nov 24, 2010 at 10:40:05AM -0600, Anthony Liguori wrote:
> >>On 11/24/2010 10:12 AM, Gleb Natapov wrote:
> Why would we specify a PIIX3 device based on a configuration file?
On Wed, Nov 24, 2010 at 07:50:06PM +0200, Avi Kivity wrote:
> On 11/24/2010 07:41 PM, Gleb Natapov wrote:
> >On Wed, Nov 24, 2010 at 07:39:39PM +0200, Avi Kivity wrote:
> >> On 11/24/2010 07:33 PM, Gleb Natapov wrote:
> >> >>
> >> >> But I don't see the point. If you look at my repository, th
On 11/24/2010 11:33 AM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 10:40:05AM -0600, Anthony Liguori wrote:
On 11/24/2010 10:12 AM, Gleb Natapov wrote:
Why would we specify a PIIX3 device based on a configuration file?
There is only one PIIX3 device in the world. I don't see
On Wed, Nov 24, 2010 at 07:50:44PM +0200, Avi Kivity wrote:
> On 11/24/2010 07:43 PM, Gleb Natapov wrote:
> >> >Explicit code means you know what is going on, it means you can debug it
> >> >in gdb and match it. That is a *good* thing!
> >>
> >> Implicit code means that you don't need to debug i
On 11/24/2010 11:45 AM, Jes Sorensen wrote:
On 11/24/10 18:43, Anthony Liguori wrote:
On 11/24/2010 11:36 AM, Jes Sorensen wrote:
On 11/24/10 18:27, Anthony Liguori wrote:
The compiler won't generate an error. Only upon a call to
file_release() will a null pointer derefere
On 11/24/2010 07:45 PM, Jes Sorensen wrote:
>
> So I take it you avoid switch statements, while, or for loops in your C
> code.
Those map easily to assembly code and gdb.
So do virtual functions.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this li
On 11/24/2010 07:43 PM, Jes Sorensen wrote:
On 11/24/10 18:41, Avi Kivity wrote:
> On 11/24/2010 07:36 PM, Jes Sorensen wrote:
>> On 11/24/10 18:27, Anthony Liguori wrote:
>>
>> > The compiler won't generate an error. Only upon a call to
>> > file_release() will a null pointer dereferenc
On 11/24/2010 07:36 PM, Gleb Natapov wrote:
> That is pure bullshit. All major browsers are written in C++, all
> major office suites, one leading free desktop, google, countless
> other projects. There is a lot more C++ code in the world than C
> code. If virtual functions didn't behave a
On 11/24/2010 07:43 PM, Gleb Natapov wrote:
> >Explicit code means you know what is going on, it means you can debug it
> >in gdb and match it. That is a *good* thing!
>
> Implicit code means that you don't need to debug it. The compiler
> gets it right every time.
>
Best joke ever!
Do you
On 11/24/2010 07:41 PM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 07:39:39PM +0200, Avi Kivity wrote:
> On 11/24/2010 07:33 PM, Gleb Natapov wrote:
> >>
> >> But I don't see the point. If you look at my repository, there's
> >The point is that C++ is ugly language. The short code Avi sen
On 11/24/10 18:43, Anthony Liguori wrote:
> On 11/24/2010 11:36 AM, Jes Sorensen wrote:
>> On 11/24/10 18:27, Anthony Liguori wrote:
>>
>>
>>> The compiler won't generate an error. Only upon a call to
>>> file_release() will a null pointer dereference happens whereas in C++,
>>> because this pa
On 11/24/2010 11:36 AM, Jes Sorensen wrote:
On 11/24/10 18:27, Anthony Liguori wrote:
The compiler won't generate an error. Only upon a call to
file_release() will a null pointer dereference happens whereas in C++,
because this paradigm is structured in the language, the compiler can
help
On 11/24/10 18:41, Avi Kivity wrote:
> On 11/24/2010 07:36 PM, Jes Sorensen wrote:
>> On 11/24/10 18:27, Anthony Liguori wrote:
>>
>> > The compiler won't generate an error. Only upon a call to
>> > file_release() will a null pointer dereference happens whereas in C++,
>> > because this paradig
On Wed, Nov 24, 2010 at 07:41:48PM +0200, Avi Kivity wrote:
> On 11/24/2010 07:36 PM, Jes Sorensen wrote:
> >On 11/24/10 18:27, Anthony Liguori wrote:
> >
> >> The compiler won't generate an error. Only upon a call to
> >> file_release() will a null pointer dereference happens whereas in C++,
>
On 11/24/2010 07:36 PM, Jes Sorensen wrote:
On 11/24/10 18:27, Anthony Liguori wrote:
> The compiler won't generate an error. Only upon a call to
> file_release() will a null pointer dereference happens whereas in C++,
> because this paradigm is structured in the language, the compiler can
>
On Wed, Nov 24, 2010 at 07:39:39PM +0200, Avi Kivity wrote:
> On 11/24/2010 07:33 PM, Gleb Natapov wrote:
> >>
> >> But I don't see the point. If you look at my repository, there's
> >The point is that C++ is ugly language. The short code Avi sent remind
> >me perl (aka line noise). It is almost
On 11/24/2010 07:33 PM, Gleb Natapov wrote:
>
> But I don't see the point. If you look at my repository, there's
The point is that C++ is ugly language. The short code Avi sent remind
me perl (aka line noise). It is almost impossible to parse it into
what code it actually does. Most symbols are
On 11/24/10 18:27, Anthony Liguori wrote:
> The compiler won't generate an error. Only upon a call to
> file_release() will a null pointer dereference happens whereas in C++,
> because this paradigm is structured in the language, the compiler can
> help assist you.
Explicit code means you know w
On Wed, Nov 24, 2010 at 07:25:08PM +0200, Avi Kivity wrote:
> On 11/24/2010 07:17 PM, Jes Sorensen wrote:
> >>
> >> Anyone wishing to implement this interface is forced to implement read
> >> and write methods (callbacks) with exactly the right signature. The
> >> compiler will complain if they
On 11/24/2010 07:27 PM, Anthony Liguori wrote:
The alternative in C is:
struct file_operations {
void (*release)(void);
void (*read)(...);
void (*write)(...);
};
struct file {
struct file_operations *ops;
};
If I do:
static file_operations posix_file_ops = {
.read = posix_file_r
On Wed, Nov 24, 2010 at 10:40:05AM -0600, Anthony Liguori wrote:
> On 11/24/2010 10:12 AM, Gleb Natapov wrote:
> >
> >>Why would we specify a PIIX3 device based on a configuration file?
> >>There is only one PIIX3 device in the world. I don't see a lot of
> >>need to create arbitrary types of devi
On 11/24/2010 07:28 PM, Jes Sorensen wrote:
On 11/24/10 18:25, Avi Kivity wrote:
> On 11/24/2010 07:17 PM, Jes Sorensen wrote:
>> In the mean time we spend our time debugging the runtime because the
>> virtual functions don't behave as expected. In C we know what is going
>> on, in C++ it is
On 11/24/2010 06:57 PM, Anthony Liguori wrote:
It's a question of how it is accessed, if it is treated like an ISA
device by the silicon, we should treat it like an ISA device in QEMU,
rather than pretend it is something that it isn't.
Does anyone have any evidence that the i8042 has anything t
On 11/24/2010 11:17 AM, Jes Sorensen wrote:
On 11/24/10 18:11, Avi Kivity wrote:
On 11/24/2010 07:06 PM, Jes Sorensen wrote:
Sorry but that is utterly and completely bogus! The enforcement is only
as good as the developers and maintainers make it,
class File {
public:
On 11/24/10 18:25, Avi Kivity wrote:
> On 11/24/2010 07:17 PM, Jes Sorensen wrote:
>> In the mean time we spend our time debugging the runtime because the
>> virtual functions don't behave as expected. In C we know what is going
>> on, in C++ it is pray and hope.
>
> That is pure bullshit. All ma
On 11/24/2010 07:16 PM, Gleb Natapov wrote:
>
> If the i8042 is completely stock, we write
>
> class i440fx {
> private:
> i8042 kbc;
> }
>
> (or the C equivalent)
>
> If it's not completely stock, we substitute some subclass that takes
> care of the differences.
>
And if you want to
On 11/24/2010 07:17 PM, Jes Sorensen wrote:
>
> Anyone wishing to implement this interface is forced to implement read
> and write methods (callbacks) with exactly the right signature. The
> compiler will complain if they don't. So if File is a good interface,
> we can make the compiler for
On Wed, Nov 24, 2010 at 07:01:00PM +0200, Avi Kivity wrote:
> On 11/24/2010 06:55 PM, Gleb Natapov wrote:
> >> >
> >> >What you did above is making the exact same mistake as is done with the
> >> >current i440fx.c code.
> >>
> >> If a real life 440fx has an i8042, then an emulated 440fx should
On 11/24/10 18:11, Avi Kivity wrote:
> On 11/24/2010 07:06 PM, Jes Sorensen wrote:
>> Sorry but that is utterly and completely bogus! The enforcement is only
>> as good as the developers and maintainers make it,
>
> class File {
> public:
> virtual ~File() {}
> virtual void read(..
On 11/24/2010 11:07 AM, Avi Kivity wrote:
On 11/24/2010 07:02 PM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 06:56:52PM +0200, Avi Kivity wrote:
> On 11/24/2010 06:52 PM, Gleb Natapov wrote:
> >> Plus some magic glue. You can't say it is an ISA bridge. It's
> >> exactly what its spec say
On 11/24/2010 07:10 PM, Jes Sorensen wrote:
On 11/24/10 18:07, Avi Kivity wrote:
> On 11/24/2010 07:02 PM, Gleb Natapov wrote:
>> On Wed, Nov 24, 2010 at 06:56:52PM +0200, Avi Kivity wrote:
>> > On 11/24/2010 06:52 PM, Gleb Natapov wrote:
>> > >>Plus some magic glue. You can't say it
On 11/24/2010 07:06 PM, Jes Sorensen wrote:
On 11/24/10 17:59, Avi Kivity wrote:
> On 11/24/2010 06:51 PM, Jes Sorensen wrote:
>> Right we need good design for our C code, which we are lacking to a
>> large extend. However that has nothing to do with the language, that has
>> to do with the d
On 11/24/10 18:07, Avi Kivity wrote:
> On 11/24/2010 07:02 PM, Gleb Natapov wrote:
>> On Wed, Nov 24, 2010 at 06:56:52PM +0200, Avi Kivity wrote:
>> > On 11/24/2010 06:52 PM, Gleb Natapov wrote:
>> > >> Plus some magic glue. You can't say it is an ISA bridge. It's
>> > >> exactly what its
On 11/24/2010 07:02 PM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 06:56:52PM +0200, Avi Kivity wrote:
> On 11/24/2010 06:52 PM, Gleb Natapov wrote:
> >> Plus some magic glue. You can't say it is an ISA bridge. It's
> >> exactly what its spec says it is.
> >>
> >First thing my spec sa
On 11/24/10 17:59, Avi Kivity wrote:
> On 11/24/2010 06:51 PM, Jes Sorensen wrote:
>> Right we need good design for our C code, which we are lacking to a
>> large extend. However that has nothing to do with the language, that has
>> to do with the developers.
>
> I'm sure patches will be welcome.
On 11/24/10 17:53, Anthony Liguori wrote:
> On 11/24/2010 10:40 AM, Jes Sorensen wrote:
>> Well the problem is the 10% you are talking about is another 30% loss
>> because the code is now practically unreadable, plus you open up the can
>> of worms that people will start using some of the tota
On Wed, Nov 24, 2010 at 10:56:15AM -0600, Anthony Liguori wrote:
> On 11/24/2010 10:48 AM, Gleb Natapov wrote:
> >>They *aren't* ISA devices. Look at the PIIX3 spec. All of the
> >>ports for these devices are positively decoded and not sent over the
> >>ISA bus.
> >>
> >Over the external ISA bus
On Wed, Nov 24, 2010 at 06:56:52PM +0200, Avi Kivity wrote:
> On 11/24/2010 06:52 PM, Gleb Natapov wrote:
> >> Plus some magic glue. You can't say it is an ISA bridge. It's
> >> exactly what its spec says it is.
> >>
> >First thing my spec says is "Bridge Between the PCI Bus and ISA Bus"
>
> I
On 11/24/2010 06:55 PM, Gleb Natapov wrote:
> >
> >What you did above is making the exact same mistake as is done with the
> >current i440fx.c code.
>
> If a real life 440fx has an i8042, then an emulated 440fx should
> have an emulated i8042. It's not complicated.
>
Correct. But it can be
On 11/24/2010 10:51 AM, Jes Sorensen wrote:
On 11/24/10 17:47, Avi Kivity wrote:
On 11/24/2010 06:40 PM, Jes Sorensen wrote:
Well the problem here is that the i8042 is in the i440fx.c file, it
shouldn't be there in the first place. The gluing together things in
silicon is really just
On 11/24/2010 06:51 PM, Jes Sorensen wrote:
On 11/24/10 17:47, Avi Kivity wrote:
> On 11/24/2010 06:40 PM, Jes Sorensen wrote:
>> Well the problem here is that the i8042 is in the i440fx.c file, it
>> shouldn't be there in the first place. The gluing together things in
>> silicon is really ju
On 11/24/2010 10:48 AM, Gleb Natapov wrote:
They *aren't* ISA devices. Look at the PIIX3 spec. All of the
ports for these devices are positively decoded and not sent over the
ISA bus.
Over the external ISA bus you mean?
There is no internal ISA bus. The reality is that the PIIX3
On 11/24/2010 06:52 PM, Gleb Natapov wrote:
> Plus some magic glue. You can't say it is an ISA bridge. It's
> exactly what its spec says it is.
>
First thing my spec says is "Bridge Between the PCI Bus and ISA Bus"
It's the first item in a list of features. Be serious.
> >>
> >> I co
On Wed, Nov 24, 2010 at 06:47:28PM +0200, Avi Kivity wrote:
> On 11/24/2010 06:40 PM, Jes Sorensen wrote:
>
> >>> The fact that in physical implementation they sit in the same silicon
> >>> does not mean that logically they belong to the same class. PIIX3
> >>> is ISA bridge. It doesn't mea
On Wed, Nov 24, 2010 at 06:33:17PM +0200, Avi Kivity wrote:
> On 11/24/2010 06:29 PM, Gleb Natapov wrote:
> >>
> >> >> >Besides, as I said, PIIX3 is ISA bridge and this
> >> >> >is what class should implement.
> >> >>
> >> >> Isn't it an ISA bridge + a few ISA devices?
> >> >>
> >> >Why
On 11/24/2010 10:40 AM, Jes Sorensen wrote:
Well the problem here is that the i8042 is in the i440fx.c file, it
shouldn't be there in the first place. The gluing together things in
silicon is really just a way to shorten the wires and make it easier,
they are still separate devices and as long as
On 11/24/10 17:47, Avi Kivity wrote:
> On 11/24/2010 06:40 PM, Jes Sorensen wrote:
>> Well the problem here is that the i8042 is in the i440fx.c file, it
>> shouldn't be there in the first place. The gluing together things in
>> silicon is really just a way to shorten the wires and make it easier,
On 11/24/2010 06:44 PM, Jes Sorensen wrote:
>>
>> It's got :'s all over the place that makes no sense whatsoever :(
>
> You've got two in one sentence! Practice what you preach.
>
If you want to reject my patches due to my broken English, go ahead. At
least it should be somewhat readable.
I
On Wed, Nov 24, 2010 at 10:43:57AM -0600, Anthony Liguori wrote:
> On 11/24/2010 10:21 AM, Gleb Natapov wrote:
> >On Wed, Nov 24, 2010 at 06:14:22PM +0200, Avi Kivity wrote:
> >>On 11/24/2010 06:12 PM, Gleb Natapov wrote:
> Why would we specify a PIIX3 device based on a configuration file?
>
On 11/24/2010 06:40 PM, Jes Sorensen wrote:
>>>
>> The fact that in physical implementation they sit in the same silicon
>> does not mean that logically they belong to the same class. PIIX3
>> is ISA bridge. It doesn't mean it owns devices on the ISA bus it
>> provides. The information that y
On 11/24/10 17:34, Avi Kivity wrote:
> On 11/24/2010 06:29 PM, Jes Sorensen wrote:
>> >
>> > FWIW, I still disagree with C++ and believe this code to be hardly
>> readable.
>>
>> YUCK!
>>
>> It's got :'s all over the place that makes no sense whatsoever :(
>
> You've got two in one sentence! Prac
On 11/24/2010 10:21 AM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 06:14:22PM +0200, Avi Kivity wrote:
On 11/24/2010 06:12 PM, Gleb Natapov wrote:
Why would we specify a PIIX3 device based on a configuration file?
There is only one PIIX3 device in the world. I don't see a lot of
On 11/24/2010 10:12 AM, Gleb Natapov wrote:
Why would we specify a PIIX3 device based on a configuration file?
There is only one PIIX3 device in the world. I don't see a lot of
need to create arbitrary types of devices.
Why deny this flexibility from those who need it for modelling
dif
On 11/24/10 16:50, Anthony Liguori wrote:
> On 11/24/2010 09:40 AM, Gleb Natapov wrote:
>> On Wed, Nov 24, 2010 at 08:41:26AM -0600, Anthony Liguori wrote:
>>> In real hardware, the i8042 (keyboard controller) is actually
>>> implemented in the PIIX3 which is a chip that is part of the i440fx.
>>>
On 11/24/2010 06:29 PM, Gleb Natapov wrote:
>
> >> >Besides, as I said, PIIX3 is ISA bridge and this
> >> >is what class should implement.
> >>
> >> Isn't it an ISA bridge + a few ISA devices?
> >>
> >Why? Because they happen to be on the same silicon? So then in SoC
> >all devices a
On 11/24/2010 06:29 PM, Jes Sorensen wrote:
>
> FWIW, I still disagree with C++ and believe this code to be hardly readable.
YUCK!
It's got :'s all over the place that makes no sense whatsoever :(
You've got two in one sentence! Practice what you preach.
--
error compiling committee.c: too
On 11/24/10 13:59, Alexander Graf wrote:
>
> On 24.11.2010, at 11:52, Avi Kivity wrote:
>
>> Introduce exception-safe objects for calling system, vm, and vcpu ioctls.
>>
>> Signed-off-by: Avi Kivity
>
>
> FWIW, I still disagree with C++ and believe this code to be hardly readable.
YUCK!
It's
On Wed, Nov 24, 2010 at 06:25:44PM +0200, Avi Kivity wrote:
> On 11/24/2010 06:21 PM, Gleb Natapov wrote:
> >On Wed, Nov 24, 2010 at 06:14:22PM +0200, Avi Kivity wrote:
> >> On 11/24/2010 06:12 PM, Gleb Natapov wrote:
> >> >>
> >> >> Why would we specify a PIIX3 device based on a configuration
On 11/24/2010 06:21 PM, Gleb Natapov wrote:
On Wed, Nov 24, 2010 at 06:14:22PM +0200, Avi Kivity wrote:
> On 11/24/2010 06:12 PM, Gleb Natapov wrote:
> >>
> >> Why would we specify a PIIX3 device based on a configuration file?
> >> There is only one PIIX3 device in the world. I don't see
On Wed, Nov 24, 2010 at 06:14:22PM +0200, Avi Kivity wrote:
> On 11/24/2010 06:12 PM, Gleb Natapov wrote:
> >>
> >> Why would we specify a PIIX3 device based on a configuration file?
> >> There is only one PIIX3 device in the world. I don't see a lot of
> >> need to create arbitrary types of de
On 11/24/2010 06:12 PM, Gleb Natapov wrote:
>
> Why would we specify a PIIX3 device based on a configuration file?
> There is only one PIIX3 device in the world. I don't see a lot of
> need to create arbitrary types of devices.
>
Why deny this flexibility from those who need it for modelling
1 - 100 of 117 matches
Mail list logo
