| /openbmc/openbmc/meta-security/dynamic-layers/meta-perl/recipes-security/bastille/files/ |
| H A D | config | 1 # Q: Would you like to enforce password aging? [Y]
7 # Q: What umask would you like to set for users on the system? [077]
11 # Q: Would you like to deactivate the Apache web server? [Y]
13 # Q: Would you like to password protect single-user mode? [Y]
19 # Q: Would you like to put limits on system resource usage? [N]
21 # Q: Would you like to set more restrictive permissions on the administration utilities? [N]
23 # Q: Would you like to disable SUID status for mount/umount?
25 # Q: Would you like to disable SUID status for ping? [Y]
27 # Q: Would you like to disable SUID status for traceroute? [Y]
33 # Q: Would you like to run the packet filtering script? [N]
[all …]
|
| /openbmc/u-boot/drivers/usb/eth/ |
| H A D | Kconfig | 4 Say Y here if you would like to enable support for USB Ethernet
13 Say Y here if you would like to support ASIX AX8817X based USB 2.0
20 Say Y here if you would like to support ASIX AX88179 based USB 3.0
28 Say Y here if you would like to support Microchip LAN75XX Hi-Speed
38 Say Y here if you would like to support Microchip LAN78XX USB 3.1
47 Say Y here if you would like to support MOSCHIP MCS7830 based
54 Say Y here if you would like to support Realtek RTL8152B/RTL8153 base
62 Say Y here if you would like to support SMSC LAN95xx based USB 2.0
|
| /openbmc/docs/designs/mctp/ |
| H A D | mctp-userspace.md | 18 For OpenBMC, we would introduce a MCTP daemon, which implements the transport
45 The lower interface would be plugged in to one of a number of hardware-specific
46 binding implementations. Most of these would be included in the library source
52 this, the library would be written in portable C (structured in a way that can
68 socket. Each of these would register with the MCTP daemon to receive MCTP
69 messages of a certain type, and would transmit MCTP messages of that same type.
73 daemon would use a message queue to enable message reception/transmission to a
74 blocked daemon, but this would be of a limited size. Handlers whose sockets
75 exceed this queue would be disconnected from the daemon.
128 disjoint set. This would likely lead to unnecessary restrictions on the
[all …]
|
| /openbmc/qemu/docs/system/s390x/ |
| H A D | css.rst | 47 would be ``dev_id = "fe.0.0000"`` and ``subch_id = "fe.0.0000"``.
53 If added to the same Linux guest as above, it would show up as ``0.0.0042``
56 The properties for the device would be ``dev_id = "fe.0.0042"`` and
63 If added to the same Linux guest as above, it would show up as ``0.2.1111``
66 The properties for the device would be ``dev_id = "fe.2.1111"`` and
73 This would not show up in a standard Linux guest.
75 The properties for the device would be ``dev_id = "2.0.2222"`` and
82 This would not show up in a standard Linux guest, either, as ``0`` is not
85 The properties for the device would be ``dev_id = "0.0.1234"`` and
|
| /openbmc/docs/designs/ |
| H A D | thermal-control-modes.md | 51 Initially the current mode would be set to "Default" and the implementation of
52 the interface would populate the supported list of modes.
54 As one implementation, phosphor-fan-presence/control would be updated to extend
55 this dbus interface object which would fill in the list of supported modes from
57 starts, the interface would be added on the zone object and available to be
59 current mode to any of those supported modes and the current mode would be
67 technique would not be reliable in adjusting the floor speeds for only
68 configurations using optical cables. This would instead present the possibility
|
| H A D | psu-monitoring.md | 70 12. The application would periodically communicate with the power supplies via
84 [phosphor-power][6] repository. The application would be written in C++17.
86 Upon startup, the power supply application would be passed a parameter
88 file. This file would contain information such as the D-Bus object name(s),
93 The power supply application would then detect which system type it is running
95 information, what type each supply is, etc. The application would then try to
97 would be considered invalid. The application should continue to check what if
106 The proposed power supply application would not control any fans internal to the
107 power supply, that function would be left to other userspace application(s).
|
| H A D | hw-fault-monitor.md | 17 purposes. The information logged would include a wide variety of chipset
24 Future expansion of the hardware fault monitor would include adding the means to
100 platform-specific system-level data. The fault monitor would therefore
102 information. This information would be bundled, logged, and associated with
106 - The fault monitor would monitor link level retries and link retrainings of
119 center monitoring tools would use the logs to determine whether memory should
152 function is in dump_manager_main.cpp). The new fault log would contain dump
155 would be defined with an additional "dump type" member variable to identify the
175 /redfish/v1/Managers/bmc/LogServices/Dump), but we would like to implement a
|
| H A D | voltage-regulator-configuration.md | 143 _Statement of direction: New interfaces that apply to all regulators would use
145 apply to a single regulator would use the xyz.openbmc_project.Regulator
153 _Statement of direction: New interfaces that apply to all regulators would be
154 implemented on the same object path. Individual regulators would be represented
156 interfaces that apply to a single regulator would be implemented on that path._
208 They believe long term a new driver framework could be designed that would
209 provide this functionality and would be acceptable to the Linux upstream
223 worked. If error checking were added based on return code, it would be
226 would run more slowly than an application and negatively impact boot speed.
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Sensor/ |
| H A D | Accuracy.interface.yaml | 11 ranges. A value of 0.25 would be 0.25%, a value of 2 would represent
12 2%. A value of 2 for 2% would mean that a reading of 10 would have an
|
| /openbmc/docs/architecture/code-update/ |
| H A D | emmc-storage-design.md | 39 IMAGE_TYPES would need to be created to support a different filesystem type.
89 fairly small chip such as a 32MB one would suffice. Therefore, in order to
90 support two firmware versions, the kernel for each version would need to be
99 kernel images. Selection of the desired kernel image would be done with the
103 additional work would be required to introduce a new method to select the
113 ext4 filesystem, although it is unknown how any of the two would perform in an
116 A suitable alternative would be btrfs, which has checksums for both metadata
138 be needed. Therefore, having an initramfs would offer a more standard
146 rofs-b, and read-write). Additional partitions would be needed for a dual boot
171 works in a similar way, so it would not be complex to implement LVM
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/State/ |
| H A D | README.md | 37 A simple system design would be to include a single _BMC_, _Host_, and
45 The _BMC_ would provide interfaces at `/xyz/openbmc_project/state/bmc<instance>`
49 The _Host_ would provide interfaces at
54 The _Chassis_ would provide interfaces at
83 the request would be ambiguous and probably not what the user wanted.
88 multi-chassis system, starting counting from 1 rather than 0 would avoid this
90 chassis. With chassis0 being special, it would allow existing code to continue
93 For example, a system with multiple hosts would have BMCs, Chassis and Hosts
96 them would _not_ be what the API user intended.
|
| /openbmc/openbmc-test-automation/lib/ |
| H A D | boot_utils.robot | 16 # the state that would normally result from
42 # the state that would normally result from
68 # the state that would normally result from
94 # the state that would normally result from
120 # the state that would normally result from
146 # the state that would normally result from
172 # the state that would normally result from
199 # the state that would normally result from
225 # the state that would normally result from
251 # the state that would normally result from
[all …]
|
| H A D | var_stack.py | 46 # The print-out of the object would then look like this:
59 # The print-out of the object would then look like this:
84 sprint the fields of this object. This would normally be for debug purposes.
97 print the fields of this object to stdout. This would normally be for debug purposes.
|
| H A D | var_funcs.py | 110 … proper delimiters in it. A string created by join_dict would qualify.
207 An example of a key/value string would be as follows:
211 In the example shown, the delimiter is ":". The resulting key would be as follows:
214 … If one were to take the default values of to_lower=1 and underscores=1, the resulting key would be
221 The resulting value for the example above would be as follows:
227 In this case, the delim would be "=", the key is "name" and the value is "Mike".
275 The resulting power_limit directory would look like this:
298 The resulting headers_dict would look like this:
315 … so they will be processed as a list rather than as a dictionary. The result would be as follows:
417 The resulting power_limit directory would look like this:
[all …]
|
| /openbmc/docs/architecture/ |
| H A D | LED-architecture.md | 41 All applicable Inventory D-Bus objects would have a forward association mapping
48 All applicable LED Group D-Bus objects would have an association mapping to
72 used. All applicable Inventory D-Bus objects would have a forward association
79 All applicable LED Group D-Bus objects would have an association mapping to
94 would mean turn ON the LED group `true` would mean turn OFF the LED group
153 In the example, below two URIs would be created:
156 `fault` but do so differently. The lamp_test would also drive a blink signal to
|
| /openbmc/qemu/include/authz/ |
| H A D | pamacct.h | 57 * subsystem. The above config would require a config
59 * lookup it would contain
64 * The external file would then contain a list of usernames.
66 * entry would match the distinguish name:
|
| /openbmc/libpldm/tests/transport/ |
| H A D | send_recv_one.cpp | 41 * To test the case when timestamp is closer to the 28 day uptime we would in TEST()
43 * the systems where the unit tests would be run, could have long be a 64 in TEST()
44 * bit integer thus would pass with this anyway but fail on a standard BMC in TEST()
45 * 32bit SOC. Hence workaround this by using `LONG_MAX - 10` which would in TEST()
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Led/ |
| H A D | README.md | 60 this group is acted on, led_1 will turn solid [ON], while led_2 would be
75 - Henceforth, the term **asserted** would mean writing boolean **true** onto
76 `assert` property of the group. Term **de-assert** would mean writing
86 would result in blinking the front and rear Identify LEDs of the enclosure.
91 groups namely; **bmc_booted** and **power_on**. Those would be asserted post
124 the `asserted` property to `true` would result in these actions in `id_front`
|
| /openbmc/openbmc/meta-openembedded/meta-oe/recipes-graphics/openbox/files/ |
| H A D | 0001-openbox-xdg-autostart-convert-to-python3.patch | 84 - print " --list Show a list of the files which would be run"
85 - print " Files which would be run are marked with an asterix"
86 - print " symbol [*]. For files which would not be run,"
107 + print(" --list Show a list of the files which would be run")
108 + print(" Files which would be run are marked with an asterix")
109 + print(" symbol [*]. For files which would not be run,")
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Common/Callout/ |
| H A D | README.md | 7 would be `xyz.openbmc_project.Error.Callout.IIC`, to indicate an IIC callout.
10 is familiar to them, such as a sysfs entry, or an IIC address. It would be up to
17 metadata would be defined in the callout YAML interface. Here is an example (for
74 Taking an example of a generic device callout here, but this would be the flow
90 This would have to be mapped to the BMC planar as the FRU to be called out.
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Logging/ |
| H A D | Event.interface.yaml | 12 entries. The event D-Bus object path would look like
14 Could be network/system state event etc. Type would be given by the
15 application configuration file which would be implementing this interface.
|
| /openbmc/qemu/docs/devel/ |
| H A D | multi-process.rst | 48 this service would not be able to use this exploit to access files or
51 A QEMU control process would remain, but in multi-process mode, will
52 have no direct interfaces to the VM. During VM execution, it would still
56 from the main QEMU program, which would continue to provide CPU
57 emulation. i.e., the control process would also be the CPU emulation
131 vhost user device, the memory operation would need to be sent over a
203 rest of this section is a discussion of how a proxy object model would
211 QEMU code, because for anything but the simplest device, it would not be
218 processes will provide are specified on its command line, as they would
226 would indicate process *disk-proc* uses a qcow2 emulated disk named
[all …]
|
| /openbmc/qemu/docs/system/ |
| H A D | authz.rst | 64 A possible use case would be when configuring QEMU for an incoming live
66 to arrive from. The x509 certificate associated with this source QEMU would
68 machine is dedicated to a specific tenant, then the VNC server would be
199 subsystem. The above config would require a config
201 lookup it would contain
209 The external file would then contain a list of usernames.
211 entry would match the distinguished name:
241 Thus an example using SASL and authorization for the VNC server would look
|
| /openbmc/u-boot/doc/ |
| H A D | README.unaligned-memory-access.txt | 19 reading 4 bytes of data from address 0x10005 would be an unaligned memory
50 to architecture. It would be easy to write a whole document on the differences
88 starting at address 0x10000. With a basic level of understanding, it would
89 not be unreasonable to expect that accessing field2 would cause an unaligned
95 above case it would insert 2 bytes of padding in between field1 and field2.
110 where padding would otherwise be inserted, and hence reduce the overall
120 For a natural alignment scheme, the compiler would only have to add a single
166 Think about what would happen if addr1 was an odd address such as 0x10003.
210 To avoid the unaligned memory access, you would rewrite it as follows:
|
| /openbmc/openbmc/poky/meta/recipes-core/glibc/glibc/ |
| H A D | 0002-localedef-fix-ups-hardlink-to-make-it-compile.patch | 64 - _("Would link: ") :
66 + ("Would link: ") :
69 - _("Would save: ") :
71 + ("Would save: ") :
174 - (ctl->no_link ? _("Would link") : _("Linked")),
176 + (ctl->no_link ? ("Would link") : ("Linked")),
182 - (ctl->no_link ? _("Would link") : _("Linked")),
184 + (ctl->no_link ? ("Would link") : ("Linked")),
186 - (ctl->no_link ? _("would save") : _("saved")),
187 + (ctl->no_link ? ("would save") : ("saved")),
|