summaryrefslogtreecommitdiff
path: root/hurd
diff options
context:
space:
mode:
Diffstat (limited to 'hurd')
-rw-r--r--hurd/libfuse.mdwn20
-rw-r--r--hurd/subhurd/discussion.mdwn10
-rw-r--r--hurd/translator/procfs/jkoenig/discussion.mdwn138
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