Hi! On 20/04/12 00:45, Nicholas Bamber wrote: >> 8.6 Why can't Configure create lsof_owner.h for FreeBSD 6 and above?
>> ... Lsof needs to access elements of that >> lockf_owner structure to determine if a lock belongs to the >> process that has a file open. The goal really is to keep userland tools out of kernel internals to produce better software; that's one of many good things I hope will come as a side effect out of the GNU/kFreeBSD effort. Since the 'freebsd' dialect of lsof has been relying on kernel internals for some time, I expect that code will be in pretty bad shape. You could try to get what you need from the kfreebsd source but I think it would be a bad idea. (A kernel with an incompatible definition might be booted at any time, and no dpkg dependency can help with that). However, if the 'linux' dialect does not depend on kernel source code I think that would make a better starting point. I tried just now with the freebsd/machine.h and Makefile, but replaced the symlinks to use dialect/linux code instead, except for node1/2 and zfs. That way I even managed to build something, which almost looks like it works: > steven@kfreebsd-i386:~/lsof-4.81.dfsg.1+wtf$ ./lsof -c lsof > COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME > lsof 99812 steven cwd DIR 92,2340356138 72 15497 > /home/steven/lsof-4.81.dfsg.1+wtf > lsof 99812 steven rtd DIR 0,71 512 2 / > lsof 99812 steven txt REG 92,2340356138 145071 15837 > /home/steven/lsof-4.81.dfsg.1+wtf/lsof > lsof 99812 steven mem REG 0,0 15837 > /home/steven/lsof-4.81.dfsg.1+wtf/lsof (path dev=92,-1954611158) > lsof 99812 steven mem REG 0,0 117963 > /lib/i386-kfreebsd-gnu/ld-2.13.so (path dev=0,71) > lsof 99812 steven mem REG 0,0 213682 /etc/ld.so.cache > (path dev=0,71) > lsof 99812 steven mem REG 0,0 117953 /lib/libkvm.so.0 > (path dev=0,71) > lsof 99812 steven mem REG 0,0 117809 > /lib/i386-kfreebsd-gnu/i686/cmov/libc-2.13.so (path dev=0,71) > lsof 99812 steven mem REG 0,0 117827 > /lib/i386-kfreebsd-gnu/libbsd.so.0.3.0 (path dev=0,71) > lsof 99812 steven mem REG 0,0 108648 > /usr/lib/locale/locale-archive (path dev=164,284950746) > lsof 99812 steven mem REG 0,0 117898 > /lib/i386-kfreebsd-gnu/i686/cmov/libnss_compat-2.13.so (path dev=0,71) > lsof 99812 steven mem REG 0,0 117829 > /lib/i386-kfreebsd-gnu/i686/cmov/libnsl-2.13.so (path dev=0,71) > lsof 99812 steven mem REG 0,0 117834 > /lib/i386-kfreebsd-gnu/i686/cmov/libnss_nis-2.13.so (path dev=0,71) > lsof 99812 steven mem REG 0,0 117838 > /lib/i386-kfreebsd-gnu/i686/cmov/libnss_files-2.13.so (path dev=0,71) > lsof 99812 steven NOFD /proc/99812/fd > (opendir: No such file or directory) > lsof 99813 steven cwd DIR 92,2340356138 72 15497 > /home/steven/lsof-4.81.dfsg.1+wtf > lsof 99813 steven rtd DIR 0,71 512 2 / > lsof 99813 steven txt REG 92,2340356138 145071 15837 > /home/steven/lsof-4.81.dfsg.1+wtf/lsof > lsof 99813 steven mem REG 0,0 15837 > /home/steven/lsof-4.81.dfsg.1+wtf/lsof (path dev=92,-1954611158) > lsof 99813 steven mem REG 0,0 117963 > /lib/i386-kfreebsd-gnu/ld-2.13.so (path dev=0,71) > lsof 99813 steven mem REG 0,0 213682 /etc/ld.so.cache > (path dev=0,71) > lsof 99813 steven mem REG 0,0 117953 /lib/libkvm.so.0 > (path dev=0,71) > lsof 99813 steven mem REG 0,0 117809 > /lib/i386-kfreebsd-gnu/i686/cmov/libc-2.13.so (path dev=0,71) > lsof 99813 steven mem REG 0,0 117827 > /lib/i386-kfreebsd-gnu/libbsd.so.0.3.0 (path dev=0,71) > lsof 99813 steven mem REG 0,0 108648 > /usr/lib/locale/locale-archive (path dev=164,284950746) > lsof 99813 steven NOFD /proc/99813/fd > (opendir: No such file or directory) Sadly though we're missing /proc/*/fd in linprocfs as you can see. :( No pipes, network or unix-style sockets can be listed either. So it's not very functional yet, but being able to build something is a start. To build this I had to change declarations in machine.h to turn off each bit of code that touches the structs usually guarded by #ifdef _KERNEL as seen in: http://fxr.watson.org/fxr/source/sys/file.h?v=FREEBSD9#L40 I'll try to turn this into some sort of diff. The approach I'd like to take is to add ifdefs into the linux dialect to make that more portable, rather than invent a new one. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org