iotop for EPEL5

[Kirby Zhou]

EPEL5 owns python26 now, can iotop be ported to EPEL5 now?

  Regards
  Kirby Zhou

On Mon, Sep 14, 2009 at 11:10:01AM -0500, BJ Dierkes wrote:
> Hello all,
>
> Per the EPEL meeting last week we are attempting to get iotop working 
> for EL5. The issue is that iotop requires Python >= 2.5 in order to use 
> the builtin netlink support (of the socket module). That said, there is 
> also a fallback on the '_netlink C module':
>
> From /usr/lib/python2.4/site-packages/iotop/netlink.py:
>
> #------------------------------------------------
> try:
> # try to use python 2.5's netlink support
> _dummysock = socket.socket(socket.AF_NETLINK, socket.SOCK_RAW, 0)
> _dummysock.bind((0, 0))
> del _dummysock
> def _nl_bind(descriptor, addr):
> descriptor.bind(addr)
> def _nl_getsockname(descriptor):
> return descriptor.getsockname()
> def _nl_send(descriptor, msg):
> descriptor.send(msg)
> def _nl_recv(descriptor, bufs=16384):
> return descriptor.recvfrom(bufs)
> except socket.error:
> # or fall back to the _netlink C module
> try:
> import _netlink
> except ImportError:
> raise ImportError("This is neither python 2.5 nor is "
> "the _netlink C module available!")
> def _nl_bind(descriptor, addr):
> _netlink.bind(descriptor.fileno(), addr[1])
> def _nl_getsockname(descriptor):
> return _netlink.getsockname(descriptor.fileno())
> def _nl_send(descriptor, msg):
> _netlink.send(descriptor.fileno(), msg)
> def _nl_recv(descriptor, bufs=16384):
> return _netlink.recvfrom(descriptor.fileno(), bufs)
> #------------------------------------------------
>
>
>
> I can't figure out where the '_netlink C module' would be provided, as I 
> was hoping to implement that if possible. All Google hits seem to 
> reference this code.
>
> Any ideas?

Hmm. No. :) Other than askin the iotop guys where they got that
_netlink module from or checking on one of the python development
lists.

I wonder how hard it would be to rip out the python 2.5+ socket module
as an external package and either install it explicitly with iostat in
some non-conflicting way or rename it and install it in some
non-conflicting way that could be used by a patched iostat...

Ray

_______________________________________________
epel-devel-list mailing list
epel-devel-list at xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/epel-devel-list