[[!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]] [[!toc]] # Argument Parsing ## IRC, freenode, #hurd, 2013-06-27 the arg parsing in libdiskfs and libnetfs differ :/ afaics libdiskfs gets it right, libnetfs does not what do you mean? wrt to *_std_{runtime,startup}_argp see eg netfs.h libdiskfs/opts-std-runtime.c:const struct argp diskfs_std_runtime_argp = libdiskfs/opts-std-runtime.c-{ libdiskfs/opts-std-runtime.c- std_runtime_options, parse_opt, 0, 0, children libdiskfs/opts-std-runtime.c-}; but libnetfs/std-runtime-argp.c:const struct argp netfs_std_runtime_argp = { 0 }; well there are no common startup/runtime options provided by netfs usually netfs-based translators put netfs_std_startup_argp as child as their options, so if netfs starts providing options they would work ah if you have a test showing issues, we can certainly look it :) ok, m/b I was confused... no worries, feel free to ask anytime I thought about providing --update as common runtime flag, like diskfs does, you think it's the right thing to do? what would it do? or should it be left for each translator to implement? nothing by default I guess options provided in libdiskfs are implemented and handled mostly in libdiskfs itself so imho a new option for libnetfs would be there because its behaviour is implemented mostly within libnetfs itself libdiskfs calls diskfs_reload_global_state libnetfs could do the same, allowing translators to plug in anything they wish but I'll implement it in procfs for the time being ah, its alias is remount yes I need that working for procfs btw, I think I got your mount confusion thing figured out but procfs has nothing to update/flush, all the information are fetched at every rpc yes but we still need to ignore the flag otherwise the set_options rpc fails http://paste.debian.net/12938/ whee, remounting proc works :) :) # IRC, freenode, #hurd, 2013-07-29 so, what do you folks think about refactoring libdiskfs and libnetfs to be more alike? what do you mean? ah, I mentioned that in the context of my mtab prototype 1374247519-26589-1-git-send-email-4winter@informatik.uni-hamburg.de they are hard to diff against each other b/c they differ in file names and identifier names while working on the mtab stuff I encountered stuff that was implemented in libdiskfs, but never in libnetfs mostly support for binding translators to libnetfs nodes teythoon: sure, but looks a little out of scope braunr: I do not mean now, more in general ok teythoon: I wondered about this, too. I don't know if it's possible to literally merge them (and build the backend-based (libdiskfs) vs. volatile-backend one (libnetfs) based on a pre-processor define or similar), or just structure the source code (files) in a way such that »diff -ru libdiskfs/ libnetfs/« gives meaningful results, figuratively spoken. tschwinge: my thoughts exactly # IRC, freenode, #hurd, 2013-08-28 braunr: do you think another lib*fs would be frowned uppon? I like the way procfs is structured and that could be refactored and generalized into a library i think we need more lib*fs libraries and better integration that's one of the strengths in linux it makes writing file systems very easy cool :) now we only need a snappy name, any suggestions? i don't know what you like specificlaly in procfs libpseudofs ? well, it's not perfect, but i like the way you just have to implement a function for a node and it magically gains the ability to being read for example yes i see lacks a bit of caching though no caching for such file systems indeed why would you want caching ? you might have files that don't change at all, or rarely do the premise is that it's meant for files generated on the fly but are they big ?