diff options
Diffstat (limited to 'hurd')
| -rw-r--r-- | hurd/libfuse.mdwn | 20 | ||||
| -rw-r--r-- | hurd/subhurd/discussion.mdwn | 10 | ||||
| -rw-r--r-- | hurd/translator/procfs/jkoenig/discussion.mdwn | 138 |
3 files changed, 154 insertions, 14 deletions
diff --git a/hurd/libfuse.mdwn b/hurd/libfuse.mdwn index 45ff97ec..78e96022 100644 --- a/hurd/libfuse.mdwn +++ b/hurd/libfuse.mdwn @@ -29,6 +29,26 @@ etc. * File I/O is quite slow. +## IRC, freenode, #hurd, 2013-05-31 + + <zacts> well the reason I'm asking, is I'm wonder about the eventual + possibility of zfs on hurd + <pinotree> no, zfs surely not + <zacts> *wondering + <zacts> pinotree: would that be because of license incompatabilities, or + technical reasons? + <pinotree> the latter + <taylanub> It's just a matter of someone sitting down and implementing it + though, not ? + <pinotree> possibly + <braunr> zacts: the main problem seems to be the interactions between the + fuse file system and virtual memory (including caching) + <braunr> something the hurd doesn't excel at + <braunr> it *may* be possible to find existing userspace implementations + that don't use the system cache (e.g. implement their own) + <braunr> and they could almost readily use our libfuse version + + # Source [[source_repositories/incubator]], libfuse/master. diff --git a/hurd/subhurd/discussion.mdwn b/hurd/subhurd/discussion.mdwn index 6e694677..fac93625 100644 --- a/hurd/subhurd/discussion.mdwn +++ b/hurd/subhurd/discussion.mdwn @@ -170,3 +170,13 @@ License|/fdl]]."]]"""]] <zacts> ah ok <braunr> in theory, subhurds can run without root privileges <braunr> (but there are currently a few things that prevent it) + + +## IRC, freenode, #hurd, 2011-06-07 + + <zacts> would hurd jails be more powerful than FreeBSD jails? how so? + <braunr> not more powerful + <braunr> easier to develop + <braunr> safer + <braunr> perhaps more powerful too, but that entirely depends on the + features you want inside diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 00215dec..197461b8 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -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 - <youpi> jkoenig: is it not possible to provide a /proc/self which points at - the client's pid? <pinotree> (also, shouldn't /proc/version say something else than "Linux"?) <youpi> to make linux tools work, no :/ <youpi> kfreebsd does that too @@ -33,10 +34,103 @@ IRC, #hurd, around September 2010 <youpi> Linux version 2.6.16 (des@freebsd.org) (gcc version 4.3.5) #4 Sun Dec 18 04:30:00 CET 1977 <pinotree> k - <giselher> I had some problems with killall5 to read the pid from /proc, Is - this now more reliable? - <youpi> I haven't tested with jkoenig's implementation - [...] + + +## IRC, freenode, #hurd, 2013-06-04 + + <safinaskar> ?@?#@?$?@#???!?!?!?!??!?!?!?! why /proc/version on gnu system + reports "Linux version 2.6.1 (GNU 0.3...)"? + <braunr> safinaskar: because /proc/version is a linux thing + <braunr> applications using it don't expect to see anything else than linux + when parsing + <braunr> think of it as your web brower allowing you to set the user-agent + <safinaskar> braunr: yes, i just thought about user-agent, too + <safinaskar> braunr: but freebsd doesn't report it is linux (as well as i + know) + <braunr> their choice + <braunr> we could change it, but frankly, we don't care + <safinaskar> so why "uname" says "GNU" and not "Linux"? + <braunr> uname is posix + <braunr> note that /proc/version also includes GNU and GNU Mach/Hurd + versions + <safinaskar> if some program read the word "Linux" from /proc/version, it + will assume it is linux. so, i think it is bad idea + <braunr> why ? + <safinaskar> there is no standard /proc across unixen + <braunr> if a program reads /proc/version, it expects to be run on linux + <safinaskar> every unix implement his own /proc + <safinaskar> so, we don't need to create /proc which is fully compatible + with linux + <braunr> procfs doesn't by default + <safinaskar> instead, we can make /proc, which is partially compatible with + linux + <braunr> debiansets the -c compatibility flag + <braunr> that's what we did + <safinaskar> but /proc/version should really report kernel name and its + version + <braunr> why ? + <braunr> (and again, it does) + <safinaskar> because this is why /proc/version created + <pinotree> no? + <braunr> on linux, yes + <braunr> pinotree: hm ? + <safinaskar> and /proc/version should not contain the "Linux" word, because + this is not Linux + <braunr> pinotree: no to what ? :) + <braunr> safinaskar: *sigh* + <braunr> i explained the choice to you + <pinotree> safinaskar: if you are using /proc/version to get the kernel + name and version, you're doing bad already + <braunr> disagree if you want + <braunr> but there is a point to using the word Linux there + <pinotree> safinaskar: there's the proper aposix api for that, which is + uname + <safinaskar> pinotree: okey. so why we ever implement /proc/version? + <braunr> it's a linux thing + <braunr> they probably wanted more than what the posix api was intended to + do + <safinaskar> 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 + <pinotree> and even on freebsd their linprocfs (mounted on /proc) is not + mounted by default + <braunr> 10:37 < braunr> applications using it don't expect to see anything + else than linux when parsing + <braunr> 10:37 < braunr> think of it as your web brower allowing you to set + the user-agent + <braunr> safinaskar: the answer hasn't changed + <safinaskar> pinotree: but they don't export /proc/version with "Linux" + word in it anyway + <pinotree> safinaskar: they do + <safinaskar> pinotree: ??? their /proc/version contain Linux? + <pinotree> Linux version 2.6.16 (des@freebsd.org) (gcc version 4.6.3) #4 + Sun Dec 18 04:30:00 CET 1977 + <kilobug> 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 + <pinotree> that's on a debian gnu/kfreebsd machine + <pinotree> and on a freebsd machine it is the same + <braunr> safinaskar: you should understand that parsing this string allows + correctly walking the rest of the /proc tree + <pinotree> and given such filesystem on freebsd is called "linprocfs", you + can already have a guess what it is for + <kilobug> 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" + <safinaskar> so, is there really a lot of programs which expect "Linux" + word in /proc/version even on non-linux platforms? + <braunr> no + <braunr> but when they do, they do + + +# `/proc/self` + +## IRC, freenode, #hurd, around 2010-09 + + <youpi> jkoenig: is it not possible to provide a /proc/self which points at + the client's pid? <pinotree> looks like he did 'self' too, see rootdir_entries[] in rootdir.c <youpi> but it doesn't point at self <antrik> youpi: there is no way to provide /proc/self, because the server @@ -59,7 +153,7 @@ IRC, #hurd, around September 2010 # root group -IRC, #hurd, around October 2010 +## IRC, freenode, #hurd, around October 2010 <pinotree> the only glitch is that files/dirs have the right user as owner, but always with root group @@ -67,7 +161,7 @@ IRC, #hurd, around October 2010 # `/proc/[PID]/stat` being 400 and not 444, and some more -IRC, freenode, #hurd, 2011-03-27 +## IRC, freenode, #hurd, 2011-03-27 <pochu> is there a reason for /proc/$pid/stat to be 400 and not 444 like on Linux? @@ -112,7 +206,8 @@ IRC, freenode, #hurd, 2011-03-27 /proc uses rather than rely on CLK_TCK <jkoenig> (so we can choose whatever reasonable value we want) -IRC, freenode, #hurd, 2011-03-28 + +## IRC, freenode, #hurd, 2011-03-28 <antrik> jkoenig: does procfs expose any information that is not available to everyone through the proc server?... @@ -165,7 +260,8 @@ IRC, freenode, #hurd, 2011-03-28 <antrik> (though I never got around to look at his buggy code...) <jkoenig> ok -IRC, freenode, #hurd, 2011-07-22 + +## IRC, freenode, #hurd, 2011-07-22 <pinotree> hm, why /proc/$pid/stat is 600 instead of 644 of linux? <jkoenig> pinotree, it reveals information which, while not that sensitive, @@ -186,7 +282,7 @@ IRC, freenode, #hurd, 2011-07-22 # `/proc/mounts`, `/proc/[PID]/mounts` -IRC, freenode, #hurd, 2011-07-25 +## IRC, freenode, #hurd, 2011-07-25 < pinotree> jkoenig: btw, what do you think about providing empty /proc/mounts and /proc/$pid/mounts files? @@ -206,8 +302,16 @@ 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` + +# `/proc/[PID]/auxv` + +Needed by glibc's `pldd` tool (commit +11988f8f9656042c3dfd9002ac85dff33173b9bd). + + +# `/proc/[PID]/exe` Needed by glibc's `pldd` tool (commit 11988f8f9656042c3dfd9002ac85dff33173b9bd). @@ -323,6 +427,12 @@ Also used in `[GCC]/intl/relocatable.c`:`find_shared_library_fullname` for `#ifdef __linux__`. +# `/proc/[PID]/mem` + +Needed by glibc's `pldd` tool (commit +11988f8f9656042c3dfd9002ac85dff33173b9bd). + + # `/proc/[PID]/cwd` ## IRC, freenode, #hurd, 2012-06-30 |