prettierrc: update config
Copy org-wide config from openbmc-build-scripts and reformat
accordingly.
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Ie142989f03f7d702b48f33bbf1c50b3b2f1f47c4
diff --git a/.editorconfig b/.editorconfig
deleted file mode 100644
index 4a4080a..0000000
--- a/.editorconfig
+++ /dev/null
@@ -1,6 +0,0 @@
-[*]
-indent_style = space
-indent_size = 4
-# Config for shfmt
-switch_case_indent = true
-space_redirects = true
diff --git a/.prettierrc.yaml b/.prettierrc.yaml
index f07fbdd..a69b879 100644
--- a/.prettierrc.yaml
+++ b/.prettierrc.yaml
@@ -1,3 +1,7 @@
-tabWidth: 2
+tabWidth: 4
+printWidth: 80
+proseWrap: "always"
overrides:
- - { "files": "*.yaml", "options": { "tabWidth": 4 } }
+ - files: "*.md"
+ options:
+ tabWidth: 2
diff --git a/README.md b/README.md
index 2c8077c..4802467 100644
--- a/README.md
+++ b/README.md
@@ -2,8 +2,8 @@
sdbusplus contains two parts:
-1. A C++ library (libsdbusplus) for interacting with D-Bus, built on top of
- the sd-bus library from systemd.
+1. A C++ library (libsdbusplus) for interacting with D-Bus, built on top of the
+ sd-bus library from systemd.
2. A tool (sdbus++) to generate C++ bindings to simplify the development of
D-Bus-based applications.
@@ -11,8 +11,8 @@
The sdbusplus library requires sd-bus, which is contained in libsystemd.
-The sdbus++ application requires Python 3 and the Python libraries mako
-and inflection.
+The sdbus++ application requires Python 3 and the Python libraries mako and
+inflection.
## Building
@@ -29,8 +29,8 @@
Optionally, building the tests and examples can be disabled by passing
`-Dtests=disabled` and `-Dexamples=disabled` respectively to `meson`.
-The sdbus++ application is installed as a standard Python package
-using `setuptools`.
+The sdbus++ application is installed as a standard Python package using
+`setuptools`.
```sh
cd tools
@@ -63,33 +63,33 @@
```
In a few, relatively succinct, C++ lines this snippet will create a D-Bus
-connection to the system bus, and call the systemd login manager to get a
-list of active users. The message and bus objects are automatically freed
-when they leave scope and the message format strings are generated at compile
-time based on the types being read. Compare this to the corresponding server
-code within [logind].
+connection to the system bus, and call the systemd login manager to get a list
+of active users. The message and bus objects are automatically freed when they
+leave scope and the message format strings are generated at compile time based
+on the types being read. Compare this to the corresponding server code within
+[logind].
In general, the library attempts to mimic the naming conventions of the sd-bus
library: ex. `sd_bus_call` becomes `sdbusplus::bus::call`,
`sd_bus_get_unique_name` becomes `sdbusplus::bus::get_unique_name`,
-`sd_bus_message_get_signature` becomes `sdbusplus::message::get_signature`,
-etc. This allows a relatively straight-forward translation back to the sd-bus
+`sd_bus_message_get_signature` becomes `sdbusplus::message::get_signature`, etc.
+This allows a relatively straight-forward translation back to the sd-bus
functions for looking up the manpage details.
[sd-bus]: http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html
-[logind]: https://github.com/systemd/systemd/blob/d60c527009133a1ed3d69c14b8c837c790e78d10/src/login/logind-dbus.c#L496
+[logind]:
+ https://github.com/systemd/systemd/blob/d60c527009133a1ed3d69c14b8c837c790e78d10/src/login/logind-dbus.c#L496
## Binding generation tool
-sdbusplus also contains a bindings generator tool: `sdbus++`. The purpose of
-a bindings generator is to reduce the boilerplate associated with creating
-D-Bus server or client applications. When creating a server application,
-rather than creating sd-bus vtables and writing C-style functions to handle
-each vtable callback, you can create a small YAML file to define your D-Bus
-interface and the `sdbus++` tool will create a C++ class that implements your
-D-Bus interface. This class has a set of virtual functions for each method
-and property, which you can overload to create your own customized behavior
-for the interface.
+sdbusplus also contains a bindings generator tool: `sdbus++`. The purpose of a
+bindings generator is to reduce the boilerplate associated with creating D-Bus
+server or client applications. When creating a server application, rather than
+creating sd-bus vtables and writing C-style functions to handle each vtable
+callback, you can create a small YAML file to define your D-Bus interface and
+the `sdbus++` tool will create a C++ class that implements your D-Bus interface.
+This class has a set of virtual functions for each method and property, which
+you can overload to create your own customized behavior for the interface.
There are currently two types of YAML files: [interface](docs/yaml/interface.md)
and [error](docs/yaml/error.md). Interfaces are used to create server and client
diff --git a/docs/asio.md b/docs/asio.md
index b215d9e..04ff9c1 100644
--- a/docs/asio.md
+++ b/docs/asio.md
@@ -8,18 +8,20 @@
To return a D-Bus error reply for either GetProperty or SetProperty, throw a
custom exception derived from `sdbusplus::exception_t`. For the custom
-exception, you can return a well-defined org.freedesktop.DBus.Error
-(https://www.freedesktop.org/software/systemd/man/sd-bus-errors.html#) from the
-`name()` or a custom/arbitrary name. The former will be automatically translated
-into a matching error code
-(https://github.com/systemd/systemd/blob/485c9e19e7ebcd912d5fbf11f40afc62951173f8/src/libsystemd/sd-bus/bus-error.c)
-that can be consumed by the caller, while the latter will always be mapped to
-`EIO`, requiring a `strcmp` to determine the exact error name.
+exception, you can return a well-defined [org.freedesktop.DBus.Error][1] from
+the `name()` or a custom/arbitrary name. The former will be automatically
+translated into a matching [error code][2] that can be consumed by the caller,
+while the latter will always be mapped to `EIO`, requiring a `strcmp` to
+determine the exact error name.
The handler may also throw any exception not derived from
`sdbusplus::exception_t`, in which case a generic
org.freedesktop.DBus.Error.InvalidArgs error will be returned to the caller.
+[1]: https://www.freedesktop.org/software/systemd/man/sd-bus-errors.html#
+[2]:
+ https://github.com/systemd/systemd/blob/485c9e19e7ebcd912d5fbf11f40afc62951173f8/src/libsystemd/sd-bus/bus-error.c
+
### Get Property callback
When registering a property using ASIO methods, the get callback should meet the
diff --git a/docs/yaml/error.md b/docs/yaml/error.md
index 4177547..292b0ef 100644
--- a/docs/yaml/error.md
+++ b/docs/yaml/error.md
@@ -1,19 +1,17 @@
# Error YAML
-D-Bus errors can be defined by creating a YAML file to describe the errors.
-From this YAML file, both documentation and binding code may be generated.
-The generated bindings are C++ exception types corresponding to the D-Bus
-error name. Ex. `org.freedesktop.Example.Error.SomeError` will create a
-generated exception type of
-`sdbusplus::org::freedesktop::Example::Error::SomeError` which may be thrown
-or caught as appropriate. If the error is thrown from an interface method
-which has specified it may return that error, then the bindings will generate
-a catch clause that returns a D-Bus error like
+D-Bus errors can be defined by creating a YAML file to describe the errors. From
+this YAML file, both documentation and binding code may be generated. The
+generated bindings are C++ exception types corresponding to the D-Bus error
+name. Ex. `org.freedesktop.Example.Error.SomeError` will create a generated
+exception type of `sdbusplus::org::freedesktop::Example::Error::SomeError` which
+may be thrown or caught as appropriate. If the error is thrown from an interface
+method which has specified it may return that error, then the bindings will
+generate a catch clause that returns a D-Bus error like
"org.freedesktop.Example.Error.SomeError" to the method caller.
-The error YAML is simply a list of `name` along with optional `description`
-and `errno` properties.
-Example:
+The error YAML is simply a list of `name` along with optional `description` and
+`errno` properties. Example:
```yaml
- name: SomeError
diff --git a/docs/yaml/interface.md b/docs/yaml/interface.md
index 69ef12d..e5b6e28 100644
--- a/docs/yaml/interface.md
+++ b/docs/yaml/interface.md
@@ -1,16 +1,15 @@
# Interface YAML
-D-Bus interfaces can be defined by creating a YAML file to describe the
-methods, properties, and signals they contain. From this YAML file,
-both documentation and binding code may be generated.
+D-Bus interfaces can be defined by creating a YAML file to describe the methods,
+properties, and signals they contain. From this YAML file, both documentation
+and binding code may be generated.
## YAML sections
An interface YAML may have the following sections:
- description
- - A small documentation section describing the purpose of the
- interface.
+ - A small documentation section describing the purpose of the interface.
- methods
- A list of methods provided by this D-Bus interface.
- properties
@@ -22,33 +21,32 @@
## Enumerations
-A common problem we have found with D-Bus interfaces is having a consistent
-way to define enumerations. Two common practices are to either assign
-special meaning to integers, as a C compiler might do, or to have specific
-strings representing the enumeration name. The
-[D-Bus API design guidelines][dbus-design-guidelines] specify both of these
-options:
+A common problem we have found with D-Bus interfaces is having a consistent way
+to define enumerations. Two common practices are to either assign special
+meaning to integers, as a C compiler might do, or to have specific strings
+representing the enumeration name. The [D-Bus API design
+guidelines][dbus-design-guidelines] specify both of these options:
> For APIs being used in constrained situations, enumerated values should be
-> transmitted as unsigned integers. For APIs which need to be extended by
-> third parties or which are used in more loosely coupled systems, enumerated
-> values should be strings in some defined format.
+> transmitted as unsigned integers. For APIs which need to be extended by third
+> parties or which are used in more loosely coupled systems, enumerated values
+> should be strings in some defined format.
What we have done in `sdbus++` is to consider enumerations as a first-class
-type. Within an interface you can define an enumeration and the bindings
-will have a C++ enumeration defined for it. At a D-Bus level any property or
-method parameter will be a string, but the string will contain a
-fully-qualified name "interface.enum-name.enum-value" like
-"org.freedesktop.Example.Color.Red". Within the generated bindings, an
-automatic conversion is done between strings and C++ enumeration values and
-clients will get an "xyz.openbmc_project.sdbusplus.Error.InvalidEnumString"
-error response if they attempt to use an invalid string value.
+type. Within an interface you can define an enumeration and the bindings will
+have a C++ enumeration defined for it. At a D-Bus level any property or method
+parameter will be a string, but the string will contain a fully-qualified name
+"interface.enum-name.enum-value" like "org.freedesktop.Example.Color.Red".
+Within the generated bindings, an automatic conversion is done between strings
+and C++ enumeration values and clients will get an
+"xyz.openbmc_project.sdbusplus.Error.InvalidEnumString" error response if they
+attempt to use an invalid string value.
An enumeration must have the YAML properties `name` and `values` and may
-optionally contain a `description`. The `name` is a word corresponding to
-the desired "enum-name" portion of the fully-qualified name and the resulting
-C++ enum type. The `values` are a list of enumeration values each containing
-their own `name` and optional `description`.
+optionally contain a `description`. The `name` is a word corresponding to the
+desired "enum-name" portion of the fully-qualified name and the resulting C++
+enum type. The `values` are a list of enumeration values each containing their
+own `name` and optional `description`.
Example:
@@ -70,9 +68,9 @@
### Base types
-Types are identified in YAML using their typename found in the
-[D-Bus specification][dbus-spec], but listed using lowercases: `int64`
-instead of `INT64` or C++ `int64_t`.
+Types are identified in YAML using their typename found in the [D-Bus
+specification][dbus-spec], but listed using lowercases: `int64` instead of
+`INT64` or C++ `int64_t`.
- `byte`
- `boolean`
@@ -122,8 +120,8 @@
It may seem odd that variants are required to list the types they may contain,
but this is due to C++ being a strongly-typed language. In order to generate
-bindings, to read from and append to a message, the binding generator must
-know all possible types the variant may contain.
+bindings, to read from and append to a message, the binding generator must know
+all possible types the variant may contain.
### Enumeration Types
@@ -194,12 +192,11 @@
If no flag is given, a property will default to `emits_change`.
-Both `const` and `readonly` prevent D-Bus clients from being able to write
-to a property. `const` is a D-Bus indication that the property can never
-change, while `readonly` properties can be changed by the D-Bus server itself.
-As examples, the `Version` property on a software object might be appropriate
-to be `const` and the `Value` property on a sensor object would likely be
-`readonly`.
+Both `const` and `readonly` prevent D-Bus clients from being able to write to a
+property. `const` is a D-Bus indication that the property can never change,
+while `readonly` properties can be changed by the D-Bus server itself. As
+examples, the `Version` property on a software object might be appropriate to be
+`const` and the `Value` property on a sensor object would likely be `readonly`.
Example:
@@ -219,8 +216,8 @@
## Signals
A signal must have the YAML property `name` and may optionally have a
-`description` and list of `properties`. Properties are specified the same
-as interface properties.
+`description` and list of `properties`. Properties are specified the same as
+interface properties.
Example:
diff --git a/example/yaml/net/poettering/Calculator.interface.yaml b/example/yaml/net/poettering/Calculator.interface.yaml
index 543d559..4862f84 100644
--- a/example/yaml/net/poettering/Calculator.interface.yaml
+++ b/example/yaml/net/poettering/Calculator.interface.yaml
@@ -1,6 +1,6 @@
description: >
- An example interface originally described as part of the announcement
- of new sd-bus interfaces at:
+ An example interface originally described as part of the announcement of new
+ sd-bus interfaces at:
http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html
methods:
- name: Multiply