Re: New libgtop maintainer

["Jasper St. Pierre" <jstpierre mecheye net>]

On Sun, Aug 11, 2013 at 7:28 AM, Robert Roth <robert roth off gmail com> wrote:

On Sun, Aug 11, 2013 at 1:45 PM, Jasper St. Pierre <jstpierre mecheye net> wrote:

On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth <robert roth off 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