Searched refs:received (Results 1 - 25 of 35) sorted by relevance

12

/barrelfish-master/usr/tests/octopus/
H A Dd2trigger.c39 size_t* received = (size_t*) state; local
40 *received = *received + 1;
48 size_t* received = (size_t*) state; local
49 *received = *received + 1;
68 size_t received = 0; local
80 octopus_BINDING_EVENT, OCT_ON_DEL, trigger_handler, &received);
92 while (received != 1) {
96 received
[all...]
H A Dd2pubsub.c30 size_t* received = (size_t*) st; local
37 debug_printf("Message: %s received: %zx\n", record, *received);
41 ASSERT_STRING(receive_order[*received], name);
50 (*received)++;
60 size_t received = 0; local
65 err = oct_subscribe(message_handler, &received, &id1, "111 [] attr: 10 }");
68 err = oct_subscribe(message_handler, &received, &id1,
74 err = oct_subscribe(message_handler, &received, &id2, "_ { str: r'%s' }",
79 err = oct_subscribe(message_handler, &received,
[all...]
/barrelfish-master/lib/openssl-1.0.0d/crypto/jpake/
H A Djpake.h69 int JPAKE_STEP1_process(JPAKE_CTX *ctx, const JPAKE_STEP1 *received);
78 int JPAKE_STEP2_process(JPAKE_CTX *ctx, const JPAKE_STEP2 *received);
88 int JPAKE_STEP3A_process(JPAKE_CTX *ctx, const JPAKE_STEP3A *received);
93 int JPAKE_STEP3B_process(JPAKE_CTX *ctx, const JPAKE_STEP3B *received);
H A Djpake.c302 int JPAKE_STEP1_process(JPAKE_CTX *ctx, const JPAKE_STEP1 *received) argument
304 if(!is_legal(received->p1.gx, ctx))
310 if(!is_legal(received->p2.gx, ctx))
317 if(!verify_zkp(&received->p1, ctx->p.g, ctx))
324 if(!verify_zkp(&received->p2, ctx->p.g, ctx))
331 if(BN_is_one(received->p2.gx))
338 BN_copy(ctx->p.gxc, received->p1.gx);
339 BN_copy(ctx->p.gxd, received->p2.gx);
414 int JPAKE_STEP2_process(JPAKE_CTX *ctx, const JPAKE_STEP2 *received) argument
430 if(verify_zkp(received, t
464 JPAKE_STEP3A_process(JPAKE_CTX *ctx, const JPAKE_STEP3A *received) argument
491 JPAKE_STEP3B_process(JPAKE_CTX *ctx, const JPAKE_STEP3B *received) argument
[all...]
/barrelfish-master/lib/bulk_transfer/backends/net/
H A Dbulk_net_e10k.h39 void (*received)(struct bulk_e10k *,
H A Dbulk_net_e10k.c341 rxe->bu->received(rxe->bu, &rxe->msg);
540 * @param received Callback for a received packet
549 void (*received)(struct bulk_e10k *,
563 bu->received = received;
623 * a received packet.
H A Dbulk_net_backend.h183 * @param received Callback for a received packet
192 void (*received)(struct bulk_e10k *,
203 * a received packet.
/barrelfish-master/usr/monitor/
H A Dtiming.c27 static int received; variable
32 received++;
54 received = 0;
76 while(received < waitfor) {
/barrelfish-master/lib/net/test/
H A Dudp_ping.c56 uint8_t received; member in struct:result
95 results[seq & (PING_RESULT_MAX - 1)].received = 1;
139 results[ping_seq_num & (PING_RESULT_MAX - 1)].received = 0;
154 if (!results[ping_seq_num & (PING_RESULT_MAX - 1)].received) {
H A Dping.c51 uint8_t received; member in struct:result
89 results[seq & (PING_RESULT_MAX - 1)].received = 1;
140 results[ping_seq_num & (PING_RESULT_MAX - 1)].received = 0;
155 if (!results[ping_seq_num & (PING_RESULT_MAX - 1)].received) {
/barrelfish-master/include/net_sockets/
H A Dnet_sockets.h12 net_received_callback_t received; member in struct:net_socket
/barrelfish-master/include/bulk_transfer/
H A Dbulk_net.h50 void (*received)(struct bulk_e10k *, member in struct:bulk_e10k
/barrelfish-master/include/net/
H A Dif_arp.h104 uint64_t rxrequests; /* # of ARP requests received by this host. */
105 uint64_t rxreplies; /* # of ARP replies received by this host. */
106 uint64_t received; /* # of ARP packets received by this host. */ member in struct:arpstat
/barrelfish-master/usr/drivers/ahcid/
H A Dtest.c241 bufferid_t *received = calloc(1, sizeof(bufferid_t) * read_requests); local
280 free(received);
320 bufferid_t *received = calloc(1, sizeof(bufferid_t) * requests); local
343 memset((void*)received, 0x0, sizeof(bufferid_t)*requests);
/barrelfish-master/doc/015-disk-driver-arch/
H A Dxahcid.tex39 init procedure is called, ahcid consults the received base address registers to
60 checks which ports received an interrupt and clears the port's interrupt
63 has received an interrupt, ahcid sends a \lstinline+command_completed+ message
H A Dintro.tex75 The received \ac{fis} area serves as an area where copies of the \acp{fis}
76 received from the device are stored. The \ac{hba} will copy all incoming
/barrelfish-master/doc/018-Practical-guide/
H A DhelloWorldApp.tex216 printf("server: received hello_msg:\n\t%s\n", str);
233 printing out the string we received as part of the message.
471 server: received hello_msg:
473 server: received hello_msg:
475 server: received hello_msg:
477 server: received hello_msg:
479 server: received hello_msg:
481 server: received hello_msg:
/barrelfish-master/lib/net_sockets/
H A Dnet_sockets.c100 socket->received = NULL;
346 socket->received = cb;
408 if (socket->received) {
411 socket->received(socket->user_state, socket, shb_data, nb->size, nb->host_address, nb->port);
/barrelfish-master/usr/eclipseclp/documents/libman/
H A Dmp.tex115 messages can be received.
141 \item [msg\_pending(+PortId)] Check for presence of received messages.
/barrelfish-master/usr/eclipseclp/documents/mpslib/
H A Doutline.tex98 received from ports. Messages are Prolog terms.
184 Messages, i.e. Prolog terms, are sent to and received from ports
273 "Hello World !", is sent to and received from a port. The first
431 A notification predicate should have received all the messages from a port
/barrelfish-master/doc/006-routing/
H A DRouting.tex75 \item \textbf{Memory}: Any ICD link will require some memory to buffer unsent messages and messages that have been received but not yet delivered. Some links will require additional memory for the channel itself. For instance, the shared-memory UMP driver on x86 requires two pages of physical memory per binding. In general, the amount of memory required is governed by the number of messages in flight and
165 The virtual circuit switching approach would also allow to reserve some resources on the nodes for each channel. Per-channel reserved resources could include buffer space to save received, but not yet forwarded messages, or bandwidth on the ICD links. This is potentially very useful for congestion and flow control. Note that we cannot simply drop messages in case of congested links, as we want to provide a reliable messaging service. As of now, we do not reserve resources on the nodes, but allocate required resources dynamically.
217 \item The monitor proxies the bind replay back to where it received the bind request from.
232 In order to support sending messages, the existing messaging interfaces between dispatchers and their local monitor, and between monitors has been extended. Each multi-hop message contains a VCI, a field encoding the direction of the message and the message payload (as a dynamic array). Furthermore, it contains one field encoding message flags and another field used to acknowledge received messages. Those two fields are used for flow control (see section~\ref{section: flow control}).
283 The flow control mechanism is completely transparent to applications. It is entirely handled by the multi-hop interconnect driver. On each message sent by a dispatcher over a multi-hop channel an acknowledgement for all messages previously received over this channel is piggy-backed.
285 If an application uses a one-way communication schema, i.e. one dispatcher is always sending while the other is only receiving, it is not possible to piggy-back acknowledgements on messages sent the other way. In such a case, the multi-hop interconnect driver sends a dummy message. A dummy message contains no message payload, but acknowledges all received messages. This approach ensures that acknowledgements are, whenever possible, piggy-backed on messages. Only if it is absolutely necessary, an acknowledgement is sent in its own message.
326 We include the size of every dynamically sized argument in the message payload. This tells the receiver about the size of those arguments and allows him to retrieve them from the received message payload. Currently, we use 8 bytes to transfer the size of a dynamic argument. This ensures that we do not get an overflow. We account for those size fields when calculating the size of the message payload.
336 The send continuation is the only way to know when a message has been sent over the multi-hop channel and it is safe to send the next message. Note that even if an application uses a ping pong communication scheme, i.e. it sends a message back and forth between two dispatchers, it is not guaranteed to not get a \texttt{FLOUNDER\_ERR\_TX\_BUSY} error code, unless it serialises all sends with the continuation. This somewhat unintentional behaviour is caused by the fact that the multi-hop channel internally relies on other ICD-links to transport messages. The multi-hop channel itself uses send continuations on the underlying ICD-links to determine when it can accept another message. Those send continuations are always executed after a message is sent. Therefore it is possible (although unlikely) that a message is sent and the reply for that message is received, before the multi-hop channel can accept the next message.
344 If the user-defined message contains dynamic arguments, we have to allocate space for each of those arguments separately and copy them from the received multi-hop message. This is necessary, because all dynamic message arguments are passed by reference to the user and become property of the user. The user must be able to free those arguments separately, therefore they must be copied to separately allocated memory. Fixed-size arguments are simply passed on the stack to the user.
/barrelfish-master/doc/023-coreboot/
H A Dcoreboot.tex105 start-up. On boot-up, the kernel checks if the KCB it received is initialized.
261 to be received on that core etc. which can cause the whole system to lock-up. It
/barrelfish-master/usr/eclipseclp/documents/embedding/
H A Dembvb.tex103 events may be received by the Visual Basic program during the
/barrelfish-master/doc/026-device-queues/
H A Ddevif.tex313 and even when a notification is received there is no guarantee that the queue contains any buffers
315 dequeues a buffer, it has to invalidate its cache of the received buffer when
724 of the queue and a queue id. With the received cap,
743 are received can be requested, otherwise one of the 1024 VNICs will be used.
929 This handler is called whenever a \texttt{notify} from the other process is received.
/barrelfish-master/doc/014-bulk-transfer/
H A Dbulk-transfer.tex184 receiving side, each received packet involves 2 messages
185 (register-pbuf, packet-received). The performance impact of these
334 received packet.
346 internal queue (RX-queue) of slots where the packet received
777 \textit{packet received interrupt} from NIC hardware to the device

Completed in 219 milliseconds

12