[haiku-bugs] Re: [Haiku] #10191: Make NetFS stack an actual HPKG via build system
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Sun, 31 Aug 2014 15:43:42 -0000
#10191: Make NetFS stack an actual HPKG via build system
----------------------------+----------------------------
Reporter: mmadia | Owner: bonefish
Type: task | Status: new
Priority: normal | Milestone: R1
Component: Build System | Version: R1/Development
Resolution: | Keywords:
Blocked By: 10192, 11168 | Blocking:
Has a Patch: 1 | Platform: All
----------------------------+----------------------------
Comment (by bonefish):
We're talking about different "settings" files here. A settings file for
NetFS itself -- i.e. the one defining shares and users -- shouldn't be
included at all. The entry for NetFS in the UserlandFS settings file
specifies information about NetFS's ioctl interface that UserlandFS needs
to know to properly forward the ioctl data. So, strictly speaking, those
aren't settings at all -- changing them would break certain functionality
of NetFS. Let's call such an entry for a client FS an interface
description instead.
It doesn't make much sense that the UserlandFS package includes the
interface description for client FSs. Instead a package that contains a
client FS should also provide the interface description for that client
FS. There's a proven idiom to achieve something like that. It has e.g.
already been implemented for Expander. Instead of a singleton expander
rules file, Expander reads all files in the data/expander/rules
directories of all installation locations. This way a package like
xz_utils can provide a file data/expander/rules/xz_utils which contains
the rules for xz packaged files.
In case of UserlandFS it can be implemented somewhat similarly. UserlandFS
would scan the data/userlandfs/file_systems directories of all
installation locations for a file matching a client FS. The NetFS package
would provide its interface definition via a file
data/userlandfs/file_systems/netfs. So, when UserlandFS wants to load the
settings for NetFS, it would iterate through the installation locations
(in order home non-packaged, home, system non-packaged, system) and read
the first data/userlandfs/file_systems/netfs file it finds. It is not
necessary to merge the content of multiple files.
Regarding your suggestion concerning the driver settings implementation.
For kernel drivers there is usually no need to read more than one settings
file. If a driver supports a settings file, it should be located under
/system/settings/.... The user's home directory should not affect the
kernel at all. We inherited that behavior from BeOS and it doesn't hurt
ATM, since Haiku is essentially single-user, but that will change
eventually. That's also what the TODO in `load_driver_settings()` is
about.
Since in Haiku the driver settings API is also used by certain userland
code, it may be useful to introduce functionality for reading all driver
settings files with a certain name (or really all) from a list of
directories. However, IMO that functionality would be more suitable for
BDriverSettings than for the low level C API. (And it is not needed for
UserlandFS nor for NetFS.)
Regarding your question concerning multiple parameters with the same name,
the `get_driver_*parameter()` functions returns only the first occurrence.
However, the API user can iterate through the driver settings structure
manually and thus handle all occurrences, if necessary.
--
Ticket URL: <https://dev.haiku-os.org/ticket/10191#comment:8>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
