From: Maynard J. <may...@us...> - 2013-07-08 23:52:08
|
On 07/04/2013 10:47 AM, Gilles Allard wrote: > > ---------- Forwarded Message ---------- > > Subject: Re: [RFC] Oprof_start GUI: port to pure Qt4 & features extension > Date: Thursday, July 04, 2013, 03:35:22 PM > From: Gilles Allard <gil...@or...> > To: Maynard Johnson <may...@us...> > > Maynard > > On Wednesday, July 03, 2013 09:21:47 AM you wrote: >> Gilles, >> Thank you for this proposal. Although I'm not a GUI user, I personally see >> no reason to move to qt4 now, since it's been available in distros for >> several years now. > > Saying "since it's been available in distros" do you mean qt3 ? No, I meant qt4. > Does "move to qt4" means qt4 without any qt3 support ? Yes. > Do you know if someone in the Oprofile project using oprof_start GUI could make > any comment on the first point of that proposal ? No, I don't. If we hear no objections from the community, we'll just do it. > >>> o) A port to pure Qt4, without Qt3Support. As a consequence, it will >>> not be possible to build it using Qt3. The "--enable-gui=qt3" option of >>> configure is removed; the options "--enable-gui=qt4" and >>> "--enable-gui=yes" are now equivalent. >>> >>> oo) oprof_start will be able to run either "opcontrol" or "operf". >>> >>> The user can access 2 "profiling modes" through a "Mode settings" button >>> and its sub-menu. The default profiling mode is currently set to >>> "Opcontrol". >> >> The default mode should be 'operf', unless you have a very convincing >> argument for the legacy 'opcontrol' mode. > > The default mode was "Opcontrol" a week ago; for the most recent release, it Just to be clear, are you saying that the statement "The default profiling mode is currently set to Opcontrol" did not match your latest patch posting? > is "Operf" (for the very first session) and, when quiting, the current profiling > mode is saved in a general config file (not in "operfrc" or "daemonrc") to be > used as the default mode on the next profiling session. > This may be a way to prepare the merge of the config files into a single one > (taken into account that opcontrol needs "dameonrc"). >> >>> The appearence of the main window is modified : all the settings common >>> to both modes are gathered in the "Setting" page along with the list of >>> available events. >>> >>> Each mode has its own private page. >>> Only the page associated to the current profiling mode is visible and >>> switching from one mode to the other is only possible if the profiler >>> is not running. >>> >>> Each page shows all the available : >>> o) "Opcontrol" mode : the profiling parameters of the >>> previous GUI >>> >>> release are available without any modification. >>> >>> o) "Operf" mode : the following settings are available : >>> --append, --callgraph, >>> --separate-cpu, >>> --separate-thread, --system-wide >> >> I presume the default for all of these options is "false". > > Yes it is, just like the "single mode" version of oprof_start > >>> --session-dir, --verbose and --vmlinux >>> settings are sent to >>> >>> the common page as explain above. >> >> Unfortunately, the "--verbose" option is not standard across the three tools >> -- opcontrol, operf, and ocount. Can that be handled seamlessly on the >> common page? > > The mechanism used to switch from one profiling mode to another runs in the > context of the "common page" so that it can access to all settings of this > page. The new mode can very easily disable any common feature (for example the > "verbose" option) > >> It would be good if the current session-dir could be highlighted in some >> way, so that when the user runs post-processing tools (e.g, opreport), >> they'll know to either run the tool in the appropriate directory or specify >> --session-dir appropriately. > > The current session directory is shown in a line edit of the common page and, > if this line is empty, the default value is shown by the associated tool tip. > A tool bar was created at the bottom of the main window where you can see the > current profiling mode, the profiler status (running, stopped, interrupted...) > along with the user's application (in "Operf" mode); I think it will be very > easy to add a 3rd field to show the current session directory. > > >>> --pid, --system-wide and a given user >>> application are mutually >>> >>> exclusive >>> >>> --pid argument can be entered through >>> a dialog showing all >>> >>> the processes running when GUI is launched. >>> >>> A new config file, the path of which is "$HOME/.oprofile/operfrc" is >>> created to be used by operf. It is very similar to "daemonrc"; but >>> "operfrc" is not currently merged with "daemonrc". The user application >>> ( if any ) is saved in this file and will be the default application on >>> the next run. >> >> What other data would be kept in the operfrc file? I can see saving the >> vmlinux filename, and perhaps session-dir. > > All the data in "daemonrc" file are part of "operfrc". I should have mentioned > that "operfrc" is a superset of "daemonrc" : the "USER_APPLICATION" line was > added to build "operfrc" A superset of daemonrc doesn't seem appropriate, since the daemonrc has cached values that aren't needed/used by operf. -Maynard > >> >>> All the other tools ( and libraries ) in the Oprofile package are kept >>> unchanged. >>> >>> ooo) This proposed GUI release can be easily extended to other profiling >>> tools such as the new "ocount" tool. >> >> Nice. >> Thanks again! >> >> -Maynard > ----------------------------------------- > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |