Re: Broken procfs/status, related to kthreads
On Mon, 5 Feb 2001, Bruce Evans wrote: On Sun, 4 Feb 2001, Andrzej Bialecki wrote: According to procfs(5), the status line contains several well-defined fields separated by spaces. However, the kernel thread names look like 'swi5: task queue' and 'swi1: net', which results in variable number of space-separated fields. As a consequence, some software that parses this line gives incorrect results. I think procfs never actually implemented this. Program names may have spaces in them too. Of course, the line is too hard to parse if the first "field" has spaces in it. Only MAXCOMLEN and NAME_MAX prevent the command name being the contents of another process's status line :-). Ok, then how should this be fixed? We could escape the space characters with something: swi5:$task$queue 14 0 0 0 -1,-1 noflags 981365276,40 0,0 0,0 nochan 0 0 0,0 - and for command name 'my$prog': my$$prog 334 1 332 0 -1,-1 noflags 981361691,37404 0,0 0,5748 select 0 0 0,0 - or similar... The commands with $ in them are much less likely than the names with spaces, which on -current are guaranteed to occur. Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Broken procfs/status, related to kthreads
In local.freebsd.current you write: On Mon, 5 Feb 2001, Bruce Evans wrote: [...] I think procfs never actually implemented this. Program names may have spaces in them too. Of course, the line is too hard to parse if the first "field" has spaces in it. Only MAXCOMLEN and NAME_MAX prevent the command name being the contents of another process's status line :-). Ok, then how should this be fixed? We could escape the space characters with something: swi5:$task$queue 14 0 0 0 -1,-1 noflags 981365276,40 0,0 0,0 nochan 0 0 0,0 - and for command name 'my$prog': my$$prog 334 1 332 0 -1,-1 noflags 981361691,37404 0,0 0,5748 select 0 0 0,0 - or similar... IMHO a correct solution would be to use a separator that cannot occur in any of the fields. All fields but the command name can be considered "well behaved" (= under control by procfs), and the command name is subject to file name limitations: that leaves NUL, "\n" and maybe "/" (of only the basename is shown) as safe separators. The "cmdline" file seems to solve the problem by using NULs. Come to think of it: another solution, in this case, would be to put the command name last on the line: anything beyond field N is the command name, including any spaces. But, please, no quoting. $.02, /Mikko -- Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Broken procfs/status, related to kthreads
On Mon, Feb 05, 2001, Andrzej Bialecki wrote: Ok, then how should this be fixed? We could escape the space characters with something: swi5:$task$queue 14 0 0 0 -1,-1 noflags 981365276,40 0,0 0,0 nochan 0 0 0,0 - and for command name 'my$prog': my$$prog 334 1 332 0 -1,-1 noflags 981361691,37404 0,0 0,5748 select 0 0 0,0 - or similar... The commands with $ in them are much less likely than the names with spaces, which on -current are guaranteed to occur. .. or we output information in a new file (say, /proc/$pid/stat?) which looks like the rlimit output? I like that idea better. adrian -- Adrian Chadd"Programming is like sex: [EMAIL PROTECTED] One mistake and you have to support for a lifetime." -- rec.humor.funny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Broken procfs/status, related to kthreads
Hi, Whoever made procfs aware of kernel threads broke also the /proc/%pid/status line. Or, maybe it's a by-product of showing kthreads in the proc table... According to procfs(5), the status line contains several well-defined fields separated by spaces. However, the kernel thread names look like 'swi5: task queue' and 'swi1: net', which results in variable number of space-separated fields. As a consequence, some software that parses this line gives incorrect results. I noticed this while trying to fix mysterious coredumps in src/release/picobsd/tinyware/aps (which is obsolete anyway, but it should work). Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Broken procfs/status, related to kthreads
On Sun, 4 Feb 2001, Andrzej Bialecki wrote: According to procfs(5), the status line contains several well-defined fields separated by spaces. However, the kernel thread names look like 'swi5: task queue' and 'swi1: net', which results in variable number of space-separated fields. As a consequence, some software that parses this line gives incorrect results. I think procfs never actually implemented this. Program names may have spaces in them too. Of course, the line is too hard to parse if the first "field" has spaces in it. Only MAXCOMLEN and NAME_MAX prevent the command name being the contents of another process's status line :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
