The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Доступен новый гипервизор KSM"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Заметили полезную информацию ? Пожалуйста добавьте в FAQ на WIKI.
. "Доступен новый гипервизор KSM" +/
Сообщение от flop (?), 02-Фев-17, 08:50 
> 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 offset in the parent structure to get a pointer to the parent structure.

> container_of is not a magic way to use pointers into structures as
> substitute for pointers to structures. Because container_of is using explicit casts
> which is bad. Such casts used everywere in kernel not because
> it is a good practice, but because C gives no other
> ways to do some things. Pointer arith even worse, but in
> some cases its the only choice also. Your case is not
> valid case for using pointer arith, expicit casts and container_of.

So you're arguing about pointer arithmetic being bad, but yet your compiler deploys it all day long because of your indirect use, but having a function such as offsetof, invalidates the use, good arguments you make, mate...

> Just add to struct vcpu field `struct ksm *parent', and your vcpu_to_ksm
> will not need any casts anymore. Its completely safe: such a
> pointer will not become dangling, because struct vcpu shares lifetime with
> containing struct ksm. Just do not forget to initialize this pointer.

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

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Доступен новый гипервизор KSM, opennews, 30-Янв-17, 23:38  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру