summaryrefslogtreecommitdiff
path: root/hurd/translator/discussion.mdwn
blob: 70a6efee76a7b3e691607c81ab98d9682d2ad0d5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
[[!meta copyright="Copyright © 2011, 2013, 2014 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_documentation open_issue_hurd]]

[[!toc]]


# IRC, freenode, #hurd, 2011-08-25

    < frhodes> how can I replace an existing running server with a new one
      without rebooting?
    < antrik> frhodes: depends. if other critical things depend on it, you
      can't. there is no mechanism to serialize and pass on the open sessions
    < antrik> in some situations, you can orphan the old translator while
      starting a new one, so the previous clients will stay with the old one
      while new one will get the new one
    < antrik> obviously that only works for things that aren't exclusive by
      nature
    < antrik> in some cases, you might even be able simply to remove the old
      translator... but obviously only for non-critical stuff :-)


# IRC, freenode, #hurd, 2013-10-21

    <braunr> mhmm, there is a problem with thread destruction

[[open_issues/libpthread/t/fix_have_kernel_resources]].

    <braunr> actually, translator self destruction
    <braunr> if a request arrives after the last thread servicing a port set
      returns from mach_msg because of a timeout, but before the translator is
      detached from its parent, the client will get an error
    <braunr> it should very rarely happen, but if it does, we could face the
      same kind of issues we have when a server crashes
    <braunr> e.g. sshd looping over select() returning EBADF, consuming all cpu
    <braunr> not sure we want to introduce such new issues

    <braunr> i don't think i'll be able to make translators disappear reliably
      ..
    <braunr> but at least, thread consumption will correctly decrease with
      inactivity


# IRC, freenode, #hurd, 2014-01-30

    <sjbalaji> can any one exmplain me hello translator ? I am new to hurd
    <teythoon> sjbalaji: sure, what do you want to know ?
    <teythoon> how to use it ?
    <sjbalaji> No I mean what is the main reason of that translator. I am
      familiar with Linux.
    <gnu_srs> sjbalaji: start with:
      https://www.gnu.org/software/hurd/hurd/documentation/translator_primer.html
    <sjbalaji> I ran that example but I am still clueless about the actual
      reason behind the translators and this simple hello world translator
      example. 
    <teythoon> sjbalaji: the Hurd is a multiserver os, almost all functionality
      lives in userspace servers called 'translators'
    <teythoon> sjbalaji: the Hurd uses the file system as namespace to lookup
      these servers
    <teythoon> e.g. /servers/socket/1 is /hurd/pflocal and handles pipes and
      unix socket communication
    <sjbalaji> I can see from the example that a hello file is associated with
      a /hurd/hello translator 
    <teythoon> yes
    <teythoon> think of translators like FUSE-based filesystems, only more
      general
    <teythoon> b/c translators are not restricted to provide filesystem-like
      services
    <sjbalaji> So this example hello translator just adds hello world in the
      associated file, am I correct ?
    <teythoon> it's not adding stuff to a file
    <teythoon> say you did settrans -ac /tmp/hi /hurd/hello, if you do cat
      /tmp/hi, cat does some rpc calls to the started /hurd/hello program that
      returns 'hello world' as the file contents
    <teythoon> in a sense /hurd/hello is a 'filesystem' that provides a single
      file
    <sjbalaji> So is it like hello is the mount moint for that hello server ? 
    <teythoon> sjbalaji: yes, kind of that, but in a more general sense
    <sjbalaji> teythoon: How can I see the different servers that are running
      in the system ? I tried top in the terminal but it returned cannot find
      /proc/version
    <teythoon> sjbalaji: so it seems your procfs is not running, try as root:
      settrans /proc /hurd/procfs -c
    <sjbalaji> teythoon: But how does one differentiate between a server and a
      normal process ?
    <teythoon> one does not
    <teythoon> for a rule of thumb: anything from /hurd is a translator
    <teythoon> you can view a nodes passive translator record using showtrans,
      e.g. showtrans /dev/hd0
    <sjbalaji> Is there something like a man page for translators ? Like how to
      work with them or to figure out what services are offered by them ?
    <teythoon> well, there is --help
    <teythoon> also, go to /dev and /servers and look around using showtrans or
      fsysopts
    <sjbalaji> teythoon: What is the difference between a nodes active and
      passive translator ?
    <teythoon> a passive translator record is stored in the file system for the
      node
    <teythoon> if the node is accessed, and no translator is currently running,
      it is started on demand
    <teythoon> we call a running translator an active one
    <sjbalaji> So the hello translator in the example is a passive one ?
    <teythoon> if you used settrans foo /hurd/hello, a node foo is created with
      an passive translator record
    <teythoon> if you used settrans -a foo /hurd/hello, the translator is
      started immediately
    <sjbalaji> teythoon: What do you mean by a passive translator record ?
    <teythoon> sjbalaji: it's an argv-vector encoded in the filesystem
      (currently, only ext2 supports this)
    <teythoon> in ext2, it is stored in a block and a os-specific field in the
      inode points to that block
    <sjbalaji> teythoon: I can't understand the logic behind that :(
    <teythoon> this way, the servers are started on demand
    <sjbalaji> But once they are invoked they are always online after that. 
    <teythoon> yes
    <sjbalaji> I thought that the server goes down once its used 
    <gnu_srs> teythoon: shouldn't the passive ones time out if unused?
    <teythoon> yes, that's how it was intented to be, but that has been
      patched-out in debian/hurd
    <gnu_srs> reason?
    <teythoon> i don't know the details, but there is a race condition

(`libports_stability.patch`.)


# IRC, freenode, #hurd, 2014-01-31

    <sjbalaji> How can I see the complete control flow when I run the hello
      translator example ?


# IRC, freenode, #archhurd, 2014-02-05

    <CalimeroTeknik> plus I discussed quickly that idea with Richard Stallman
      and he told me translators had a conception flaw that would forbid such a
      system to be usable


## IRC, freenode, #archhurd, 2014-02-06

    <antrik_> CalimeroTeknik: the "conceptal problem" rms told you about was
      probably the simple issue that translators are always followed, even if
      they are run by another user
    <antrik> CalimeroTeknik: the conceptal problem is only in that the original
      designers believed that would be safe, which it isn't. changing that
      default policy (to be more like FUSE) wouldn't do much harm to the Hurd's
      features, and it should be easy to do
    <antrik> it's just nobody bothered so far, because it's not a big deal for
      typical use cases
    <antrik> rms isn't really in touch with Hurd development. he was made to
      believe it was a fundamental issue by a former Hurd developer who got
      carried away; and he didn't know enough to realise that it's really not a
      big deal at all


# Candidates for Google Summer of Code [[community/gsoc/Project_Ideas]]

## Extend `ls` et al. for Translators

### IRC, freenode, #hurd, 2014-02-08

    <youpi> heh
    <youpi> I was wondering what that incoming/ directory was in my home
    <youpi> ls gave me hundreds of packages
    <youpi> then I remembered I had /hurd/httpfs http://incoming.debian.org/ on
      it :)
    <cluck> if only there were an easy and automated way to make ls and file
      managers (like dired!) aware of links, mounts and translators :)
    <youpi> cluck: what do you mean by "awaree"?
    <cluck> someting like: lrwxrwxrwx  1 foo foo          31 Aug 21 18:01
      my_translator-23.0 -> ../some/fakefs /some_parameters*
    <cluck> (yes, i realize it goes against some security practices but maybe
      there could be a distinction like with soft/hard links that made it
      opaque for some use cases)


## Passive Translators

### IRC, freenode, #hurd, 2014-02-12

    <braunr> well don't expect rsync to save passive translator records ..
    <braunr> i recommend you save either the entire disk image or the partition
    <gg0> should i expect it from tar/cp ?
    <braunr> no
    <braunr> i'm not even sure dumpe2fs does it
    <braunr> the only reliable way is to save the block device
    <azeem> might be a worthwhile GSOC
    <azeem> "implement Hurd specific features in GNU utilities"
    <azeem> there were some patches floating around for some things in the past
      IIRC
    <antrik> azeem: the plan for supporting Hurd features in FS utilities was
      exposing them as xattrs, like Roland's Linux patch did... cascardos once
      did some work on this, but don't remember how far he got

[[community/gsoc/project_ideas/xattr]].

    <antrik> you are right though that it would make for a good GSoC project...
    <antrik> of course, *some* utilities would still benefit from explicit Hurd
      support -- most notably ls
    <azeem> IIRC there were also ls patches at one point
    <antrik> can't recall that... but maybe it was befor my time ;-)