API /proc/pid/status가 /proc/pid/stat를 더 이상 사용하지 않아야/할 수 있다고 가정합니까?

GNU/Linux에서 사용할 수 있는 프로세스 정보에 대해 몇 가지 질문이 있습니다.프로세스 파일 시스템. 이는 처음에는 애플리케이션에서 vmPeak, vmSize, vmRSS 및 vmHWM을 추출하려는 욕구 때문이었습니다.

/proc/<pid>/status사람이 읽을 수 있는 버전은 /proc/<pid>/stat기계가 읽을 수 있다는 가정으로 시작합니다. kernel.org 댓글:

stat - 프로세스 상태

status - 사람이 읽을 수 있는 형식의 프로세스 상태

나는 깨달았을 때 이것이 옳지 않다는 것을 깨달았습니다.가상 피크에서만 구매하실 수 있습니다 /proc/pid/status.

/proc/pid/status실제로 여러 곳의 가치를 결합하고 그 자체의 가치를 일부 추가하는 것처럼 보입니다 .

우리가 /proc/pid/status사용할 이유가 있다면 /proc/pid/stat? 그것이 필요한 이유는 무엇입니까? API가 두 개 있는 이유는 무엇입니까? 더 이상 /proc/pid/stat사용되지 않거나 유용할 수 있습니까?

stat동등하지 않습니다. 더 적은 수의 필드를 제공합니다. 구문 분석하기가 약간 더 쉽습니다(사용순진하게 하면 미묘한 오류가 발견될 수 있습니다.). stat를 사용하는 모든 프로그램은 상태를 사용하도록 쉽게 전환할 수 있습니다. 실제로 몇 개나 깨질 수 있습니까?

방금 두 가지 모두에 대해 파서를 작성했습니다(비록 API가 별로 유용하지 않았기 때문에 통계용으로 파서를 사용하게 되었지만). 기계가 읽을 수 있는 콘텐츠는 많지 않습니다. 실제로 "상태"에 대한 파서는 원하는 모든 종류의 키-값 저장소로 직접 읽을 수 있기 때문에 더 우아해집니다. 상태는 모든 언어에서 구문 분석하기가 더 쉽고 확장 가능합니다.

실제로 "상태" 대신 "상태"에 의존하는 프로그램은 몇 개입니까? 그들 중 실제로 이것이 제공할 수 있는 미미한 구문 분석 속도가 필요한 것이 있습니까?

이제 나는 이전 버전과의 호환성으로 인해 통계를 수년 동안 제거할 수 없다는 것을 이해하지만, 유지해야 할 합당한 이유가 없으면 "이제 더 이상 사용되지 않습니다"라고 말할 수 있습니다(이것이 내 질문에 대한 가능한 답변이 될 것입니다).

성능이 문제인 경우 가상 파일 시스템을 통해 이 커널 정보를 텍스트로 변환하고 다시 역으로 변환하는 성능은 라이브러리 호출 성능보다 확실히 낮습니다.

지속적으로 새로운 API를 추가하는 것은 짜증날 수 있습니다.이 답변제안이지만 대부분이 안정적이라는 점을 감안할 때 C 라이브러리 API가 없는 이유는 무엇입니까?시스템 메시지?