linux-kernel - [RFC] use of /sys versus /proc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080523131255.C19831F0380@attica.americas.sgi.com>
Date:	Fri, 23 May 2008 08:12:55 -0500
From:	cpw@....com (Cliff Wickman)
To:	linux-kernel@...r.kernel.org
Subject: [RFC] use of /sys versus /proc

I have a need to display TLB shootdown statistics.  (I'm working
on a patch to implement this on a new machine at SGI.)

I had planned to display these statistics through /proc
as in arch/ia64/sn/kernel/sn2/sn2_smp.c (/proc/sgi_sn/ptc_statistics).

However, considering the general move to reserve /proc for
process-related things, I thought the community might prefer the
interface to be in /sys.

But sysfs has an output buffer restriction of one page, which
is too restrictive for statistics from very large cpu counts.
We intend to display about 10 numbers per cpu.

Besides, the spirit of /sys according to the sysfs.txt documentation:
    "Attributes should be ... preferably with only one value
     per file. ... acceptable to express an array of values of the same type."
  [it also  warns:
    "... expressing multiple lines of data, ... is heavily frowned upon.
     Doing these things may get you publically humiliated and your code
     rewritten without notice."]

If I break up the statistics files per-cpu, or maybe ranges of
cpu's, it would create a potentially large number of files in /sys.

Or, I could stick with a single file in /proc.

What would you recommend?

Thanks.
-Cliff Wickman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/