On Sun, Aug 11, 2013 at 1:45 PM, Jasper St. Pierre <jstpie...@mecheye.net>wrote:
> On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth <robert.roth....@gmail.com>wrote: > >> Hello everyone, >> >> Matthias Clasen (mclasen) asked me to write and let you know that I will >> be taking over the maintenance of libgtop. >> >> libgtop is the library used by System Monitor and Control Center (if you >> are a developer of an application using libgtop, please let me know) to >> query system information, but unfortunately the development has stalled, >> the last release has happened in 2011, almost two years ago. >> >> My goals for the 3.12 cycle (as we're getting close to the 3.9 freeze, >> only for the next cycle) are to review the buglist of the module, and >> extend it to provide library support for various gnome-system-monitor >> enhancement requests, but in the meantime keep it simple and fast enough to >> back the upcoming Usage application. >> >> Thanks for reading, >> > > I was trying to hack on the libgtop code a little while ago, and I just > found it hard to hack on. The code was generated, and it seemed to be put > together by this giant mess of perl scripts. > I've also hacked some small features in the libgtop code, and wasn't hard, but maybe I took only the low-hanging fruits. Extending existing libgtop implementations (meaning include/... and sysdeps/linux/... code) with new features looked pretty hassle-free for me. Of course, If there are server changes required (I don't know cases when we would need that, I didn't need any so far), it might be hard. > > So, I wonder if it makes sense to stop generating libgtop and instead just > focus on a solid, easily understood codebase. I never really understood why > we had a client/daemon split, either; it doesn't seem that we're doing > anything too fancy on either side. Is it that we require root for reading > some of the files? Should we move to a system DBus service instead? > I guess the client-server split is required for the root access indeed, in that case replacing it with a DBUS system service would be an option, but seems like libgtop is a server indeed, and can be connected to from the network too, and I don't know whether that's possible with DBUS, > > The other thing is that libgtop seems to be munging a lot of procfs files. > I wonder if it'or something (completely made up example). > s possible to investigate new kernel APIs or make ones so that instead of > looking for "MemTotal:" in /proc/meminfo, we could just read > /proc/mem/memtotal > See the discussion in the thread for more details, it's not only about procfs, it's completely different for *BSD systems. The linux implementation could probably be improved by reading /proc/mem/memtotal , but if we read /proc/meminfo for other information anyway, maybe searching for MemTotal: in the file is less expensive than reading another file from procfs --- Robert
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
