From 9667351422dec0ca40a784a08dec7ce128482aba Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 10 Jul 2013 23:39:29 +0200 Subject: IRC. --- hurd/translator/procfs/jkoenig/discussion.mdwn | 114 +++++++++++++++++++++++-- 1 file changed, 105 insertions(+), 9 deletions(-) (limited to 'hurd/translator/procfs') diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index d26f05f9..2ba98150 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -14,12 +14,13 @@ License|/fdl]]."]]"""]] [[!toc]] -# Miscellaneous +# `/proc/version` -IRC, #hurd, around September 2010 +[[!taglink open_issue_documentation]]: edit and move to [[FAQ]]. + + +## IRC, freenode, #hurd, around 2010-09 - jkoenig: is it not possible to provide a /proc/self which points at - the client's pid? (also, shouldn't /proc/version say something else than "Linux"?) to make linux tools work, no :/ kfreebsd does that too @@ -33,10 +34,103 @@ IRC, #hurd, around September 2010 Linux version 2.6.16 (des@freebsd.org) (gcc version 4.3.5) #4 Sun Dec 18 04:30:00 CET 1977 k - I had some problems with killall5 to read the pid from /proc, Is - this now more reliable? - I haven't tested with jkoenig's implementation - [...] + + +## IRC, freenode, #hurd, 2013-06-04 + + ?@?#@?$?@#???!?!?!?!??!?!?!?! why /proc/version on gnu system + reports "Linux version 2.6.1 (GNU 0.3...)"? + safinaskar: because /proc/version is a linux thing + applications using it don't expect to see anything else than linux + when parsing + think of it as your web brower allowing you to set the user-agent + braunr: yes, i just thought about user-agent, too + braunr: but freebsd doesn't report it is linux (as well as i + know) + their choice + we could change it, but frankly, we don't care + so why "uname" says "GNU" and not "Linux"? + uname is posix + note that /proc/version also includes GNU and GNU Mach/Hurd + versions + if some program read the word "Linux" from /proc/version, it + will assume it is linux. so, i think it is bad idea + why ? + there is no standard /proc across unixen + if a program reads /proc/version, it expects to be run on linux + every unix implement his own /proc + so, we don't need to create /proc which is fully compatible + with linux + procfs doesn't by default + instead, we can make /proc, which is partially compatible with + linux + debiansets the -c compatibility flag + that's what we did + but /proc/version should really report kernel name and its + version + why ? + (and again, it does) + because this is why /proc/version created + no? + on linux, yes + pinotree: hm ? + and /proc/version should not contain the "Linux" word, because + this is not Linux + pinotree: no to what ? :) + safinaskar: *sigh* + i explained the choice to you + safinaskar: if you are using /proc/version to get the kernel + name and version, you're doing bad already + disagree if you want + but there is a point to using the word Linux there + safinaskar: there's the proper aposix api for that, which is + uname + pinotree: okey. so why we ever implement /proc/version? + it's a linux thing + they probably wanted more than what the posix api was intended to + do + okey, so why we need this linux thing? there is a lot of + linux thing which is useful in hurd. but not this thing. because this + is not linux. if we support /proc/version, we should not write "Linux" + to it + and even on freebsd their linprocfs (mounted on /proc) is not + mounted by default + 10:37 < braunr> applications using it don't expect to see anything + else than linux when parsing + 10:37 < braunr> think of it as your web brower allowing you to set + the user-agent + safinaskar: the answer hasn't changed + pinotree: but they don't export /proc/version with "Linux" + word in it anyway + safinaskar: they do + pinotree: ??? their /proc/version contain Linux? + Linux version 2.6.16 (des@freebsd.org) (gcc version 4.6.3) #4 + Sun Dec 18 04:30:00 CET 1977 + safinaskar: it's like all web browsers reporting "mozilla" in + their UA, it may be silly, but it's how it is for + compatibility/historical reasons, and it's just not worth the trouble of + changing it + that's on a debian gnu/kfreebsd machine + and on a freebsd machine it is the same + safinaskar: you should understand that parsing this string allows + correctly walking the rest of the /proc tree + and given such filesystem on freebsd is called "linprocfs", you + can already have a guess what it is for + safinaskar: saying "Linux version 2.6.1" just means "I'm + compatible with Linux 2.6.1 interfaces", like saying "Mozilla/5.0 (like + Gecko)" in the UA means "I'm a modern browser" + so, is there really a lot of programs which expect "Linux" + word in /proc/version even on non-linux platforms? + no + but when they do, they do + + +# `/proc/self` + +## IRC, freenode, #hurd, around 2010-09 + + jkoenig: is it not possible to provide a /proc/self which points at + the client's pid? looks like he did 'self' too, see rootdir_entries[] in rootdir.c but it doesn't point at self youpi: there is no way to provide /proc/self, because the server @@ -206,6 +300,8 @@ IRC, freenode, #hurd, 2011-07-25 i don't remember) < pinotree> not a strict need +See also [[community/gsoc/project_ideas/mtab]]. + # `/proc/[PID]/auxv`, `/proc/[PID]/exe`, `/proc/[PID]/mem` -- cgit v1.2.3