lszdev must be modified to share the site-specific configuration
information from the persistent settings. The persistent configuration
array will be read and tabularized based on the site-id input from the
user.
This patch also accommodates the site specific information in the
lszdev --info command. New information about the site-ids are integrated
with the command. For example,
DEVICE dasd-eckd 0.0.f001
Names : -
Modules : dasd_eckd_mod dasd_mod
Online : no
Exists : yes
Persistent : yes
Sites : 1,2
ATTRIBUTE ACTIVE PERSISTENT SITE1 SITE2
cmb_enable "0" "0" "1" -
eer_enabled "0" - - -
erplog "0" - - -
failfast "0" - - -
last_known_reservation_state "none" - - -
online "0" "1" "1" "1"
raw_track_access "0" - - -
readonly "0" - - -
reservation_policy "ignore" - - -
use_diag "0" - - -
Each available site specific configuration will be shown as column. The
"Sites" parameter in the above output indicates the available site
configurations and the SITE1 and SITE2 colums indicates the detailed
configuration for the respective sites.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Modify the dev_get_setting_list function to get the site-specific
attributes of the device. The new site_id parameter for this function
must be less than SITE_FALLBACK to read the site-specific attributes.
As SITE_FALLBACK setting is same as persistent setting, we do not need
a separate read function for it.
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Currently zdev supports the configuration and maintenance of one single
persistent device state. With the introduction of sites, zdev should be
able to store, configure and maintaine NUM_SITES number of states in
the persistent configuration. This patch modifies the struct device and
adds a new site_specific device_state array, which stores the
persistent configuration for all the available sites.
Total number of available sites are configured with NUM_SITES. Where,
10 site-specific configurations and 1 common configuration.
1. during read, all site data is always read and update the
site_specific[] array.
2. dev->persistent is a copy of dev->site_specific[global_site_id]
3. modifications are only done on dev->persistent, and during write
dev->persistent overlays dev->site_specific[global_site_id]
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add support for defining read-only attributes in the chzdev/lszdev
tools. These attributes can be used to provide online documentation
for specific attributes via the --help-attribute and --list-attributes
tool functions.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com>
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Since commit d542138868 ("zdev: use libutil provided path functions")
lszdev fails to correctly report most read-only sysfs attributes as such
in its detailed information output (options -i or -ii). This is because
the libutil function util_path_is_writable() is not equivalent to the
former function file_writable().
util_path_is_writable() always returns true (the underlying function
access() indicates the file is writable), if the path exists and the user
is root, regardless of the path's effective access permissions. This is
correct for most use cases, as root can effectively read/write any path
regardless of its effective access permissions). util_path_is_writable()
behaves exactly like Bash -w in this regard.
The former function file_writable() examined the file's access permissions
to check if one or more of user, group, and other have write permission.
For lszdev it is irrelevant whether a file is effectively writable by
the current user. Instead it needs to determine whether sysfs attributes
access permissions contain write access in any form. If not it lists
those sysfs attributes in a separate read-only section.
Use the new function util_path_is_readonly_file(), which does explicitly
check the file's effective read and write access permissions. It behaves
similar to the former function file_writable(), except that it does test
whether any of user, group, and other have read permission.
Fixes: d542138868 ("zdev: use libutil provided path functions")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This change adds base infrastructure for implementing internal device
attributes. In the context of the zdev tools, an internal device
attribute is a new type of device attribute with the following
characteristics:
- Can be set and removed like normal device attributes
- Affects zdev-internal handling only
- Does not correspond to an actual device attribute, that is
it has no representation in SysFS
- Can not be set in the active configuration
- Name starts with "zdev:" to prevent conflicts with actual
device attributes
Values for internal device attributes are stored in udev rules alongside
the normal persistent configuration of a device. They are encoded as
udev environment variables. Note that they have no further effect on
udev processing.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Auto-configuration is the name of a new configuration target that is
supported by chzdev and lszdev besides the existing active and
persistent configuration targets. Directives created in this new
configuration are stored as udev rules in the /run/udev/rules.d
directory.
Auto-configuration directives are only in effect if there are no
directives for the same device in the user-provided persistent
configuration. This allows users to override auto-configuration
directives if necessary.
Due to the volatile nature of the /run directory, auto-configuration
directives are cleared on reboot. Therefore mechanisms that generate
auto-configuration directives must recreate them on every boot.
The lszdev tool displays auto-configuration data both in list view
as well as in detail view. Users can specify the new option --auto-conf
to only show data from this configuration target.
Mechanisms that generate automated configuration directives can use
chzdev together with the --auto-conf option to create the corresponding
udev rules.
Note: This change does not include a mechanism that generates
auto-configuration directives.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Apply some changes to existing functions and data structures to simplify
the firmware configuration file support implementation.
- Make qeth and dasd subtype objects non-static
- Change the existing helper functions for reading file contents into
memory to also support binary functions
- Move some configuration file import functions to make them available
for use in other source files
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This commit is based on the s390-tools-1.39.0 version.
Changes on top of s390-tools-1.39.0:
- Add MIT license to all source files
- Add LICENSE file
- Transform REAMDE to README.md (markdown)
- Add AUTHORS.md file
- Add CONTRIBUTING.md file
- Move changelog from README to CHANGELOG.md file
Reviewed-by: Stefan Haberland <sth@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
