2012-03-19 16 views
14

Según man 5 proc, se puede utilizar el sistema de archivos /proc para acceder a la siguiente información en Linux:¿Cuál es la mejor manera de leer desde las interfaces Linux/proc utilizando el código de espacio de usuario C?

/proc/[pid]/maps 
      A file containing the currently mapped memory regions and their access 
      permissions. 

      The format is: 

      address   perms offset dev inode pathname 
      08048000-08056000 r-xp 00000000 03:0c 64593 /usr/sbin/gpm 
      08056000-08058000 rw-p 0000d000 03:0c 64593 /usr/sbin/gpm 
      08058000-0805b000 rwxp 00000000 00:00 0 
      40000000-40013000 r-xp 00000000 03:0c 4165 /lib/ld-2.2.4.so 
      40013000-40015000 rw-p 00012000 03:0c 4165 /lib/ld-2.2.4.so 
      4001f000-40135000 r-xp 00000000 03:0c 45494 /lib/libc-2.2.4.so 
      40135000-4013e000 rw-p 00115000 03:0c 45494 /lib/libc-2.2.4.so 
      4013e000-40142000 rw-p 00000000 00:00 0 
      bffff000-c0000000 rwxp 00000000 00:00 0 

      where "address" is the address space in the process that it occupies, 
      "perms" is a set of permissions: 

       r = read 
       w = write 
       x = execute 
       s = shared 
       p = private (copy on write) 

      "offset" is the offset into the file/whatever, "dev" is the device 
      (major:minor), and "inode" is the inode on that device. 0 indicates 
      that no inode is associated with the memory region, as the case would 
      be with BSS (uninitialized data). 

      Under Linux 2.0 there is no field giving pathname. 

Realmente no quiero estar escribiendo código de análisis de texto en C; Prefiero simplemente hacer llamadas al sistema operativo y leer la información directamente en las estructuras. Busqué en /usr/include/linux para ver si había una estructura obvia con las API, pero no vi nada.

Así, dos preguntas parte:

  1. Puede esto ser considerada como una "mala idea"? Es decir, ¿los programas de usuario simplemente muerden la viñeta y leen el texto de /proc en caso de que las interfaces del kernel cambien? Si es así, ¿hay una "mejor práctica" aceptada para leer desde /proc usando C? (fscanf()? Expresiones regulares?)
  2. ¿Qué debo hacer para encontrar la documentación para las interfaces del núcleo (suponiendo que existan) que me permita leer estos datos directamente? (¿Es el origen del kernel en sí el mejor lugar para comenzar? En caso afirmativo, ¿en qué parte del núcleo debo buscar?) Puntos de bonificación si sabe qué interfaz puede proporcionar los datos de /proc/[pid]/maps específicamente. =)
+0

Busybox "superior" al menos lee/archivos de proc y los raspa la pantalla. Creo que hay diversa información que no está disponible de otra manera desde Userland. Es feo, sin embargo. – blueshift

+0

parece sencillo con 'strtok' y' atoi'.''\ n'' es un separador de registros,'' ''es un separador de campo, y luego' perms' probablemente necesitará una cantidad mínima de lógica especial. – bkconrad

+0

usando sscanf es más rápido que 'strtok' y' atoi'. – Paschalis

Respuesta

8

Creo que para un script de perl o de shell es perfectamente correcto leer y analizar el/proc/data. En un programa C, si se requiere robustez, usaría una interfaz kernel (probablemente una sysctl).

Resulta que el procps-bundled pmap implementation un análisis sintáctico /proc/PID/maps archivos línea por línea de la siguiente manera (ver one_proc() función):

sscanf(mapbuf,"%"KLF"x-%"KLF"x %31s %Lx %x:%x %Lu", &start, &end, flags, &file_offset, &dev_major, &dev_minor, &inode); 

EDITAR: Versión original de mi respuesta mostró una manera de analizar los datos de la memoria compartida solo segmentos, no todos segmentos de memoria mapeados como el OP deseado.

Creo que ipcs -m le dará los mismos datos para múltiples procesos. Así que la respuesta a la segunda pregunta es que usted debe leer el código ipcs: (por ejemplo BSD version, Linux version):

+0

Gracias por la sugerencia. Acabo de echar un vistazo a 'ipcs' y parece que no acaba de hacer lo que quiero, pero seguiré echando un vistazo para ver si su código fuente puede llevarme en la dirección correcta. – mpontillo

+0

@Mike También encontré la fuente para la versión de Linux de la utilidad. Creo que el extracto de la fuente que pegué en la respuesta debería darle suficiente información sobre cómo consultar y analizar los datos que necesita. –

+0

Para esas partes de código no triviales, creo que debería incluir las declaraciones de licencia del código en esos fragmentos que publicó. –

2

lectura secuencial de texto pseudo-archivos como /proc/self/maps es la forma canónica, en Linux, para obtener esa información (y hay no es una manera fácil de obtenerlo de otra manera, es la forma en que el kernel lo está dando).

Puede usar alguna biblioteca (como libproc) que lo haga por usted. Pero al final su aplicación analizará (quizás a través de algunas bibliotecas) los archivos bajo /proc. No estoy seguro de que tengas razón para evitar eso.

Intente ejecutar un comando como ps o top con /proc siendo desmontado. Probablemente ya no funcionará.

1

proporciona una manera conveniente de acceder al contenido bajo /proc.

Cuestiones relacionadas