summaryrefslogtreecommitdiff
path: root/community/gsoc/project_ideas/mtab/discussion.mdwn
blob: 0e322c11f102ae132b69f91de82efb920f3299f4 (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
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
[[!meta copyright="Copyright © 2013 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, 2013-04-17

    <kuldeepdhaka> thinking how to get the listing. traversing would be
      ineffecient,   trying to come up with something better
    <braunr> what listing ?
    <braunr> and traversing what ?
    <kuldeepdhaka> mtab
    <braunr> well i assumed so
    <braunr> be more precise please
    <kuldeepdhaka> when the translator is done initalized      <translation
      info> are written to /etc/mtab      <translation info> will be provided
      by the translator, and when some one want to read the info just read it
      this way if their is some credentials like ftp sites pass username can be
      masked by the translator
    <kuldeepdhaka> if some trans dont want to list them, no need to write to
      file    | while unmounting (sorry i couldnt find the right word) , it
      will pass the mount node address | <translation info> will have special
      structure to remove/add mounts example "a /mount-to /mount-from" = add
      , "r /mount-to" = remove    here "/mount-to" will be unique for every
      mount
    <kuldeepdhaka> this have a draw back , we would have to trust trans for the
      listed data  | also "/mount-to" + "/mount-from" could be used a
      combination for making sure that other trans unable remove others trans
      mount data
    <kuldeepdhaka> sorry but "also "/mount-to" + "/mount-from" could be used a
      combination for making sure that other trans unable remove others trans
      mount data"  this is a bad idea if we had to print the whole thing
    <kuldeepdhaka> braunr, whats ur opinion?
    <pinotree> you don't need a mtab to "unmount" things on hurd
    <braunr> kuldeepdhaka: hum, have you read the project idea ?
    <braunr>
      http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/mtab/
    <braunr> A more promising approach is to have mtab exported by a special
      translator, which gathers the necessary information on demand. This could
      work by traversing the tree of translators, asking each one for mount
      points attached to it.
    <kuldeepdhaka> pinotree, not to unmount, i mean is to remove the
      <translation data>
    <braunr> for a first implementation, i'd suggest a recursive traversal of
      root-owned translators
    <kuldeepdhaka> braunr, hum, but it did stated it as inefficient
    <braunr> where ?
    <kuldeepdhaka> para 5 , line 3
    <kuldeepdhaka> and line 6
    <braunr> no
    <braunr> traversing "all" nodes would be inefficient
    <braunr> translators which host the nodes of other translators could
      maintain a simple list of active translators
    <braunr> ext2fs, e.g. (if that's not already the case) could keep the list
      of the translators it started
    <braunr> we can already see that list with pstree for example
    <braunr> but this new list would only retain those relevant for mtab
    <braunr> i.e. root-owned ones
    <pinotree> i would not limit to those though
    <braunr> and then filter on their type (e.g. file system ones)
    <braunr> pinotree: why ?
    <pinotree> this way you could have proper per-user /proc/$pid/mounts info
    <braunr> we could also very easily have a denial of service
    <kuldeepdhaka> but how will the mount point and source point will be
      listed?
    <braunr> they're returned by the translator
    <kuldeepdhaka> k
    <braunr> you ask /, it returns its store and its options, and asks its
      children recursively 
    <braunr> a /home translator would return its store and its options
    <braunr> etc..
    <braunr> each translator would build the complete path before returning it
    <braunr> sort of, it's very basic
    <braunr> but that would be a very hurdish way to do it
    <kuldeepdhaka> shall /etc/mtab should be made seek-able and what should be
      the filesize?  content are generated on demand so, it could arise problem
      (fsize:0 , seek-able:no), ur opinions?
    <braunr> kuldeepdhaka: it should have all the properties of a regular file
    <braunr> the filesize would be determined after it's generated
    <braunr> being empty doesn't imply it's not seekable
    <kuldeepdhaka> content is generated on demand so, could cause problem while
      seeking and filesize, shall i still program as regular file?
    <kuldeepdhaka> in two different read, it could generate different content,
      though same seek pos is used...
    <braunr> what ?
    <braunr> the content is generated on open
    <kuldeepdhaka> ooh, ok


# IRC, freenode, #hurd, 2013-06-04

    <safinaskar> how to see list of all connected translators?
    <braunr> you can't directly
    <braunr> you can use ps to list processes and guess which are translators
    <braunr> (e.g. everything starting with /hurd/)
    <braunr> a recursive call to obtain such a list would be useful
    <braunr> similar to what's needed to implement /proc/mounts


# IRC, freenode, #hurd, 2013-06-25

In context of [[microkernel/mach/mig/documentation/structured_data]].

    <teythoon> should I go for an iterator like interface instead?
    <teythoon> btw, what's the expected roundtrip time?
    <braunr> don't think that way
    <braunr> consider the round trip delay as varying
    <teythoon> y, is it that bad?
    <braunr> no
    <braunr> but the less there is the better
    <braunr> we think the same with system calls even if they're faster
    <braunr> the delay itself isn't the real issue
    <braunr> look at how proc provides information
    <braunr> (in procfs for example)


## IRC, freenode, #hurd, 2013-06-26

    <teythoon> so tell me about the more hurdish way of dealing with that issue
    <teythoon> creating a specialized translator for this?
    <braunr> 11:45 < pinotree> there's also
      http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/mtab/
      about that topic
    <braunr> you need to avoid thinking with centralization in mind
    <braunr> the hurd is a distributed system in practice
    <braunr> i think proc is the only centralized component in there
    <teythoon> braunr: would having an mtab translator and having fs
      translators register to thae be acceptable?
    <teythoon> that*
    <braunr> teythoon: why do you want to centralize it ?
    <braunr> translators already register themselves when they get attached to
      a node
    <braunr> we don't want an additional registration
    <braunr> have you read the link we gave you ?
    <teythoon> I did and I got the message, but isn't the concept of
      /proc/mounts or a mtab file already a centralized one?
    <braunr> that doesn't mean the implementation has to be
    <braunr> and no, i don't think it's centralized actually
    <braunr> it's just a file
    <braunr> you can build a file from many sources
    <teythoon> or if we do it your way recursing on fs translators *but*
      restricting this to root owned translators also suffering from
      centralization wrt to the root user? I mean the concept of all mounted
      filesystems does not apply cleanly to the hurd
    <braunr> i don't understand
    <braunr> restricting to the root user doesn't mean it's centralized
    <braunr> trust has nothing to do with being centralized
    <teythoon> I guess I'm not used to thinking this way
    <braunr> teythoon: i guess that's the main reason why so few developers
      work on the hurd
    <teythoon> also the way fs notification is done is also centralized, that
      could also be done recursively
    <braunr> what doyou call fs notification ?
    <teythoon> and the information I need could just be stuffed into the same
      mechanism
    <teythoon> fs translators being notified of system shutdown
    <braunr> right
    <braunr> that gets a bit complicated because the kernel is also a
      centralized component
    <braunr> it knows every memory object and their pagers
    <braunr> it manages all virtual memory
    <braunr> there are two different issues here
    <braunr> syncing memory and shutting down file systems
    <braunr> the latter could be done recursively, yes
    <braunr> i wonder if the former could be delegated to external pagers as
      well
    <braunr> teythoon: but that's not the focus of your work aiui, it would
      take much time
    <teythoon> sure, but missing an mtab file or better yet /proc/mounts could
      be an issue for me, at least a cosmetic one, if not a functional one
    <braunr> i understand
    <teythoon> and hacking up a quick solution for that seemed like a good
      exercise
    <braunr> i suggest you discuss it with your mentors
    <braunr> they might agree to a temporary centralized solution
    <braunr> although i don't think it's much simpler than the recursive one
    <teythoon> braunr: would that be implemented in libdiskfs and friends?
    <braunr> teythoon: i'm not sure, it might be a generic fs operation
    <braunr> libnetfs etc.. are also mount points
    <teythoon> so where would it go if it was generic?
    <braunr> libfshelp perhaps
    <teythoon> translator startup is handled in start-translator-long.c, so in
      case a startup is successful, I'd add it to a list?
    <braunr> i'd say so, yes
    <teythoon> would that cover all cases, passive and active translators?
    <braunr> that's another question
    <braunr> do we consider passive translators as mounted ?
    <teythoon> ah, that was not what i meant
    <braunr> i know
    <braunr> but it's related
    <teythoon> start b/c of accessing a passive one vs. starting an active one
      using settrans
    <braunr> start_translator_xxx only spawn active translators
    <braunr> it's the same
    <teythoon> ok
    <braunr> the definition of a passive translator is that it starts the
      active translator on access
    <teythoon> yeah I can see how that wouldn't be hard to implement
    <braunr> i think we want to include passive translators in the mount table
    <braunr> so registration must happen before starting the active one
    <teythoon> so it's a) keeping a list of active translators and b) add an
      interface to query fs translators for this list and c) an interface to
      query mtab style information?
    <braunr> keeping a list of all translators attached
    <braunr> and yes
    <braunr> well
    <braunr> a is easy
    <braunr> b is the real work
    <braunr> c would be procfs using b
    <teythoon> oh? I thought recursing on the translators and querying info
      would be separate operations?
    <braunr> why so ?
    <braunr> the point is querying recursively :)
    <braunr> and when i say recursively, it's only a logical view
    <teythoon> ok, yes, it can be implemented this way, so we construct the
      list while recursing on the translators
    <braunr> i think it would be better to implement it the way looking up a
      node is done
    <teythoon> in a loop, using a stack?
    <braunr> iteratively
    <braunr> a translator would provide information about itself (if
      supported), and referrences to translators locally registered to it
    <teythoon> could you point me to the node lookup?
    <teythoon> ah, yes
    <braunr> eg., you ask /, it tells you it's on /dev/hd0, read-write, with
      options, and send rights to /home, /proc, etc..
    <braunr> well rights, references
    <braunr> it could be the path itself
    <teythoon> rights as in a port to the translators?
    <braunr> i think the path would be better but i'm not sure
    <braunr> it would also allow you to check the permissions of the node
      before querying
    <teythoon> path would be nicer in the presence of stacked translators
    <braunr> and obviously you'd have the path right away, no need to provide
      it in the reply
    <teythoon> true

    <teythoon> braunr: if we want to list passive translators (and I agree, we
      should), it isn't sufficient to touch libfshelp, as setting a passive
      translator is not handled there, only the startup
    <braunr> teythoon: doesn't mean you can't add something there that other
      libraries will use
    <braunr> so yes, not sufficient


## IRC, freenode, #hurd, 2013-06-29

    <teythoon> braunr: diskfs_S_fsys_set_options uses diskfs_node_iterate to
      recurse on active translators if do_children is given
    <teythoon> braunr: I wonder how fast that is in practice
    <teythoon> braunr: if it's fast enough, there might not even be a need for
      a new function in fsys.defs
    <teythoon> and no need to keep a list of translators for that reason
    <teythoon> braunr: if it's not fast enough, then diskfs_S_fsys_set_options
      could use the list to speed this up
    <braunr> teythoon: on all nodes ?
    <teythoon> braunr: i believe so, yes, see libdiskfs/fsys-options.c
    <braunr> teythoon: well, if it really is all node, you clearly don't want
      that


## IRC, freenode, #hurd, 2013-07-01

    <teythoon> I've ment to ask, the shiny new fsys_get_translators interface,
      should it return the options for the queried translator or not?
    <braunr> i don't think it should
    <teythoon> ok
    <braunr> let's walk through why it shouldn't
    <teythoon> may I assume that the last argument returned by fsys_get_options
      is the "source"?
    <braunr> how would you know these options ?
    <braunr> the source ?
    <teythoon> I wouldn't actually
    <braunr> yes, you wouldn't
    <braunr> you'd have to ask the translators for that
    <braunr> so the only thing you can do is point to them
    <teythoon> well, the device to include in the mtab file
    <braunr> and the client asks
    <braunr> i don't know fsys_get_options tbh
    <teythoon> well, both tmpfs and ext2fs print an appropriate value for
      "device" as last argument
    <braunr> looks like a bad interface to me
    <braunr> options should be options
    <braunr> there should be a specific call for the device
    <braunr> but if everyone agrees with the options order, you can do it that
      way for now i guess
    <teythoon> one that could be used to recreate the "mount" using either
      mount or settrans
    <braunr> just comment it where appropriate
    <teythoon> I thought that'd be the point?
    <braunr> ?
    <teythoon> % fsysopts tmp
    <teythoon> /hurd/tmpfs --writable --no-inherit-dir-group --no-sync 48K
    <braunr> where is the device ?
    <teythoon> % settrans -ca tmp $(fsysopts tmp)
    <braunr> 15:56 < teythoon> well, both tmpfs and ext2fs print an appropriate
      value for "device" as last argument
    <teythoon> 48K
    <braunr> i don't see it
    <braunr> really ?
    <teythoon> yes
    <braunr> what about ext2fs ?
    <braunr> hm ok i see
    <teythoon> % fsysopts /
    <teythoon> ext2fs --writable --no-inherit-dir-group --sync=10
      --store-type=typed device:hd0s1
    <braunr> i don't think you should consider that as devices
    <braunr> but really translator specific options
    <pinotree> agree
    <teythoon> I don't ;)
    <teythoon> b/c the translator calling convention is hardcoded in the mount
      utility
    <braunr> ?
    <teythoon> I think it's reasonable to assume that this mapping can be
      reversed
    <pinotree> theorically you can write a translator that takes no arguments,
      but just options
    <braunr> the 48K string for tmpfs is completely meaningless
    <braunr> in fstab, it should be none
    <pinotree> "tmpfs"
    <braunr> the linux equivalent is the size option
    <braunr> no, none
    <braunr> it's totally ignored
    <braunr> and it's recommended to set none rather than the type to avoid
      confusion
    <teythoon> u sure?
    <teythoon> % settrans -cga tmp /hurd/tmpfs --mode=666 6M          
    <teythoon> % settrans -cga tmp /hurd/tmpfs --mode=666 6M          
    <teythoon> % fsysopts tmp
    <teythoon> /hurd/tmpfs --writable --no-inherit-dir-group --no-sync 6M
    <braunr> i've not explained myself clearly
    <braunr> it's not ignored by the translator
    <braunr> but in fstab, it should be in the options field
    <braunr> it's not the source
    <braunr> clearly not
    <teythoon> ah
    <braunr> now i'm talking about fstab, but iirc the format is similar in
      mtab/mounts
    <pinotree> close, but not the same
    <braunr> yes, close
    <teythoon> ok, so I'll put a method into libfshelp so that translators can
      explicitly set a device and patch all existing translators to do so?
    <braunr> teythoon: what i meant is that, for virtual vile systems (actually
      file systems with no underlying devices), the device field is normally
      ignored
    <braunr> teythoon: why do you need that for exactly
    <teythoon> right
    <pinotree> do they even have a "device" field?
    <braunr> (i can see why but i'd like more visibility)
    <braunr> pinotree: not yet
    <braunr> pinotree: that's what he wants to add
    <braunr> but i'd like to see if there is another way to get the information
    <braunr> 16:05 < braunr> teythoon: why do you need that for exactly
    <teythoon> well if I'm constructing a mtab entry I need a value for the
      device field
    <braunr> do we actually need it to be valid ?
    <teythoon> not necessarily I guess
    <braunr> discuss it with your mentors then
    <youpi> it has to be valid for e2fsck checks etc.
    <braunr> doesn't e2fsck check fstab actually ?
    <youpi> i.e. actually for the cases where it's trivial
    <youpi> fstab doesn't tell it whether it's mounted
    <youpi> I mean fsck checking whether it's mounted
    <youpi> not fsck -a
    <braunr> oh
    <braunr> couldn't we ask the device instead ?
    <braunr> looks twisted too
    <youpi> that'd mean patching a lot of applications which do similar checks
    <braunr> yes
    <braunr> teythoon: propose an interface for that with your mentors then
    <teythoon> yeah, but couldn't you lay it out a little, I mean would it be
      one procedure or like three?
    <braunr> 16:04 < teythoon> ok, so I'll put a method into libfshelp so that
      translators can explicitly set a device and patch all existing
      translators to do so?
    <teythoon> ok
    <braunr> why three ?
    <teythoon> no, I mean when adding stuff to fsys.defs
    <braunr> i understood that
    <braunr> but why three ? :)
    <teythoon> it'd be more generic
    <braunr> really ?
    <braunr> please show a quick example of what you have in mind
    <teythoon> i honestly don't know, thus I'm asking ;)
    <braunr> well first, this device thing bothers me
    <braunr> when you look at how we set up our ext2fs translators, you can see
      they use device:xxx
    <braunr> and not /dev/xxx
    <braunr> but ok, let's assume it's harmless
    <teythoon> ok, but isn't the first way actually better?
    <braunr> i think it ends up being the same
    <braunr> ideally, that's what we want to use as device path
    <teythoon> but you can recreate a storeio translator using the device:xxx
      info, the node is useless for that
    <braunr> so that we don't need to explicitely set it
    <braunr> ?
    <braunr> what do you mean ?
    <teythoon> well, fsysopts / tells currently tells me device:hd0s1
    <braunr> for /, there isn't much choice
    <braunr> /dev isn't there yet
    <teythoon> ah, got it
    <teythoon> that's why it differs...
    <braunr> differs ?
    <braunr> from what ?
    <braunr> other ext2fs translators are set the same way by the debian
      installer for example
    <teythoon> % fsysopts /media/scratch
    <teythoon> /hurd/ext2fs --writable --no-inherit-dir-group /dev/hd1s1
    <teythoon> here it uses the path to the node
    <braunr> that's weird
    <braunr> was that done by the debian installer ?
    <teythoon> ah no, that was me
    <braunr> :p
    <braunr> $ fsysopts /home
    <braunr> /hurd/ext2fs --writable --no-inherit-dir-group --store-type=device
      hd0s6
    <braunr> so as you can see, it's not that simple to infer the device path
    <teythoon> oho, yet another way ;)
    <teythoon> right then
    <pinotree> isn't device:hd0s1 as shortcut for specifying the store type, as
      done with --store-type=device hd0s1?
    <braunr> but perhaps we don't need to
    <braunr> yes it is
    <pinotree> iirc it's something libstore does, per-store prefixes
    <braunr> ah that sucks
    <braunr> teythoon: you may need to normalize those strings
    <braunr> so that they match what's in fstab
    <braunr> i.e. unix /dev paths
    <braunr> otherwise e2fsck still won't be able to find the translators
      mounting the device
    <braunr> well, if it's mounted actually
    <braunr> it just needs to find the matching line in mtab aiui
    <braunr> so perhaps a libfshelp function for that, yes
    <teythoon> braunr: so you suggest adding a normalizing function to
      libfshelp that creates a /dev/path?
    <braunr> yes
    <braunr> used by the call you intend to add, which returns that device
      string as found in fstab
    <teythoon> found in fstab? so this would only work for translators managed
      by fstab?
    <braunr> no
    <teythoon> ah
    <teythoon> a string like the ones found in fstab?
    <braunr> yes
    <braunr> so that fsck and friends are able to know whether a device is
      mounted or not
    <braunr> i don't see any other purpose for that string in mtab
    <braunr> you'd take regular paths as they are, convert device:xxx to
      /dev/xxx, and return "none" for the rest i suppose
    <teythoon> ok
    <braunr> i'm not even sure it's right
    <braunr> youpi: are you sure it's required ?
    <teythoon> well it's a start and I think it's not too much work
    <braunr> aiui, e2fsck may simply find the mount point in fstab, and ask the
      translator if it's mounted
    <teythoon> we can refine this later on maybe?
    <braunr> or rather, init scripts, using mountpoint, before starting e2fsck
    <braunr> teythoon: sure
    <teythoon> there's this mountpoint issue... I need to run fsysopts /
      --update early in the boot process
    <teythoon> otherwise the device ids returned by stat(2)ing / are wrong and
      mountpoint misbehaves
    <teythoon> i guess b/c it's the rootfs
    <braunr> device ids ?
    <teythoon> % stat / | grep Device
    <teythoon> Device: 3h/3d     Inode: 2           Links: 22
    <braunr> do you mean the major/minor identifiers ?
    <teythoon> I do. if I don't do the --update i get seemingly random values
    <braunr> i guess that's expected
    <braunr> we don't have major/minor values
    <braunr> well, they're emulated
    <teythoon> well, if that's fixable, that'd be really nice ;)
    <braunr> we'll never have major/minor values
    <teythoon> yeah, I understand that
    <braunr> but they could be fixed by MAKEDEV when creating device nodes
    <teythoon> but not having to call fsys_set_options on the rootfs to get the
      emulation up to speed
    <braunr> try doing it from grub
    <braunr> not sure it's possible
    <braunr> but worth checking
    <teythoon> by means of an ext2fs flag?
    <braunr> yes
    <braunr> if there is one
    <braunr> i don't know the --update flag, is it new from your work ?
    <teythoon> braunr: no, it's been there before. -oremount gets mapped to
      that
    <braunr> it's documented by fsysopts, but not by the ext2fs translators
    <teythoon> libdiskfs source says something about flushing buffers iirc
    <braunr> -s
    <braunr> what does it do ?
    <braunr> teythoon: ok
    <teythoon> braunr: so the plan is to automatically generate a device path
      from the translators argz vector but to provide the functionality so
      translators can set a more appropriate value? did I get the last part of
      the discussion right?
    <braunr> not set, return
    <teythoon> yeah return from the procedure but settable using libfshelp?
    <braunr> why settable ?
    <braunr> you'd have a fsys call to obtain the dev string, and the server
      side would call libfshelp on the fly to obtain a normalized value and
      return it
    <teythoon> ah, make a function overrideable that returns an appropriate
      response?
    <braunr> overrideable ?
    <teythoon> like netfs_append_args
    <braunr> you wouldn't change the command line, no
    <teythoon> isn't that done using weak references or something?
    <teythoon> no I know
    <braunr> sorry i'm lost then
    <teythoon> never mind, I'll propose a patch early to get your feedback
    <youpi> braunr: am I sure that _what_ is required?
    <youpi> the device?
    <youpi> e2fsck surely needs it, yes
    <braunr> a valid device path, yes
    <youpi> it can't rely only on fstab
    <braunr> yes
    <youpi> since users may mount things by hand
    <braunr> i've used strace on it and it does perform lookups there
    <braunr> (although i also saw uuid magic that i guess wouldn't work yet on
      the hurd)


## IRC, freenode, #hurd, 2013-07-03

    <teythoon> I added a procedure to fsys.defs, added a server stub to my
      tmpfs translator and wrote a simple client, but something hasn't picked
      up the new message yet
    <teythoon> % ./mtab tmp
    <teythoon> ./mtab: get_translator_info: (ipc/mig) bad request message ID
    <teythoon> I guess it's libhurduser.so from glibc, not sure though...
    <braunr> glibc would only have the client calls
    <braunr> what is "% ./mtab tmp" ?
    <teythoon> mtab is my mtab tool/soon to be a translator testing thing, tmp
      is an active tmpfs with the appropriate server stub
    <braunr> so mtab has the client call, right ?
    <teythoon> yes
    <braunr> then tmpfs doesn't
    <teythoon> so what to do about it?
    <teythoon> i set LD_LIBRARY_PATH to my hurd builds lib dir, is that
      preserved by settrans -a?
    <pinotree> not really
    <braunr> not at all
    <braunr> there is a wiki entry about that iirc
    <pinotree> http://darnassus.sceen.net/~hurd-web/hurd/debugging/translator/
    <teythoon> yeah, I read it too once
    <teythoon> ah
    <braunr> on the other hand, using export to set the environment should do
      the work
    <teythoon> yes, that did the trick, thanks :)
    * teythoon got his EOPNOPSUPP... *nomnomnom
    <braunr> ?
    <braunr> same error ?
    <teythoon> well I stubbed it out
    <braunr> oh
    <teythoon> no, that's what I've been expecting ;)
    <pinotree> great
    <braunr> :)
    <braunr> yes that's better than "mig can't find it"
    <teythoon> braunr: in that list of active and passive translators that will
      have to be maintained, do you expect it should carry more information
      other than the relative path to that translator?
    <braunr> like what ?
    <teythoon> dunno, maybe like a port to any active translator there
    <teythoon> should we care if any active translator dies and remove the
      entry if there's no passive translator that could restart it again?
    <braunr> don't add anything until you see it's necessary or really useful
    <braunr> yes
    <braunr> think of something like sshfs
    <braunr> when you kill it, it's not reported by mount any more
    <teythoon> well, for a dynamically allocated list of strings I could use
      the argz stuff, but if we'd ever add anything else, we'd need a linked
      list or something, maybe a hash table
    <teythoon> yes, I thought that'd be useful
    <braunr> use libihash for no
    <braunr> now
    <teythoon> braunr: but what would I use as keys? the relative path should
      be unique (unless translators are stacked... hmmm), but that's the value
      I'd like to store and ihash keys are pointers
    <teythoon> stacked translators are an kinda interesting case for mtab
      anyways...
    <braunr> why not store the string address ?
    <braunr> i suppose that, for stacked translators, the code querying
      information would only return the topmost translator
    <braunr> since this is the one which matters for regular clients (if i'm
      right)
    <teythoon> wouldn't that map strings that are equal but stored at different
      locations to different values?
    <teythoon> that'd defeat the point
    <teythoon> I suppose so, yes
    <braunr> then add a layer that looks for existing strings before adding
    <braunr> the list should normally be small so a linear lookup is fine
    <teythoon> yeah sure, but then there's little advantage of using ihash in
      the first place, isn't it?
    <braunr> over what ?
    <teythoon> over not using it at all
    <braunr> how would you store the list then ?
    <teythoon> it's either ll or ll+ihash
    <braunr> uh no
    <braunr> let me check
    <braunr> there is ihash_iterate
    <braunr> so you don't need a linked list
    <teythoon> so how do I store my list of strings to deduplicate the keys?
    <braunr> you store pointers
    <braunr> and on addition, you iterate over all entries, making sure none
      matches the new one
    <braunr> and if it does, you replace it i guess
    <braunr> depending on how you design the rest
    <teythoon> in an dynamically allocated region of memory?
    <braunr> i don't understand
    <braunr> your strings should be dynmaically allocate, yes
    <teythoon> no the array of char *
    <braunr> your data structure being managed by libihash, you don't care
      about allocation
    <braunr> what array ?
    <teythoon> ah, got it...
    <teythoon> right.
    <braunr> there is only one structure here, an ihash of char *
    <teythoon> yes, I got the picture ;)
    <braunr> goo
    <braunr> d
    <braunr> actually, the lookup wouldn't be linear since usually, hash tables
      have stale entries
    <teythoon> heh... what forest?!?
    <braunr> but that's ok
    <braunr> teythoon: ?
    <teythoon> the one I couldn't make out b/c of all the trees...
    <braunr> ?
    <teythoon> ah, it's not important. there is this saying over here, not sure
      if there's an english equivalent
    <braunr> ok got it
    <braunr> we have the same in french
    <teythoon> I ran into a problem with my prototype
    <teythoon> if an translator is set in e. g. diskfs_S_file_set_translator,
      how do I get the path to that node?
    <teythoon> I believe there cannot be a way to do that, b/c the mapping is
      not bijective
    <braunr> it doesn't have to be
    <teythoon> ok, so how do I get *a* path for this node?
    <braunr> that's another question
    <braunr> do you see how the node is obtained ?
    <braunr> np = cred->po->np;
    <teythoon> yes
    <braunr> the translation occurred earlier
    <braunr> you need to find where
    <braunr> then perhaps, you'll need to carry the path along
    <braunr> or if you're lucky, it will still be there somewhere
    <teythoon> the translation from path to node?
    <braunr> yes
    <teythoon> doesn't that happen in the client? and the client hands a file_t
      to the file_set_translator routine?
    <braunr> the relative lookup can't happen in the client
    <braunr> the server can (and often does) retain information between two
      RPCs
    <teythoon> uh, I can access information from a previous rpc? is that
      considered safe?
    <braunr> think of open() then read()
    <braunr> a simple int doesn't carry enough information
    <braunr> that's why it's a descriptor
    <teythoon> ah, the server retains some state, sure
    <braunr> what it refers to is the state retained between several calls
    <braunr> the object being invoked by clients
    <braunr> teythoon: what is the "passive" parameter passed to
      diskfs_S_file_set_translator ?
    <teythoon> braunr: argz vector of the passive translator
    <braunr> so it is a name
    <braunr> but we also want active translators
    <braunr> and what is active ?
    <teythoon> not the name of the node though
    <teythoon> active is the port (?) to the active translator
    <teythoon> I guess
    <braunr> fsys_t, looks that way yes
    <braunr> i suppose you could add the path to the peropen structure
    <teythoon> ok
    <braunr> see diskfs_make_peropen
    <teythoon> braunr: but translation happens in dir_lookup
    <teythoon> in all places I've seen diskfs_make_peropen used, the path is
      not available
    <teythoon> why did you point me to diskfs_make_peropen?
    <teythoon> s/dir_lookup/diskfs_lookup/
    <teythoon> diskfs_lookup operates on struct node, so the path would have to
      be stored there, right?
    <braunr> teythoon: dir_lookup should call diskfs_make_peropen
    <braunr> at least diskfs_S_dir_lookup does
    <braunr> and the path is present there
    <teythoon> braunr: right

    <teythoon> hrm... I added a path field to struct peropen and initialize it
      properly in diskfs_make_peropen, but some bogus values keep creeping in
      :/
    <braunr> first of all, make it a dynamically allocated string
    <teythoon> it is
    <braunr> not a fixed sized embedded array
    <braunr> good
    <teythoon> yes
    <braunr> if you really need help debugging what's happening, feel free to
      post your current changes somewhere
    <teythoon> there is a struct literal in fsys-getroot.c, but i fixed that as
      well
    <teythoon> % ./mtab tmp 
    <teythoon> none tmp ../tmpfs/tmpfs writable,no-inherit-dir-group,no-sync 0
      0
    <teythoon> none tmp/bar ../tmpfs/tmpfs
      writable,no-inherit-dir-group,no-sync 0 0
    <teythoon> none tmp/foo ../tmpfs/tmpfs
      writable,no-inherit-dir-group,no-sync 0 0
    <teythoon> none tmp/foo/bar ../tmpfs/tmpfs
      writable,no-inherit-dir-group,no-sync 0 0
    <teythoon> :)


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

    <teythoon> btw, I read getcwd.c and got the idea
    <teythoon> however this situation is different afaict
    <teythoon> getcwd has a port to the current working directory, right?
    <teythoon> so they can do open_dir with .. as relative path
    <teythoon> but all I've got is a port referencing the node the translator
      is being attached to
    <teythoon> s/open_dir/dir_lookup/
    <teythoon> and that is not necessarily a directory, so dir_lookup fails
      with not a directory
    <teythoon> as far as I can see it is not possible to get the directory a
      node is in from a port referencing that node
    <teythoon> dir_lookup has to be handled by all nodes, not just directories
    <teythoon> but file nodes only support "looking up" the empty string
    <teythoon> not empty, but null:
    <teythoon> This call is required to be supported by all files (even
      non-directories) if the filename is null, and should function in that
      case as a re-open of the file.  */
    <braunr> why do you want the directory ?
    <braunr> 10:40 < teythoon> as far as I can see it is not possible to get
      the directory a node is in from a port referencing that node
    <teythoon> to readdir(3) it and figure out the name of the node the
      translator is bound to
    <teythoon> similar to what getcwd does
    <braunr> that's out of the question
    <teythoon> wasn't that was youpi was suggesting?
    <braunr> you may have a lot of nodes in there, such a lookup shouldn't be
      done
    <braunr> i didn't see that detail
    <teythoon> "│   Concerning storing the path, it's a bit sad to have to do
      that, and
    <teythoon> │   it'll become wrong if one moves the mount points.  Another
      way would
    <teythoon> │   be to make the client figure it out by itself from a port to
      the mount
    <teythoon> │   point, much like glibc/sysdeps/mach/hurd/getcwd.c. It'll be
      slower, but
    <teythoon> │   should be safer.  The RPC would thus return an array of
      ports to the
    <teythoon> │   mount points instead of an array of strings.
    <braunr> yes i remember that
    <braunr> but i didn't understand well how getcwd work
    <braunr> s
    <braunr> another scalability issue
    <braunr> not a big one though, we rarely have translators in directories
      with thousands of nodes
    <braunr> so why not
    <braunr> teythoon: do it as youpi suggested
    <braunr> well if you can
    <braunr> eh
    <braunr> if not, i don't know
    <braunr> 10:47 < teythoon> │   it'll become wrong if one moves the mount
      points.  Another way would
    <teythoon> yes, I know... :/
    <teythoon> well, I'm not even sure it is possible to get the directory a
      node is in from the port referencing the node
    <teythoon> as in, I'm not sure if the information is even there
    <teythoon> b/c a filesystem is a tree, directories are nodes and files are
      leafs
    <teythoon> all non-leaf nodes reference their parent to allow traversing
      the tree starting from any directory
    <teythoon> but why would a leaf reference its parent(s - in case of
      hardlinks)?
    <braunr> uh, for the same reason ?
    <teythoon> sure, it would be nice to do that, but I dont think this is
      possible on unixy systems
    <braunr> ?
    <teythoon> you cannot say fchdir(2) to a fd that references a file
    <braunr> do you mean /path/to/file/../ ?
    <teythoon> yes
    <teythoon> only that /path/to/file is given as fd or port
    <braunr> when i pasted
    <braunr> 10:49 < braunr> 10:47 < teythoon> │   it'll become wrong if one
      moves the mount points.  Another way would
    <braunr> i was actually wondering if it was true
    <teythoon> ah
    <braunr> why can't the path be updated at the same time ?
    <braunr> it's a relative path anyway
    <braunr> completely managed by the parent translator
    <teythoon> ah
    <teythoon> right
    <teythoon> it's still kind of hacky, but I cannot see how to do this
      properly
    <braunr> hacky ?
    <teythoon> but yes, updating the path should work I guess
    <teythoon> or sad
    <braunr> what i find hacky is to set translators in two passes
    <braunr> otherwise we'd only keep the translator paths
    <braunr> not all paths
    <teythoon> true
    <braunr> but then, it only concerns open nodes
    <braunr> and again, there shouldn't be too many of them
    <braunr> so actually it's ok
    <teythoon> braunr: I understand the struct nodes are cached in libdiskfs,
      so wouldn't it be easier to attach the path to that struct instead of
      struct peropen so that all peropen objects reference the same node
      object?
    <teythoon> so that the path can be updated if anyone dir_renames it
    <teythoon> *all peropen objects derived from the same file name that is
    <braunr> teythoon: i'm not sure
    <braunr> nodes could be real nodes (i.e. inodes)
    <braunr> there can be several paths for the same inode
    <teythoon> braunr: I'm aware of that, but didn't we agree the other day
      that any path would do?
    <braunr> i don't remember we did
    <braunr> i don't know the details well, but i don't think setting a
      translator on a hard link should set the translator at the inode level
    <braunr> on the other hand, if a new inode is created to replace the
      previous one (or stack over it), then storing the path there should be
      fine
    <teythoon> braunr: I don't think I can update the paths if they're stored
      in the peropen struct
    <teythoon> how would I get a reference to all those peropen objects?
    <braunr> ?
    <braunr> first, what's the context when you talkb about updating paths ?
    <teythoon> well, youpi was concerned about renaming a mount point
    <teythoon> and you implied that this could be managed
    <braunr> can we actually do that btw ?
    <teythoon> what?
    <braunr> renaming a mount point
    <teythoon> yep, just tried
    <braunr> i mean, on a regular unix system like linux
    <braunr> $ mv test blah
    <braunr> mv: cannot move `test' to `blah': Device or resource busy
    <braunr> (using sshfs so YMMV)
    <pinotree> do you have anything (shells, open files, etc) inside it?
    <braunr> no
    <braunr> i'll try with an empty loop-mounted ext4
    <teythoon> I was testing on the Hurd, worked fine there even with a shell
      inside
    <braunr> same thing
    <braunr> i consider it a bug
    <braunr> we may want to check what posix says about it
    <teythoon> o_O
    <braunr> and decide not to support renaming
    <teythoon> why?
    <pinotree> start a discussion in ml, maybe roland can chime in
    <braunr> it complicates things
    <braunr> ah yes
    <teythoon> sure, but I can move or rename a directory, why should it be
      different with a mount point?
    <braunr> because it's two of them
    <braunr> they're stacked
    <braunr> if we do want to support that, we must be very careful about
      atomically updating all the stack
    <teythoon> ok
    <teythoon> braunr: I'm trying to detect dying translators to remove them
      from the list of translators
    <teythoon> what port can I use for that purpose?
    <teythoon> if I use the bootstrap port, can I then use the same method as
      init/init.c uses? just defining a do_mach_notify_dead_name function and
      the multiplexer will call this?
    <braunr> teythoon: possibly
    <teythoon> braunr: we'll see shortly...
    <teythoon> I get KERN_INVALID_CAPABILITY indicating that my bootstrap port
      is invalid
    <teythoon> when calling mach_port_request_notification to get the dead name
      notification I mean
    <braunr> is the translator already started when you do that ?
    <teythoon> yes, at least I think so, I'm hooking into
      diskfs_S_file_set_translator and that gets an active translators port
    <teythoon> also the mach docs suggests that the notification port is
      invalid, not the name port referencing the translator
    <braunr> i guess it shouldn't
    <braunr> oh
    <braunr> please show the code
    <braunr> but beware, if the translator is started, assume it could die
      immediately
    <teythoon> braunr: http://paste.debian.net/15371/ line 87
    <braunr> teythoon: notify can't be bootstrap
    <braunr> what do you have in mind when writing this ?
    <braunr> i'm not sure i follow
    <teythoon> I want to be notified if an active translator goes away to
      remove it from the list of translators
    <braunr> ok but then
    <braunr> create a send-once right
    <braunr> and wait on it
    <braunr> also, why do you want to be notified ?
    <braunr> isn't this already done ?
    <braunr> or can't do it lazily on access attempt ?
    <braunr> +you
    <teythoon> in the client?
    <braunr> in the parent server
    <braunr> what happens currently when a translator dies
    <braunr> is the parent notified ?
    <braunr> or does it give an invalid right ?
    <teythoon> ah, i think so
    <braunr> then you don't need to do it again
    <teythoon> right, I overlooked that