summaryrefslogtreecommitdiff
path: root/hurd
diff options
context:
space:
mode:
Diffstat (limited to 'hurd')
-rw-r--r--hurd/libdiskfs.mdwn42
-rw-r--r--hurd/libstore/examples/ramdisk/discussion.mdwn72
-rw-r--r--hurd/running/virtualbox.mdwn5
-rw-r--r--hurd/translator/tmpfs/notes_various.mdwn8
4 files changed, 127 insertions, 0 deletions
diff --git a/hurd/libdiskfs.mdwn b/hurd/libdiskfs.mdwn
new file mode 100644
index 00000000..dd499785
--- /dev/null
+++ b/hurd/libdiskfs.mdwn
@@ -0,0 +1,42 @@
+[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+
+# Paging
+
+In the course of Maksym's [[translator/tmpfs]] work:
+
+IRC, freenode, #hurd, 2011-10-24:
+
+ <mcsim> I've compared the way pagers are handled in ext2fs and found out
+ that for every file new pager is created when occurs reading or writing
+ to this file. Is it necessary? And can one pager handle several memory
+ objects?
+ <antrik> mcsim: yes, this in necessary. one pager port corresponds to one
+ memory object
+ <antrik> mcsim: note that a pager, from the kernel's point of view, is
+ essentially just the port used to communicated with the process
+ responsible for paging the object. how your process manages multiple
+ pager ports is up to you
+ <mcsim> so, how can I attach those pager_* functions, which are declared
+ now in pager-stubs.c to new pager?
+ <mcsim> or is it done automatically with all pagers, which I create, If
+ only I'm not using default one?
+ <antrik> I'm not sure how libpager works; but I suspect it's based on
+ libports. you probably need a port class for the pager ports, and add the
+ port for each new pager your create to that class
+ <antrik> (of course you also need to add it to some port bucket. if you use
+ a single dispatcher for everything, this would be the default bucket; if
+ you want a separate thread for pager handling, you'd have to create an
+ extra bucket for the pagers)
+
+This is the `diskfs_get_filemap` function that a `libdiskfs` client has to
+provide; used in `libdiskfs/rdwr-internal.c:_diskfs_rdwr_internal`, which in
+turn is used by the [[interface/io_read]]/[[interface/io_write]] RPCs.
diff --git a/hurd/libstore/examples/ramdisk/discussion.mdwn b/hurd/libstore/examples/ramdisk/discussion.mdwn
new file mode 100644
index 00000000..d73bf903
--- /dev/null
+++ b/hurd/libstore/examples/ramdisk/discussion.mdwn
@@ -0,0 +1,72 @@
+[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+
+# IRC, freenode, #hurd, 2011-10-15
+
+ <antrik> youpi: I'm not at all talking about ordinary tmpfs. I'm talking
+ about the proposed variant using a separate backing store
+ <antrik> youpi: and as you might remember, I once came up with a crazy
+ passive translator command line (based on another crazy passive
+ translator command line from tschwinge) that can automatically do the
+ mkfs
+ <antrik> so there is really very little benefit in using something else
+ than ext2fs when not paging to the swap partition
+ <antrik> real tmpfs IMHO is mostly useful precisely because it uses the
+ ordinary swap, and doesn't have an explicit size limit...
+ <youpi> well, it is still quite a waste to bounce data betwen page cache
+ and memory storage
+ <youpi> or is ext2fs able to map the store data directly?
+ <youpi> then there's only the medata bounce which is spurious
+ <youpi> and still, even a one-liner settrans doesn't fit with the "is just
+ an fs alternative for the existing tmpfs-mounting scripts"
+ <antrik> youpi: well, if the invocation is the major concern, it would be
+ trivial to write a tiny wrapper binary or script that acts like a
+ "normal" FS...
+ <youpi> antrik: could you write it then?
+ <antrik> you mean a shell script that uses ext2fs on a memory store to act
+ like a "proper" tmpfs?
+ <youpi> I mean whatever that permits to just run mount none /tmp -t tmpfs
+ <youpi> and just works already nowadays
+ <youpi> which we could e.g. ship instead of our currently-completely bugged
+ tmpfs
+ <antrik> I suspect the mount script just looks for /hurd/tmpfs in this
+ case? if so, that should indeed be pretty trivial. let's see if I can dig
+ up my crazy command line -- turning that into a "proper" script should be
+ quite easy I hope...
+ <antrik> hm... I digged up
+ http://lists.gnu.org/archive/html/bug-hurd/2007-04/msg00013.html ; but I
+ wonder how much of it is really necessary for a generic pseudo-tmpfs...
+ <antrik> the major complication seems to be the chmod, which I guess we
+ don't need for most use cases...
+ <youpi> I actually don't see why it's inlined there
+ <youpi> doesn't the caller do it if it needs it?
+ <youpi> ah, well, here there is no caller, it's just a passive entry
+ <antrik> is it a problem that this solution needs an extra node for the
+ store?
+ <youpi> yes
+ <youpi> because you need to say where it resides
+ <youpi> and there's no safe place
+ <youpi> since such safe place would typically be a mounted tmpfs
+ <antrik> I feared that much...
+ <antrik> I suspect we could work around this by not attaching the store to
+ any node; but this a) doesn't work in a shell script, and b) is much more
+ involved...
+ <antrik> hm... can we assume /dev/fd to be present? I have a vague crazy
+ idea...
+ <youpi> yes
+ <antrik> I consider hacking settrans so it grows an option which allows
+ passing the port to the translator as an FD, instead of attaching it to
+ any node... this way, we could work with anonymous translators in shell
+ scripts :-)
+ <antrik> (of course that's not less work than just doing the wrapper in
+ C... but it could be useful in other cases)
diff --git a/hurd/running/virtualbox.mdwn b/hurd/running/virtualbox.mdwn
index d9be09f2..f57fcbc3 100644
--- a/hurd/running/virtualbox.mdwn
+++ b/hurd/running/virtualbox.mdwn
@@ -39,3 +39,8 @@ To convert the image you need the VirtualBox package properly installed with a V
If [[QEMU with KVM|qemu]] is not available, VirtualBox reportedly has better
performance.
+
+IRC, freenode, #hurd, 2011-10-31:
+
+ <youpi> I don't know what virtualbox does with hardware emulation, but
+ gnumach is awfully slow to probe things there
diff --git a/hurd/translator/tmpfs/notes_various.mdwn b/hurd/translator/tmpfs/notes_various.mdwn
index d16210ca..d1c5cf62 100644
--- a/hurd/translator/tmpfs/notes_various.mdwn
+++ b/hurd/translator/tmpfs/notes_various.mdwn
@@ -212,3 +212,11 @@ License|/fdl]]."]]"""]]
<antrik> seems something more broke in the meantime :-(
<antrik> ah, right... but I the main problem was some other change
<antrik> (or maybe it never really worked, not sure anymore)
+
+---
+
+IRC, freenode, #hurd, 2011-10-11:
+
+ <mcsim> There is no patch for "tmpfs crashes on filling an empty file". For
+ second bug there is Zheng Da's patch, but it wasn't applied (at least I
+ didn't found).