> However, with the recent discussions of > an eventual build-your-own-state-provider GUI, we are starting to wonder > if it's really worth exposing all the complexity of the statesystem > (attribute tree, paths, etc.) to the end-user.
Somehow the user needs to understand the information available and how to use it to search appropriately. > Custom filters are a bit redundant I think. You can define a custom > column, and then filter on that. I think it's better to have one way of > doing things, or else people get confused... But of course, we would > have to see once we get to the actual implementation. I agree that both boil down to the same thing. It may indeed be more intuitive to specify a virtual column and then filter on it. > Just a note about file opening though, you cannot assume that a file is > opened right at the "sys_open" event. You have to wait for the matching > exit_syscall : if the file opening fails, the return value of the > syscall will indicate so, and no file will be opened by the process. I > would propose assigning the "file opened" state at the exit_syscall ; > it's only then that the process can start using the descriptor. This should indeed be identical to what the Java state provider does. > Finally, as time goes on I'm believing less and less in state > information living in the CTF metadata. Not that it would be a bad idea, > but it would not be very flexible. I'm thinking this information should > belong in the viewer/analysis tool. There is no point creating state > systems containing a LOT of information if the viewer cannot make use of > it. It is also possible to define *different* state providers for the > same trace type: for example, you can get a LOT of stuff from a kernel > trace. But you might not want to build the same state system, depending > if you want to do memory analysis, network analysis, or just seeing > which process uses the most CPU. A sophisticated provider (e.g. MariaDB or a Telecom application) may come with all its definitions (state entry / exit, colors...) in the metadata. A novice user will be very happy with this. A more sophisticated user may want to add to these definitions and even replace some of them, or use different versions for different purposes. Thus, indeed, CTF is one possible default source of such state information but it should be easy to use more than one source. _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
