Harvard Business School of Echec

Aller au contenu | Aller au menu | Aller à la recherche

Tag - linux

Fil des billets

mardi, avril 22 2008

ABI vs. API compatibility

Par benoit12 le mardi, avril 22 2008, 08:39 - GNOME

glibtop_get_proc_mem

libgtop has a function glibtop_get_proc_mem to retrieve basic memory usage of a process. It fills a struct glibtop_proc_mem which looks like:

struct _glibtop_proc_mem
{
	guint64	flags;
	guint64 size;	
	guint64 vsize;
	guint64 resident;
	guint64 share;
	guint64 rss;
	guint64 rss_rlim;
};

Yes, size/vsize and resident/rss look like duplicate. At least on the linux implementation, even if size/vsize and resident/rss come from /proc/self/stat and /proc/self/statm, you can see in linux/fs/proc/{array,task_mmu}.c that they have the same values. So, it seems to me that the only unique members of struct glibtop_proc_mem are size, resident and share (ok there are also flags which flags which members are filled and rss_lim).

linux proportional set size

Linux 2.6.25 comes with a new stat in /proc/self/smaps called pss which is even smarter/accurate than private_dirty. There's glibtop_get_proc_map which currently have all the smaps member but not this new pss. So what is the smarter way to get this new pss in libgtop without breaking everything ?

- break the ABI ?

I could simply extend struct glibtop_proc_map. That would break the ABI, which i'm allowed to because libgtop is desktop. But that's bad practice since packagers have to rebuild everything. That's a painful migration that may delay the adoption of newer versions of the library.

- break the API ?

What about cleaning up the glibtop_proc_mem duplicate members, mark unused some of them and rename rss to pss while keeping it binary compatible ? That would make the API a bit more sensible. I've scanned the Debian/unstable archive and that would break the build 3-6 packages but i would be able to submit trivial patches to fix glibtop_get_proc_mem usage. (And also add glibtop_init(); which are missing everywhere).

- hide pss inside rss ?


So what's best ?

10 commentaires

lundi, septembre 10 2007

loc-srv

Par benoit12 le lundi, septembre 10 2007, 22:44

So this weekend, i used a DSL without any NAT, so my laptop was assigned a public IP by DHCP. My ulog log was spitting a lot, mainly on tcp port loc-srv / 135. Instead of sending REJECT, i opened my iptables and started the following ruby program to actually open all these connections. When someone sends me a SYN, I reply politely.

require 'socket'
require 'etc'

nobody = Etc.getpwnam('nobody')
loc_srv = Socket::getservbyname('loc-srv')

Dir.chroot('/var/run/empty')
Dir.chdir('/')

server = TCPServer.new(loc_srv)

Process::UID.change_privilege(nobody.uid)

print <<"EOF"
uid/euid #{Process.uid}/#{Process.euid}                                                                                                        
chrooted in #{Dir.pwd}                                                                                                                         
listening on address #{server.addr.inspect}                                                                                                    
EOF

clients = []

loop do
  begin
    client = server.accept_nonblock
  rescue Errno::EAGAIN, Errno::ECONNABORTED, Errno::EPROTO, Errno::EINTR
    IO.select([server])
    next
  end

  # remember client so the connection stays opened                                                                                             
  clients << client
  print "#{client.peeraddr.inspect} connected
"
end

This script needs to be started with some privileges in order to bind on 135, but then it drops its priv and chroot to somewhere safe. That was very instructive, after ~10minutes, ss | grep -c loc-srv was reporting more than 280 connections from ~80 differents hosts.

What a storm. I'm definitely safe under my GNU+Linux umbrella :)

And Ruby is fun :)

un commentaire