From owner-freebsd-current Mon Feb 5 9:48:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by hub.freebsd.org (Postfix) with SMTP id 62F7337B491 for ; Mon, 5 Feb 2001 09:48:12 -0800 (PST) Received: (qmail 60170 invoked from network); 5 Feb 2001 17:48:10 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by 172.16.1.1 with SMTP; 5 Feb 2001 17:48:10 -0000 Received: (qmail 29658 invoked from network); 5 Feb 2001 17:48:09 -0000 Received: from explorer.rsa.com (10.81.217.59) by spirit.dynas.se with SMTP; 5 Feb 2001 17:48:09 -0000 Received: (from mikko@localhost) by explorer.rsa.com (8.11.1/8.11.1) id f15Hm1976448; Mon, 5 Feb 2001 09:48:01 -0800 (PST) (envelope-from mikko) Date: Mon, 5 Feb 2001 09:48:01 -0800 (PST) From: Mikko Tyolajarvi Message-Id: <200102051748.f15Hm1976448@explorer.rsa.com> To: abial@webgiro.com Cc: freebsd-current@freebsd.org Subject: Re: Broken procfs/status, related to kthreads Newsgroups: local.freebsd.current References: X-Newsreader: NN version 6.5.6 (NOV) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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ärvi_______________________________________mikko@rsasecurity.com RSA Security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message