Concerning KEDR platform and KEDR tools
53 views
Skip to first unread message
Eugene A. Shatokhin
Nov 2, 2012, 3:44:06 AM11/2/12
to kedr-d...@googlegroups.com
Concerning http://code.google.com/p/kedr/issues/detail?id=7: I suppose, the proposal could better be discussed here, in the open.
My current understanding is that most of the users do not distinguish KEDR as a platform and the tools that are based on this platform, so I agree with this point.
In short, I think this confusion makes no harm. We should of course rethink how to position KEDR when planning version 1.x. I would not bother with the docs until then, because there are things of higher priority to do, e.g. finding more bugs in the real-world kernel-mode software.
The longer explanation of my point is below.
KEDR is not alone facing this issue. A similar confusion exists around Valgrind, for example. Many of its users think Valgrind is a tool to check the correctness of memory-related operations. Its however a Valgrind-based tool called Memcheck they are actually talking about, one of the most widely used Valgrind-based tools. Valgrind itself is a dynamic binary instrumentation framework, a "platform", as we would call it.
Even in the description of the packages with Valgrind provided by major Linux distros, you can find the following:
"valgrind - Memory Management Debugger
Valgrind checks all memory operations in an application, like read, write, malloc, new, free, and delete. Valgrind can find uses of uninitialized memory, access to already freed memory, overflows, illegal stack operations, memory leaks, and any illegal new/malloc/free/delete commands. Another program in the package is "cachegrind," a profiler based on the valgrind engine."
This is from OpenSUSE 12.2.
It seems, this confusion did not make Valgrind-based tools less popular and less widely used. It is usually clear from the context, which meaning of Valgrind is implied, so it makes no harm.
I suppose the distinction of KEDR as a platform and of the tools based on that platform is currently only significant for us, developers of KEDR, but not for the users.
As far as I see it, "KEDR" may mean the following:
- the platform, i.e. the components that allow to build data collection and analysis tools for Linux kernel modules;
- the data collection and analysis tools for Linux kernel modules we have developed using that platform;
- the framework, containing all of the above.
The point is, the users probably don't care about all that. Most of those who I have talked to so far needed just the tools to detect problems in their kernel modules. They were interested in solving their problems, in a quick, easy and reliable way.
Perhaps, for KEDR 1.x, it could be better to provide something like a "Cookbook" with a very brief overview of KEDR framework, with the installation instructions and the detailed recipes of how to solve particular problems with it. There could be parts there concerning fault simulation, detection of memory leaks and call monitoring there. The rest would go to the collection of developer docs, also public in case someone would be interested, but kept separate.
The bottom line is, while I agree the confusion exists, I do not think anyone should bother updating the docs now. Let us better find more bugs in the real-world kernel-mode software to prove KEDR is good at it and fix these bugs to draw the attention of the respective developers and maintainers.
Regards,
Eugene
My current understanding is that most of the users do not distinguish KEDR as a platform and the tools that are based on this platform, so I agree with this point.
In short, I think this confusion makes no harm. We should of course rethink how to position KEDR when planning version 1.x. I would not bother with the docs until then, because there are things of higher priority to do, e.g. finding more bugs in the real-world kernel-mode software.
The longer explanation of my point is below.
KEDR is not alone facing this issue. A similar confusion exists around Valgrind, for example. Many of its users think Valgrind is a tool to check the correctness of memory-related operations. Its however a Valgrind-based tool called Memcheck they are actually talking about, one of the most widely used Valgrind-based tools. Valgrind itself is a dynamic binary instrumentation framework, a "platform", as we would call it.
Even in the description of the packages with Valgrind provided by major Linux distros, you can find the following:
"valgrind - Memory Management Debugger
Valgrind checks all memory operations in an application, like read, write, malloc, new, free, and delete. Valgrind can find uses of uninitialized memory, access to already freed memory, overflows, illegal stack operations, memory leaks, and any illegal new/malloc/free/delete commands. Another program in the package is "cachegrind," a profiler based on the valgrind engine."
This is from OpenSUSE 12.2.
It seems, this confusion did not make Valgrind-based tools less popular and less widely used. It is usually clear from the context, which meaning of Valgrind is implied, so it makes no harm.
I suppose the distinction of KEDR as a platform and of the tools based on that platform is currently only significant for us, developers of KEDR, but not for the users.
As far as I see it, "KEDR" may mean the following:
- the platform, i.e. the components that allow to build data collection and analysis tools for Linux kernel modules;
- the data collection and analysis tools for Linux kernel modules we have developed using that platform;
- the framework, containing all of the above.
The point is, the users probably don't care about all that. Most of those who I have talked to so far needed just the tools to detect problems in their kernel modules. They were interested in solving their problems, in a quick, easy and reliable way.
Perhaps, for KEDR 1.x, it could be better to provide something like a "Cookbook" with a very brief overview of KEDR framework, with the installation instructions and the detailed recipes of how to solve particular problems with it. There could be parts there concerning fault simulation, detection of memory leaks and call monitoring there. The rest would go to the collection of developer docs, also public in case someone would be interested, but kept separate.
The bottom line is, while I agree the confusion exists, I do not think anyone should bother updating the docs now. Let us better find more bugs in the real-world kernel-mode software to prove KEDR is good at it and fix these bugs to draw the attention of the respective developers and maintainers.
Regards,
Eugene
Andrey Tsyvarev
Jan 29, 2015, 4:27:27 AM1/29/15
to kedr-d...@googlegroups.com
Привет, Жень
Продолжаю разбирать пропущенные письма с этого ящика)
Да, ты, пожалуй, прав: пусть все называется KEDR, и платформа, и наши инструменты, написанные под нее.
Действительно, так проще объяснять обычным пользователям, что те или иные вещи можно выполнить с помощью KEDR. Поймал себя на мысли, что студентам я это объясняю именно так.
Но, когда при описании надо углубляться в ту или иную возможность KEDR (например, в документации на KEDR), без уточняющих слов предмет обсуждения становится размытым. В документации используется "fault simulation" и "LeakCheck", иногда со словом "facility". В документации на KEDR само слово "KEDR", понятно, часто опускается(но подразумевается). Таким образом, для внешние ссылки на возможности KEDR будут такие: "KEDR fault simulation facility", "KEDR LeakCheck facility". По мне, "KEDR Fault Simulation" и "KEDR Leak Check" будет более удобной формой таких ссылок. Кроме того, такие ссылки останутся неизменными и при переводе на русский язык.
Собственно, предлагаю в документации упомянуть, что "KEDR Fault Simulation" это синоним для "KEDR fault simulation facility", а "KEDR Leak Check" - для "KEDR LeakCheck facility".
Андрей
Eugene Shatokhin
Jan 30, 2015, 2:41:21 AM1/30/15
to kedr-d...@googlegroups.com
Привет, Андрей!
Да, разумно.
Евгений
> --
> You received this message because you are subscribed to the Google Groups
> "kedr-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kedr-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Да, разумно.
Евгений
> You received this message because you are subscribed to the Google Groups
> "kedr-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kedr-discuss...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages