diff options
Diffstat (limited to 'community/gsoc/project_ideas')
| -rw-r--r-- | community/gsoc/project_ideas/mtab.mdwn | 98 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/mtab/discussion.mdwn | 907 |
2 files changed, 909 insertions, 96 deletions
diff --git a/community/gsoc/project_ideas/mtab.mdwn b/community/gsoc/project_ideas/mtab.mdwn index d6f04385..0c0bb87b 100644 --- a/community/gsoc/project_ideas/mtab.mdwn +++ b/community/gsoc/project_ideas/mtab.mdwn @@ -11,6 +11,8 @@ License|/fdl]]."]]"""]] [[!meta title="mtab"]] +[[!tag open_issue_hurd]] + In traditional monolithic system, the kernel keeps track of all mounts; the information is available through `/proc/mounts` (on Linux at least), and in a very similar form in `/etc/mtab`. @@ -73,99 +75,3 @@ Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar) Exercise: Make some improvement to any of the existing Hurd translators. Especially those in [hurdextras](http://www.nongnu.org/hurdextras/) are often quite rudimentary, and it shouldn't be hard to find something to improve. - - -# Related Discussion - -## 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 diff --git a/community/gsoc/project_ideas/mtab/discussion.mdwn b/community/gsoc/project_ideas/mtab/discussion.mdwn new file mode 100644 index 00000000..0e322c11 --- /dev/null +++ b/community/gsoc/project_ideas/mtab/discussion.mdwn @@ -0,0 +1,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 |