On Sun, Aug 11, 2013 at 7:28 AM, Robert Roth <robert.roth....@gmail.com>wrote:
> > > > 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. > My case was https://bugzilla.gnome.org/show_bug.cgi?id=663265 It took a while to figure out how everything was generated and pieced together. > 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, > Hm, I didn't know it was supposed to be connectable from the network. In fact, when I read the code a little while ago, I swore it only listened on a UNIX socket. I think we've said that remote DBus is possible, but would take a considerable amount of work to actually get working. I'm not sure how true that is nowadays. 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 > Well, my goal was to get all munging out of libgtop entirely (for Linux, at least) and move to better interfaces entirely. Perhaps /proc/mem/memtotal is a bad example because sysinfo() exists. And we should probably use that instead of parsing /proc/meminfo. > --- > Robert > -- Jasper
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
