From be49aa7ddec52e121d562e14d4d93fd301b05fbb Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 4 Nov 2011 19:19:35 +0100 Subject: IRC. --- hurd/libdiskfs.mdwn | 42 +++++++++++++++ hurd/libstore/examples/ramdisk/discussion.mdwn | 72 ++++++++++++++++++++++++++ hurd/running/virtualbox.mdwn | 5 ++ hurd/translator/tmpfs/notes_various.mdwn | 8 +++ 4 files changed, 127 insertions(+) create mode 100644 hurd/libdiskfs.mdwn create mode 100644 hurd/libstore/examples/ramdisk/discussion.mdwn (limited to 'hurd') 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: + + 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? + mcsim: yes, this in necessary. one pager port corresponds to one + memory object + 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 + so, how can I attach those pager_* functions, which are declared + now in pager-stubs.c to new pager? + or is it done automatically with all pagers, which I create, If + only I'm not using default one? + 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 + (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 + + youpi: I'm not at all talking about ordinary tmpfs. I'm talking + about the proposed variant using a separate backing store + 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 + so there is really very little benefit in using something else + than ext2fs when not paging to the swap partition + real tmpfs IMHO is mostly useful precisely because it uses the + ordinary swap, and doesn't have an explicit size limit... + well, it is still quite a waste to bounce data betwen page cache + and memory storage + or is ext2fs able to map the store data directly? + then there's only the medata bounce which is spurious + and still, even a one-liner settrans doesn't fit with the "is just + an fs alternative for the existing tmpfs-mounting scripts" + 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... + antrik: could you write it then? + you mean a shell script that uses ext2fs on a memory store to act + like a "proper" tmpfs? + I mean whatever that permits to just run mount none /tmp -t tmpfs + and just works already nowadays + which we could e.g. ship instead of our currently-completely bugged + tmpfs + 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... + 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... + the major complication seems to be the chmod, which I guess we + don't need for most use cases... + I actually don't see why it's inlined there + doesn't the caller do it if it needs it? + ah, well, here there is no caller, it's just a passive entry + is it a problem that this solution needs an extra node for the + store? + yes + because you need to say where it resides + and there's no safe place + since such safe place would typically be a mounted tmpfs + I feared that much... + 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... + hm... can we assume /dev/fd to be present? I have a vague crazy + idea... + yes + 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 :-) + (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: + + 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]]."]]"""]] seems something more broke in the meantime :-( ah, right... but I the main problem was some other change (or maybe it never really worked, not sure anymore) + +--- + +IRC, freenode, #hurd, 2011-10-11: + + 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). -- cgit v1.2.3