[[!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 thinking how to get the listing. traversing would be ineffecient, trying to come up with something better what listing ? and traversing what ? mtab well i assumed so be more precise please when the translator is done initalized are written to /etc/mtab 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 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 | 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 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 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 braunr, whats ur opinion? you don't need a mtab to "unmount" things on hurd kuldeepdhaka: hum, have you read the project idea ? http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/mtab/ 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. pinotree, not to unmount, i mean is to remove the for a first implementation, i'd suggest a recursive traversal of root-owned translators braunr, hum, but it did stated it as inefficient where ? para 5 , line 3 and line 6 no traversing "all" nodes would be inefficient translators which host the nodes of other translators could maintain a simple list of active translators ext2fs, e.g. (if that's not already the case) could keep the list of the translators it started we can already see that list with pstree for example but this new list would only retain those relevant for mtab i.e. root-owned ones i would not limit to those though and then filter on their type (e.g. file system ones) pinotree: why ? this way you could have proper per-user /proc/$pid/mounts info we could also very easily have a denial of service but how will the mount point and source point will be listed? they're returned by the translator k you ask /, it returns its store and its options, and asks its children recursively a /home translator would return its store and its options etc.. each translator would build the complete path before returning it sort of, it's very basic but that would be a very hurdish way to do it 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? kuldeepdhaka: it should have all the properties of a regular file the filesize would be determined after it's generated being empty doesn't imply it's not seekable content is generated on demand so, could cause problem while seeking and filesize, shall i still program as regular file? in two different read, it could generate different content, though same seek pos is used... what ? the content is generated on open ooh, ok # IRC, freenode, #hurd, 2013-06-04 how to see list of all connected translators? you can't directly you can use ps to list processes and guess which are translators (e.g. everything starting with /hurd/) a recursive call to obtain such a list would be useful similar to what's needed to implement /proc/mounts # IRC, freenode, #hurd, 2013-06-25 In context of [[open_issues/mig_portable_rpc_declarations]]. should I go for an iterator like interface instead? btw, what's the expected roundtrip time? don't think that way consider the round trip delay as varying y, is it that bad? no but the less there is the better we think the same with system calls even if they're faster the delay itself isn't the real issue look at how proc provides information (in procfs for example) ## IRC, freenode, #hurd, 2013-06-26 so tell me about the more hurdish way of dealing with that issue creating a specialized translator for this? 11:45 < pinotree> there's also http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/mtab/ about that topic you need to avoid thinking with centralization in mind the hurd is a distributed system in practice i think proc is the only centralized component in there braunr: would having an mtab translator and having fs translators register to thae be acceptable? that* teythoon: why do you want to centralize it ? translators already register themselves when they get attached to a node we don't want an additional registration have you read the link we gave you ? I did and I got the message, but isn't the concept of /proc/mounts or a mtab file already a centralized one? that doesn't mean the implementation has to be and no, i don't think it's centralized actually it's just a file you can build a file from many sources 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 i don't understand restricting to the root user doesn't mean it's centralized trust has nothing to do with being centralized I guess I'm not used to thinking this way teythoon: i guess that's the main reason why so few developers work on the hurd also the way fs notification is done is also centralized, that could also be done recursively what doyou call fs notification ? and the information I need could just be stuffed into the same mechanism fs translators being notified of system shutdown right that gets a bit complicated because the kernel is also a centralized component it knows every memory object and their pagers it manages all virtual memory there are two different issues here syncing memory and shutting down file systems the latter could be done recursively, yes i wonder if the former could be delegated to external pagers as well teythoon: but that's not the focus of your work aiui, it would take much time 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 i understand and hacking up a quick solution for that seemed like a good exercise i suggest you discuss it with your mentors they might agree to a temporary centralized solution although i don't think it's much simpler than the recursive one braunr: would that be implemented in libdiskfs and friends? teythoon: i'm not sure, it might be a generic fs operation libnetfs etc.. are also mount points so where would it go if it was generic? libfshelp perhaps translator startup is handled in start-translator-long.c, so in case a startup is successful, I'd add it to a list? i'd say so, yes would that cover all cases, passive and active translators? that's another question do we consider passive translators as mounted ? ah, that was not what i meant i know but it's related start b/c of accessing a passive one vs. starting an active one using settrans start_translator_xxx only spawn active translators it's the same ok the definition of a passive translator is that it starts the active translator on access yeah I can see how that wouldn't be hard to implement i think we want to include passive translators in the mount table so registration must happen before starting the active one 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? keeping a list of all translators attached and yes well a is easy b is the real work c would be procfs using b oh? I thought recursing on the translators and querying info would be separate operations? why so ? the point is querying recursively :) and when i say recursively, it's only a logical view ok, yes, it can be implemented this way, so we construct the list while recursing on the translators i think it would be better to implement it the way looking up a node is done in a loop, using a stack? iteratively a translator would provide information about itself (if supported), and referrences to translators locally registered to it could you point me to the node lookup? ah, yes eg., you ask /, it tells you it's on /dev/hd0, read-write, with options, and send rights to /home, /proc, etc.. well rights, references it could be the path itself rights as in a port to the translators? i think the path would be better but i'm not sure it would also allow you to check the permissions of the node before querying path would be nicer in the presence of stacked translators and obviously you'd have the path right away, no need to provide it in the reply true 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 teythoon: doesn't mean you can't add something there that other libraries will use so yes, not sufficient ## IRC, freenode, #hurd, 2013-06-29 braunr: diskfs_S_fsys_set_options uses diskfs_node_iterate to recurse on active translators if do_children is given braunr: I wonder how fast that is in practice braunr: if it's fast enough, there might not even be a need for a new function in fsys.defs and no need to keep a list of translators for that reason braunr: if it's not fast enough, then diskfs_S_fsys_set_options could use the list to speed this up teythoon: on all nodes ? braunr: i believe so, yes, see libdiskfs/fsys-options.c teythoon: well, if it really is all node, you clearly don't want that ## IRC, freenode, #hurd, 2013-07-01 I've ment to ask, the shiny new fsys_get_translators interface, should it return the options for the queried translator or not? i don't think it should ok let's walk through why it shouldn't may I assume that the last argument returned by fsys_get_options is the "source"? how would you know these options ? the source ? I wouldn't actually yes, you wouldn't you'd have to ask the translators for that so the only thing you can do is point to them well, the device to include in the mtab file and the client asks i don't know fsys_get_options tbh well, both tmpfs and ext2fs print an appropriate value for "device" as last argument looks like a bad interface to me options should be options there should be a specific call for the device but if everyone agrees with the options order, you can do it that way for now i guess one that could be used to recreate the "mount" using either mount or settrans just comment it where appropriate I thought that'd be the point? ? % fsysopts tmp /hurd/tmpfs --writable --no-inherit-dir-group --no-sync 48K where is the device ? % settrans -ca tmp $(fsysopts tmp) 15:56 < teythoon> well, both tmpfs and ext2fs print an appropriate value for "device" as last argument 48K i don't see it really ? yes what about ext2fs ? hm ok i see % fsysopts / ext2fs --writable --no-inherit-dir-group --sync=10 --store-type=typed device:hd0s1 i don't think you should consider that as devices but really translator specific options agree I don't ;) b/c the translator calling convention is hardcoded in the mount utility ? I think it's reasonable to assume that this mapping can be reversed theorically you can write a translator that takes no arguments, but just options the 48K string for tmpfs is completely meaningless in fstab, it should be none "tmpfs" the linux equivalent is the size option no, none it's totally ignored and it's recommended to set none rather than the type to avoid confusion u sure? % settrans -cga tmp /hurd/tmpfs --mode=666 6M % settrans -cga tmp /hurd/tmpfs --mode=666 6M % fsysopts tmp /hurd/tmpfs --writable --no-inherit-dir-group --no-sync 6M i've not explained myself clearly it's not ignored by the translator but in fstab, it should be in the options field it's not the source clearly not ah now i'm talking about fstab, but iirc the format is similar in mtab/mounts close, but not the same yes, close 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: what i meant is that, for virtual vile systems (actually file systems with no underlying devices), the device field is normally ignored teythoon: why do you need that for exactly right do they even have a "device" field? (i can see why but i'd like more visibility) pinotree: not yet pinotree: that's what he wants to add but i'd like to see if there is another way to get the information 16:05 < braunr> teythoon: why do you need that for exactly well if I'm constructing a mtab entry I need a value for the device field do we actually need it to be valid ? not necessarily I guess discuss it with your mentors then it has to be valid for e2fsck checks etc. doesn't e2fsck check fstab actually ? i.e. actually for the cases where it's trivial fstab doesn't tell it whether it's mounted I mean fsck checking whether it's mounted not fsck -a oh couldn't we ask the device instead ? looks twisted too that'd mean patching a lot of applications which do similar checks yes teythoon: propose an interface for that with your mentors then yeah, but couldn't you lay it out a little, I mean would it be one procedure or like three? 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? ok why three ? no, I mean when adding stuff to fsys.defs i understood that but why three ? :) it'd be more generic really ? please show a quick example of what you have in mind i honestly don't know, thus I'm asking ;) well first, this device thing bothers me when you look at how we set up our ext2fs translators, you can see they use device:xxx and not /dev/xxx but ok, let's assume it's harmless ok, but isn't the first way actually better? i think it ends up being the same ideally, that's what we want to use as device path but you can recreate a storeio translator using the device:xxx info, the node is useless for that so that we don't need to explicitely set it ? what do you mean ? well, fsysopts / tells currently tells me device:hd0s1 for /, there isn't much choice /dev isn't there yet ah, got it that's why it differs... differs ? from what ? other ext2fs translators are set the same way by the debian installer for example % fsysopts /media/scratch /hurd/ext2fs --writable --no-inherit-dir-group /dev/hd1s1 here it uses the path to the node that's weird was that done by the debian installer ? ah no, that was me :p $ fsysopts /home /hurd/ext2fs --writable --no-inherit-dir-group --store-type=device hd0s6 so as you can see, it's not that simple to infer the device path oho, yet another way ;) right then isn't device:hd0s1 as shortcut for specifying the store type, as done with --store-type=device hd0s1? but perhaps we don't need to yes it is iirc it's something libstore does, per-store prefixes ah that sucks teythoon: you may need to normalize those strings so that they match what's in fstab i.e. unix /dev paths otherwise e2fsck still won't be able to find the translators mounting the device well, if it's mounted actually it just needs to find the matching line in mtab aiui so perhaps a libfshelp function for that, yes braunr: so you suggest adding a normalizing function to libfshelp that creates a /dev/path? yes used by the call you intend to add, which returns that device string as found in fstab found in fstab? so this would only work for translators managed by fstab? no ah a string like the ones found in fstab? yes so that fsck and friends are able to know whether a device is mounted or not i don't see any other purpose for that string in mtab you'd take regular paths as they are, convert device:xxx to /dev/xxx, and return "none" for the rest i suppose ok i'm not even sure it's right youpi: are you sure it's required ? well it's a start and I think it's not too much work aiui, e2fsck may simply find the mount point in fstab, and ask the translator if it's mounted we can refine this later on maybe? or rather, init scripts, using mountpoint, before starting e2fsck teythoon: sure there's this mountpoint issue... I need to run fsysopts / --update early in the boot process otherwise the device ids returned by stat(2)ing / are wrong and mountpoint misbehaves i guess b/c it's the rootfs device ids ? % stat / | grep Device Device: 3h/3d Inode: 2 Links: 22 do you mean the major/minor identifiers ? I do. if I don't do the --update i get seemingly random values i guess that's expected we don't have major/minor values well, they're emulated well, if that's fixable, that'd be really nice ;) we'll never have major/minor values yeah, I understand that but they could be fixed by MAKEDEV when creating device nodes but not having to call fsys_set_options on the rootfs to get the emulation up to speed try doing it from grub not sure it's possible but worth checking by means of an ext2fs flag? yes if there is one i don't know the --update flag, is it new from your work ? braunr: no, it's been there before. -oremount gets mapped to that it's documented by fsysopts, but not by the ext2fs translators libdiskfs source says something about flushing buffers iirc -s what does it do ? teythoon: ok 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? not set, return yeah return from the procedure but settable using libfshelp? why settable ? 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 ah, make a function overrideable that returns an appropriate response? overrideable ? like netfs_append_args you wouldn't change the command line, no isn't that done using weak references or something? no I know sorry i'm lost then never mind, I'll propose a patch early to get your feedback braunr: am I sure that _what_ is required? the device? e2fsck surely needs it, yes a valid device path, yes it can't rely only on fstab yes since users may mount things by hand i've used strace on it and it does perform lookups there (although i also saw uuid magic that i guess wouldn't work yet on the hurd) ## IRC, freenode, #hurd, 2013-07-03 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 % ./mtab tmp ./mtab: get_translator_info: (ipc/mig) bad request message ID I guess it's libhurduser.so from glibc, not sure though... glibc would only have the client calls what is "% ./mtab tmp" ? mtab is my mtab tool/soon to be a translator testing thing, tmp is an active tmpfs with the appropriate server stub so mtab has the client call, right ? yes then tmpfs doesn't so what to do about it? i set LD_LIBRARY_PATH to my hurd builds lib dir, is that preserved by settrans -a?