OpenForum RSS: �� KSM

�� KSM (Ordu)

Thu, 02 Feb 2017 18:38:32 GMT

> At least I understand shit before I try to argue they are wrong.

I'm not trying to be offensive, but arguing is also the way do discover things. Yes I might clone your repo, run etags on it and find definitions of all structs, lurk some time in different parts of code, and become much more correct with my initial guesses about reasons behind the patterns used. But nevertheless my guesses would remains just guesses. Now my knowledge is more reliable. I cleared my mind from influence of OP's opinion and your hostile behaviour. I have built my own opinion instead. And, I hope, you also got something from discussion. I hope I was not just using you for reaching my goals, but giving you something also.

And one more hint. Less subtle. Psychologists tend to differentiate two strategies of behaviour: need for success and failure avoidance. And I work hard to bring myself to the first. I'd like to fail in discussion, which not a super important to me -- it costs me nothing. But I can get some information while

�� KSM (flop)

Thu, 02 Feb 2017 09:40:08 GMT

> I see... You are not enlightened yet. So, go away and code.
> And do not come back until enlightened.

At least I understand shit before I try to argue they are wrong.
You're the one interested in my stuff regardless. Anyways, point proven, no need for me to come here again. The only reason I came was through Github Traffic, it got an abnormal amount of traffic and I was surprised because I did not advertise it, so it seemed to point to here and 2 other articles on the web.

�� KSM (Ordu)

Thu, 02 Feb 2017 07:04:48 GMT

> I'd rather laugh at confused people while they try to understand my
> code.

I see... You are not enlightened yet. So, go away and code. And do not come back until enlightened.

�� KSM (flop)

Thu, 02 Feb 2017 05:50:24 GMT

> Wow... I'm impressed. Unexpected use for container_of. But yes, you are right
> about I was a fool, I could catch it looking only
> into this function, but I didn't.

Good thing you admit your failure, that's one step forward.

> But nevertheless... You are using container_of in a way its not indended
> to use. Even without looking on the rest of your code
> I can say this to you with great confidence. If you
> do not believe me, you might ask any kernel developer and
> try to convince him that you have important reasons to such
> a design that leads to use container_of in this case.
>
> container_of is a tool to design some data structures like list, where
> different struct types have common parts. For example struct list_head field.

Have common parts? What? You really need to work on your understanding of things, the use of container_of is for container-structures of a single structure where you would have a pointer to that container-structure, then you can subtract it with the

�� KSM (Ordu)

Thu, 02 Feb 2017 05:28:49 GMT

> Harsh replies automatically allocate me as Linus Torvalds, ok.

No, you cannot be used as a replacement for him, but still looks similar. At least your first comment in this thread has such funny property.

> the vcpu_list is not a list_head, it's simply an array of `struct vcpu`, declared as follows:
> struct vcpu vcpu_list[MAX_VCPUS];

Wow... I'm impressed. Unexpected use for container_of. But yes, you are right about I was a fool, I could catch it looking only into this function, but I didn't.

But nevertheless... You are using container_of in a way its not indended to use. Even without looking on the rest of your code I can say this to you with great confidence. If you do not believe me, you might ask any kernel developer and try to convince him that you have important reasons to such a design that leads to use container_of in this case.

container_of is a tool to design some data structures like list, where different struct types have common parts. For example struct list_head field.
containe

�� KSM (flop)

Thu, 02 Feb 2017 03:03:40 GMT

> In your harsh replies to critics, obviously.

Harsh replies automatically allocate me as Linus Torvalds, ok.

> And what I should get?
> $ cat tmp.c
> void (*casting_pointers())()
> {
> void *void_fn = (void*)casting_pointers;
> void (*fn)() = (void (*)()) void_fn;
> return fn;
> }
> $ gcc -Wall -c tmp.c
> $

Under MSVC, you'd get a warning saying you're casting a function pointer to a data pointer, which is why I disable this warning under MSVC only.

> I don't know what warnings of MSVC you are talking about, but
> assuming you are right with it and MSVC warnings are useless,
> you should use gcc -Wall and its warnings or some external
> static code analizer to check your code.

It's already implicility used...

>[�� ]
> getting those warnings. Clean your code and either make an explicit
> cast of vcpu to struct list_head*, or change type of an
> arg in function declaration to reflect the type of field in
> struct ksm.
>> Also the incompatible p

�� KSM (Ordu)

Thu, 02 Feb 2017 02:04:04 GMT

>> If you are trying to mimic Torvalds you should spend more time
>> on learning how to use word "bullshit" well and, I believe,
> Mimic Torvalds in what exactly?

In your harsh replies to critics, obviously.

> You're wrong and yet again, try casting a function pointer to a
> void pointer (inverse works, too) under both GCC and MSVC, see
> what you get.

And what I should get?

$ cat tmp.c
void (*casting_pointers())()
{
void *void_fn = (void*)casting_pointers;
void (*fn)() = (void (*)()) void_fn;
return fn;
}
$ gcc -Wall -c tmp.c
$

> I do not have these warnings
> ignored under GCC, I have them ignored under MSVC, idiot.
> Both GTK and Linux Kernel use GCC.

I don't know what warnings of MSVC you are talking about, but assuming you are right with it and MSVC warnings are useless, you should use gcc -Wall and its warnings or some external static code analizer to check your code.

> Also the incompatible pointer warning that was _only_ ignored for just 1
> function is fro

�� KSM (flop)

Thu, 02 Feb 2017 00:21:46 GMT

> And... y'know, your sayings is not very smart. If we take into
> consideration, for instance, casts between different types in C, I could
> give you three examples of software were such casts are widely
> used _without_ any compiler warnings despite -Wall used: linux kernel, gtk+,
> enlightenment libraries. So, just take a look at those code and
> learn how to deal with casts properly.

Also the incompatible pointer warning that was _only_ ignored for just 1 function is from here: https://github.com/asamy/ksm/blob/master/ksm.h#L563 which is reasonable, if you know how to container_of works, then you'll understand why this spurious warning happens. (The funny part, GCC has this problem, but not MSVC, hah.)

�� KSM (flop)

Wed, 01 Feb 2017 23:52:38 GMT

> If you are trying to mimic Torvalds you should spend more time
> on learning how to use word "bullshit" well and, I believe,
> you lack Linus's entourage, you are really miss mailing list full
> of supporters.

Mimic Torvalds in what exactly? I don't see what you're talking about. I don't need supporters or mailing list to prove someone wrong.

> And... y'know, your sayings is not very smart. If we take into
> consideration, for instance, casts between different types in C, I could
> give you three examples of software were such casts are widely
> used _without_ any compiler warnings despite -Wall used: linux kernel, gtk+,
> enlightenment libraries. So, just take a look at those code and
> learn how to deal with casts properly.

You're wrong and yet again, try casting a function pointer to a void pointer (inverse works, too) under both GCC and MSVC, see what you get. I do not have these warnings ignored under GCC, I have them ignored under MSVC, idiot. Both GTK and Linux Kernel use

OpenForum RSS: �������� ����� ���������� KSM

�������� ����� ���������� KSM (Ordu)

�������� ����� ���������� KSM (flop)

�������� ����� ���������� KSM (Ordu)

�������� ����� ���������� KSM (flop)

�������� ����� ���������� KSM (Ordu)

�������� ����� ���������� KSM (flop)

�������� ����� ���������� KSM (Ordu)

�������� ����� ���������� KSM (flop)

�������� ����� ���������� KSM (flop)

OpenForum RSS: �� KSM

�� KSM (Ordu)

�� KSM (flop)

�� KSM (Ordu)

�� KSM (flop)

�� KSM (Ordu)

�� KSM (flop)

�� KSM (Ordu)

�� KSM (flop)

�� KSM (flop)