Home
last modified time | relevance | path

Searched full:message (Results 1 – 25 of 469) sorted by relevance

12345678910>>...19

/Documentation/virt/gunyah/
Dmessage-queue.rst3 Message Queues
5 Message queue is a simple low-capacity IPC channel between two virtual machines.
7 message queue is unidirectional and buffered in the hypervisor. A full-duplex
10 The size of the queue and the maximum size of the message that can be passed is
11 fixed at creation of the message queue. Resource manager is presently the only
12 use case for message queues, and creates messages queues between itself and VMs
13 with a fixed maximum message size of 240 bytes. Longer messages require a
14 further protocol on top of the message queue messages themselves. For instance,
18 The diagram below shows how message queue works. A typical configuration
19 involves 2 message queues. Message queue 1 allows VM_A to send messages to VM_B.
[all …]
/Documentation/driver-api/soundwire/
Dlocking.rst11 - Message lock
26 Message lock
29 SoundWire message transfer lock. This mutex is part of
30 Bus data structure (sdw_bus). This lock is used to serialize the message
38 Message transfer.
40 1. For every message transfer
42 a. Acquire Message lock.
44 b. Transfer message (Read/Write) to Slave1 or broadcast message on
47 c. Release Message lock
59 <-------------------------------+ a. Acquire Message lock
[all …]
/Documentation/ABI/testing/
Ddebugfs-scmi-raw1 What: /sys/kernel/debug/scmi/<n>/raw/message
5 Description: SCMI Raw synchronous message injection/snooping facility; write
6 a complete SCMI synchronous command message (header included)
12 and sent while the replies are read back one message at time
13 (receiving an EOF at each message boundary).
20 Description: SCMI Raw asynchronous message injection/snooping facility; write
21 a complete SCMI asynchronous command message (header included)
30 and sent while the replies are read back one message at time
31 (receiving an EOF at each message boundary).
38 Description: SCMI Raw message errors facility; any kind of timed-out or
[all …]
/Documentation/admin-guide/device-mapper/
Ddm-dust.rst9 the user can send a message to the target to start failing read
93 $ sudo dmsetup message dust1 0 addbadblock 60
96 $ sudo dmsetup message dust1 0 addbadblock 67
99 $ sudo dmsetup message dust1 0 addbadblock 72
111 To enable the "fail read on bad block" behavior, send the "enable" message::
113 $ sudo dmsetup message dust1 0 enable
144 result in an "Invalid argument" error, as well as a helpful message::
146 $ sudo dmsetup message dust1 0 addbadblock 88
147 device-mapper: message ioctl on dust1 failed: Invalid argument
151 result in an "Invalid argument" error, as well as a helpful message::
[all …]
/Documentation/networking/
Dmctp.rst42 Since MCTP is message-based, only ``SOCK_DGRAM`` sockets are supported.
99 match the network, address, and message type will be received by this socket.
101 messages with the TO bit set, to indicate an incoming request message, rather
118 The ``smctp_type`` field specifies which message types to receive. Only the
121 receiving packets with and without a message integrity check footer.
123 ``sendto()``, ``sendmsg()``, ``send()`` : transmit an MCTP message
126 An MCTP message is transmitted using one of the ``sendto()``, ``sendmsg()`` or
135 /* set message destination */
142 /* arbitrary message to send, with message-type header */
152 EID. If ``MCTP_TAG_OWNER`` is not set, the message will be sent with the tag
[all …]
Dstrparser.rst25 outside source. Message are parsed and delivered as the sequence is
36 that is called when a full message has been completed.
56 Temporarily pause a stream parser. Message parsing is suspended
92 parser will parse. timeo is timeout for completing a message.
102 buffer and message timeout is the receive timeout for the socket.
121 parse_msg is called to determine the length of the next message
124 next application layer message in the stream.
128 where the message starts in the skb.
133 >0 indicates length of successfully parsed message
134 0 indicates more data must be received to parse the message
[all …]
Dnetif-msg.rst7 The design of the network interface message level setting.
12 The design of the debugging message interface was guided and
18 integer variable that controls the debug message level. The message
21 The message level was not precisely defined past level 3, but were
34 Initially this message level variable was uniquely named in each driver
45 - Per-interface rather than per-driver message level setting.
76 The set of message levels is named
Dkcm.rst7 Kernel Connection Multiplexor (KCM) is a mechanism that provides a message based
45 The multiplexor provides the message steering. In the transmit path, messages
70 Message delineation
73 Messages are sent over a TCP stream with some application protocol message
75 of a received message can be deduced from the application protocol header
78 A TCP stream must be parsed to determine message boundaries. Berkeley Packet
81 a new message and is given an skbuff that contains the bytes received so far.
82 It parses the message header and returns the length of the message. Given this
83 information, KCM will construct the message of the stated length and deliver it
98 KCM limits the maximum receive message size to be the size of the receive
[all …]
/Documentation/sphinx/
Dkernellog.py15 def warn(app, message): argument
16 logger.warning(message)
18 def verbose(app, message): argument
19 logger.verbose(message)
21 def info(app, message): argument
22 logger.info(message)
/Documentation/userspace-api/netlink/
Dnetlink-raw.rst71 [OUTER NEST OR MESSAGE LEVEL]
84 the wrapper attr has very similar characteristics to a netlink message. It may
87 a sub-message.
89 A sub-message attribute uses the value of another attribute as a selector key to
90 choose the right sub-message format. For example if the following attribute has
103 type: sub-message
104 sub-message: linkinfo-data-msg
107 Then we look for a sub-message definition called ``linkinfo-data-msg`` and use
109 correct format for the sub-message:
126 This would decode the attribute value as a sub-message with the attribute-set
[all …]
/Documentation/devicetree/bindings/powerpc/fsl/
Dmpic-msgr.txt1 * FSL MPIC Message Registers
4 representation of the message register blocks found in some FSL MPIC
9 - compatible: Specifies the compatibility list for the message register
12 the MPIC containing the message registers.
15 message register block's addressable register space. The type shall be
27 bit at bit 'n' indicates that message register 'n' can receive interrupts.
29 be <u32>. If not present, then all of the message registers in the block
34 An alias should be created for every message register block. They are not
50 // Message registers 0 and 2 in this block can receive interrupts on
59 // Message registers 0 and 2 in this block can receive interrupts on
/Documentation/infiniband/
Dtag_matching.rst15 message envelopes may match, the pair that includes the earliest posted-send
21 When a message is sent from the sender to the receiver, the communication
24 this is an expected message, otherwise it is called an unexpected message.
31 1. The Eager protocol- the complete message is sent when the send is
39 A fin message needs to be received in order for the buffer to be reused.
45 unexpected message list. The application posts receive buffers through calls
51 pre-posted receive for this arriving message, it is passed to the software and
52 placed in the unexpected message list. Otherwise the match is processed,
57 When a receive-message is posted, the communication library will first check
58 the software unexpected message list for a matching receive. If a match is
[all …]
/Documentation/userspace-api/media/cec/
Dcec-ioc-receive.rst14 CEC_RECEIVE, CEC_TRANSMIT - Receive or transmit a CEC message
39 To receive a CEC message the application has to fill in the
45 is non-zero and no message arrived within ``timeout`` milliseconds, then
48 A received message can be:
50 1. a message received from another CEC device (the ``sequence`` field will
58 To send a CEC message the application has to fill in the struct
72 the reply will arrive in a later message. The ``sequence`` field can
102 - Timestamp in ns of when the last byte of the message was transmitted.
107 - Timestamp in ns of when the last byte of the message was received.
112 - The length of the message. For :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>` this is filled in
[all …]
Dcec-pin-error-inj.rst45 # <op>[,<mode>] rx-nack NACK the message instead of sending an ACK
47 # <op>[,<mode>] rx-add-byte add a spurious byte to the received CEC message
48 # <op>[,<mode>] rx-remove-byte remove the last byte from the received CEC message
49 # any[,<mode>] rx-arb-lost [<poll>] generate a POLL message to trigger an arbitration lost
60 # <op>[,<mode>] tx-add-bytes <num> append <num> (1-255) spurious bytes to the message
61 # <op>[,<mode>] tx-remove-byte drop the last byte from the message
71 # <op> CEC message opcode (0-255) or 'any'
73 # <bit> CEC message bit (0-159)
75 # <poll> CEC poll message used to test arbitration lost (0x00-0xff, default 0x0f)
101 received or transmitted message, ``always`` to always trigger the error
[all …]
Dcec-ioc-g-mode.rst47 When a CEC message is received, then the CEC framework will decide how
48 it will be processed. If the message is a reply to an earlier
49 transmitted message, then the reply is sent back to the filehandle that
52 If the message is not a reply, then the CEC framework will process it
53 first. If there is no follower, then the message is just discarded and a
55 process it. If there is a follower, then the message is passed on to the
57 the new message. The framework expects the follower to make the right
198 Core message processing details:
204 .. flat-table:: Core Message Processing
215 does nothing and this message has to be handled by a follower
[all …]
/Documentation/driver-api/md/
Dmd-cluster.rst57 2.2 Message passing locks
62 managed through three locks: "token", "message", and "ack", together
63 with the Lock Value Block (LVB) of one of the "message" lock.
76 other nodes to acknowledge the message before proceeding. Only one
77 message can be processed at a time.
79 3.1 Message Types
96 RESYNCING message identifies a range of the devices that the
105 the array. Message contains an identifier for that device. See
112 array. The slot-number of the device is included in the message.
137 3.2.2 message
[all …]
/Documentation/driver-api/
Dconnector.rst12 When the driver receives a special netlink message with the appropriate
40 callback function which will be called when a message with above idx.val
71 msg->seq and msg->ack are used to determine message genealogy. When
72 someone sends a message, they use a locally unique sequence and random
76 The sequence number is incremented with each message sent.
78 If you expect a reply to the message, then the sequence number in the
79 received message MUST be the same as in the original message, and the
82 If we receive a message and its sequence number is not equal to one we
83 are expecting, then it is a new message. If we receive a message and
86 message + 1, then it is a new message.
[all …]
Dmessage-based.rst1 Message-based devices
4 Fusion message devices
7 .. kernel-doc:: drivers/message/fusion/mptbase.c
10 .. kernel-doc:: drivers/message/fusion/mptscsih.c
/Documentation/crypto/
Dapi-digest.rst1 Message Digest Algorithm Definitions
5 :doc: Message Digest Algorithm Definitions
10 Asynchronous Message Digest API
14 :doc: Asynchronous Message Digest API
28 Synchronous Message Digest API
32 :doc: Synchronous Message Digest API
/Documentation/devicetree/bindings/mailbox/
Dti,message-manager.txt1 Texas Instruments' Message Manager Driver
4 The Texas Instruments' Message Manager is a mailbox controller that has
5 configurable queues selectable at SoC(System on Chip) integration. The Message
10 Message Manager Device Node:
14 - compatible: Shall be: "ti,k2g-message-manager"
24 For ti,k2g-message-manager, this shall contain:
33 compatible = "ti,k2g-message-manager";
/Documentation/driver-api/nfc/
Dnfc-pn544.rst19 write functions behave a bit differently because the message formats
26 HCI messages consist of an eight bit header and the message body. The
27 header contains the message length. Maximum size for an HCI message is
30 and third (LSB) bytes of the message. The maximum FW message length is
/Documentation/devicetree/bindings/net/can/
Dbosch,m_can.yaml24 - description: message RAM
55 Message RAM configuration data.
56 Multiple M_CAN instances can share the same Message RAM
58 in Message RAM is also configurable, so this property is
59 telling driver how the shared or private Message RAM are
64 The 'offset' is an address offset of the Message RAM where
66 0x0 if you're using a private Message RAM. The remain cells
78 Please refer to 2.4.1 Message RAM Configuration in Bosch
82 - description: The 'offset' is an address offset of the Message RAM where
84 you're using a private Message RAM.
/Documentation/devicetree/bindings/firmware/
Dgunyah-hypervisor.yaml15 of the message queues used to communicate with the Gunyah Resource Manager.
36 Manager VM using Gunyah Message Queues.
44 - description: Gunyah capability ID of the TX message queue
45 - description: Gunyah capability ID of the RX message queue
49 - description: Interrupt for the TX message queue
50 - description: Interrupt for the RX message queue
/Documentation/w1/
Dw1-netlink.rst5 Message types
24 __u8 type - message type.
65 Each connector message can include one or more w1_netlink_msg with
87 Replies to W1_LIST_MASTERS should send a message back to the userspace
97 Each message is at most 4k in size, so if number of master devices
111 [cn_msg, ack = 1 and increasing, 0 means the last message,
119 w1_netlink_cmd->len = N * 8; where N is number of IDs in this message.
142 as request message except that length parameters do not account for data
155 request message (except lengths as described above).
162 even if there were errors, only length mismatch interrupts message processing.
[all …]
/Documentation/virt/hyperv/
Dvmbus.rst108 the message length, the offset of the message payload, some flags, and a
109 transactionID. The portion of the message after the header is
114 * Unidirectional: Either side sends a message and does not
115 expect a response message
116 * Request/response: One side (usually the guest) sends a message
126 example, a message sent from the storvsc driver might be "execute
127 this SCSI command". If a message also implies some data transfer
129 transferred may be embedded with the control message, or it may be
136 control message contains a list of GPAs that describe the data
144 2. vmbus_sendpacket_pagebuffer(): Message with list of GPAs
[all …]

12345678910>>...19