From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- open_issues/libnetfs_vs_libdiskfs.mdwn | 118 --------------------------------- 1 file changed, 118 deletions(-) delete mode 100644 open_issues/libnetfs_vs_libdiskfs.mdwn (limited to 'open_issues/libnetfs_vs_libdiskfs.mdwn') diff --git a/open_issues/libnetfs_vs_libdiskfs.mdwn b/open_issues/libnetfs_vs_libdiskfs.mdwn deleted file mode 100644 index 2fcfbea5..00000000 --- a/open_issues/libnetfs_vs_libdiskfs.mdwn +++ /dev/null @@ -1,118 +0,0 @@ -[[!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 ? -- cgit v1.2.3