path: root/open_issues/libnetfs_vs_libdiskfs.mdwn
diff options
Diffstat (limited to 'open_issues/libnetfs_vs_libdiskfs.mdwn')
1 files changed, 118 insertions, 0 deletions
diff --git a/open_issues/libnetfs_vs_libdiskfs.mdwn b/open_issues/libnetfs_vs_libdiskfs.mdwn
new file mode 100644
index 00000000..2fcfbea5
--- /dev/null
+++ b/open_issues/libnetfs_vs_libdiskfs.mdwn
@@ -0,0 +1,118 @@
+[[!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
+[[!tag open_issue_hurd]]
+# Argument Parsing
+## IRC, freenode, #hurd, 2013-06-27
+ <teythoon> the arg parsing in libdiskfs and libnetfs differ :/
+ <teythoon> afaics libdiskfs gets it right, libnetfs does not
+ <pinotree> what do you mean?
+ <teythoon> wrt to *_std_{runtime,startup}_argp
+ <teythoon> see eg netfs.h
+ <teythoon> libdiskfs/opts-std-runtime.c:const struct argp
+ diskfs_std_runtime_argp =
+ <teythoon> libdiskfs/opts-std-runtime.c-{
+ <teythoon> libdiskfs/opts-std-runtime.c- std_runtime_options, parse_opt,
+ 0, 0, children
+ <teythoon> libdiskfs/opts-std-runtime.c-};
+ <teythoon> but
+ <teythoon> libnetfs/std-runtime-argp.c:const struct argp
+ netfs_std_runtime_argp = { 0 };
+ <pinotree> well there are no common startup/runtime options provided by
+ netfs
+ <pinotree> usually netfs-based translators put netfs_std_startup_argp as
+ child as their options, so if netfs starts providing options they would
+ work
+ <teythoon> ah
+ <pinotree> if you have a test showing issues, we can certainly look it :)
+ <teythoon> ok, m/b I was confused...
+ <pinotree> no worries, feel free to ask anytime
+ <teythoon> I thought about providing --update as common runtime flag, like
+ diskfs does, you think it's the right thing to do?
+ <pinotree> what would it do?
+ <teythoon> or should it be left for each translator to implement?
+ <teythoon> nothing by default I guess
+ <pinotree> options provided in libdiskfs are implemented and handled mostly
+ in libdiskfs itself
+ <pinotree> so imho a new option for libnetfs would be there because its
+ behaviour is implemented mostly within libnetfs itself
+ <teythoon> libdiskfs calls diskfs_reload_global_state
+ <teythoon> libnetfs could do the same, allowing translators to plug in
+ anything they wish
+ <teythoon> but I'll implement it in procfs for the time being
+ <pinotree> ah, its alias is remount
+ <teythoon> yes
+ <teythoon> I need that working for procfs
+ <teythoon> btw, I think I got your mount confusion thing figured out
+ <pinotree> but procfs has nothing to update/flush, all the information are
+ fetched at every rpc
+ <teythoon> yes
+ <teythoon> but we still need to ignore the flag
+ <teythoon> otherwise the set_options rpc fails
+ <teythoon>
+ <teythoon> whee, remounting proc works :)
+ <braunr> :)
+# IRC, freenode, #hurd, 2013-07-29
+ <teythoon> so, what do you folks think about refactoring libdiskfs and
+ libnetfs to be more alike?
+ <pinotree> what do you mean?
+ <teythoon> ah, I mentioned that in the context of my mtab prototype
+ <teythoon> they are hard to diff against each other b/c they differ in file
+ names and identifier names
+ <teythoon> while working on the mtab stuff I encountered stuff that was
+ implemented in libdiskfs, but never in libnetfs
+ <teythoon> mostly support for binding translators to libnetfs nodes
+ <braunr> teythoon: sure, but looks a little out of scope
+ <teythoon> braunr: I do not mean now, more in general
+ <braunr> ok
+ <tschwinge> 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.
+ <teythoon> tschwinge: my thoughts exactly
+# IRC, freenode, #hurd, 2013-08-28
+ <teythoon> 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
+ <braunr> i think we need more lib*fs libraries
+ <braunr> and better integration
+ <braunr> that's one of the strengths in linux
+ <braunr> it makes writing file systems very easy
+ <teythoon> cool :)
+ <teythoon> now we only need a snappy name, any suggestions?
+ <braunr> i don't know what you like specificlaly in procfs
+ <braunr> libpseudofs ?
+ <teythoon> 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
+ <teythoon> for example
+ <braunr> yes i see
+ <pinotree> lacks a bit of caching though
+ <braunr> no caching for such file systems
+ <teythoon> indeed
+ <braunr> why would you want caching ?
+ <pinotree> you might have files that don't change at all, or rarely do
+ <braunr> the premise is that it's meant for files generated on the fly
+ <braunr> but are they big ?