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

Reply via email to