search for: replies

...worth posting now rather than holding it up for the rest of the series. Eric Blake (4): states: Document our reliance on type overlaps generator: Finish parsing structured header in states-reply.c generator: Rename states-reply-structured to states-reply-chunk internal: Refactor layout of replies in sbuf lib/internal.h | 16 ++- generator/state_machine.ml | 53 ++++--- generator/states-reply.c | 65 +++++++-- ...eply-structured.c => states-reply-chunk.c} | 129 ++++++++---------- generator/states-reply-simple.c...

^C --- 10.100.100.74 ping statistics --- 1 packets transmitted, 1 received, +63 duplicates, +1 errors, 0% packet loss, time 0ms rtt min/avg/max/mdev =3D 0.263/2.481/4.266/1.147 ms > This ping is external box to guest, > correct? Either direction, external box->guest or guest->external box > Is it the external box that gets duplicates or the guest? > What happens when you ping

^C --- 10.100.100.74 ping statistics --- 1 packets transmitted, 1 received, +63 duplicates, +1 errors, 0% packet loss, time 0ms rtt min/avg/max/mdev =3D 0.263/2.481/4.266/1.147 ms > This ping is external box to guest, > correct? Either direction, external box->guest or guest->external box > Is it the external box that gets duplicates or the guest? > What happens when you ping

On 6/9/23 04:17, Eric Blake wrote: > In order to more easily add a third reply type with an even larger > header, but where the payload will look the same for both structured > and extended replies, it is nicer if simple and structured replies are > nested inside the same layer of sbuf.reply.hdr. Doing this also lets > us add an alias for accessing the cookie directly without picking > which header type we have on hand. > > Visually, this patch changes the layout (on x86_64)...

...sender (instead of replying to the list) > might happen by mistake. > > Newcomers (or people more used to popular and newer "social media" > than to "good old plain mailing lists"), by not having an adequate > "reply-to" field could, inadvertently, send replies to personal > addresses of other members of the list, instead of replying to the > list itself. > > I am not sure how the reply-to field is annoying, but I guess it > depends on the particular email client and on how each one manages > it. > > To be clear, I don't object...

...bility, with the aim of fewer servers and clients falling back to NBD_OPT_EXPORT_NAME. And since nbdkit as server recently started supporting NBD_OPT_GO (commit f7dd9799), our nbd client as plugin should take advantage of it. This patch is a prerequisite to teaching the nbd plugin about structured replies, which in turn will allow an implementation of .extents. Signed-off-by: Eric Blake <eblake@redhat.com> --- plugins/nbd/nbd.c | 201 +++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 183 insertions(+), 18 deletions(-) diff --git a/plugins/nbd/nbd.c b/plugins/nbd/nbd.c index 14e...

This is about the simplest implementation of NBD Structured Replies (SR) that we can do right now. It accepts NBD_OPT_STRUCTURED_REPLIES when negotiated by the client, but only sends back the simplest possible SR when required to by NBD_CMD_READ. The rest of the time it will send back simple replies as before. We do not modify the plugin API so plugins are unabl...

...n feature where the client and server agree to use larger packet headers on every packet sent during transmission phase. This has two purposes: first, it makes it possible to perform operations like trim, write zeroes, and block status on more than 2^32 bytes in a single command. For NBD_CMD_READ, replies are still implicitly capped by the maximum block payload limits (generally 32M); if you want to know if a hole larger than 32 bits can represent, you'll use BLOCK_STATUS instead of hoping that a large READ will either return a hole or report overflow. But for NBD_CMD_BLOCK_STATUS, it is very u...

...ere sbuf is malloc'd; I'm not sure that it matters much (outside of libnbd, nbd_handle is an opaque type always referenced as a pointer). Eric Blake (7): states: Log structured error messages, if any states: Refactor SET_META_CONTEXT reply parsing states: Allow large SET_CONTEXT_NAME replies states: Rewrite NBD_REP_INFO parsing states: Factor out NBD_REP payload prep states: Give up on oversized reply length states: Capture NBD_REP_ERR message generator/generator | 19 ++-- generator/states-newstyle-opt-go.c | 71 ++++++------- .../states-...

Hi, I have a Dell PowerEdge 1950 with two NICs Broadcom NetXtreme II BCM5708 1000Base-T. I installed CentOS 5.1 and Xen 3.0.3 (RPM). One of my virtual machines has Windows 2003 Server. In this virtual machine my NICs appears like "Realtek RTL8139 Family PCI Fast Ethernet NIC". The problem is that when I ping to other machines sometimes the reply time value is very high: C:>

Could whomever is in charge of the lartc mailing list please change it to add the header: Reply-To: lartc@mailman.ds9a.nl Every other list I''m on is setup so that by default replies will go to the list. When replying to lartc emails I notice myself and others constantly forgetting this list does not behave like the rest, and that we have to either do a reply-to-all, or manually enter in the to address. Thanks, Jody

No progress has been made: cable is UPS - PC 6 - 3 7 - 5 9 - 2 for ./blazer_ser -DDDDD -a infosec 0.000000 send_to_all: SETINFO driver.parameter.port "/dev/ttyS1" 0.000323 debug level is '5' 0.103068 send_to_all: SETINFO device.type "ups" 0.103104 send_to_all: SETINFO driver.version "2.7.3" 0.103118 send_to_all: SETINFO

When processing a server reply within the REPLY subgroup, we will often hit a situation where recv() requires us to block until the next NotifyRead. But since NotifyRead is the only permitted external action while in this group, we are effectively blocking CmdIssue and NotifyWrite events from happening until the server finishes the in-progress reply, even though those events have no strict

...wer (patch 3) - add tests (patch 5) - other bug fixes I found while testing it - drop EOVERFLOW patch for now; it will be separate once upstream NBD protocol specification is clarified Eric Blake (5): nbd: Implement NBD_OPT_GO client request nbd: Refactor receive loop to prepare for structured replies nbd: Implement structured reads from server nbd: Implement .extents nbd: Test .extents plugins/nbd/nbd.c | 534 +++++++++++++++++++++++++++++++++++--- tests/Makefile.am | 3 + tests/test-nbd-extents.sh | 113 ++++++++ 3 files changed, 608 insertions(+), 42 deletions(-) cr...

...dates the logic when a reply has an unexpected handle - previously, we failed for structured (even though the length makes it easy to recover) and passed for simple (even though there is nothing on the wire to state if this response is associated with NBD_CMD_READ if we did not negotiate structured replies, which would allow our state machine to start parsing arbitrary data as new responses); we're better off just always moving to DEAD. --- generator/states-reply-simple.c | 15 ++----- generator/states-reply-structured.c | 61 ++++++----------------------- generator/states-reply.c...

...ing to the list) > > might happen by mistake. > > > > Newcomers (or people more used to popular and newer "social media" > > than to "good old plain mailing lists"), by not having an adequate > > "reply-to" field could, inadvertently, send replies to personal > > addresses of other members of the list, instead of replying to the > > list itself. > > > > I am not sure how the reply-to field is annoying, but I guess it > > depends on the particular email client and on how each one manages > > it. > > &...

....or.option_reply.replylen); - if (magic != NBD_REP_MAGIC || option != NBD_OPT_SET_META_CONTEXT) { - SET_NEXT_STATE (%.DEAD); - set_error (0, "handshake: invalid option reply magic or option"); - return -1; - } switch (reply) { case NBD_REP_ACK: /* End of list of replies. */ - if (len != 0) { - SET_NEXT_STATE (%.DEAD); - set_error (0, "handshake: invalid option reply length"); - return -1; - } SET_NEXT_STATE (%^OPT_GO.START); break; case NBD_REP_META_CONTEXT: /* A context. */ if (len > maxpayload) debug (h...

Hi, is there a chance to alter the list behaviour to not use the sender address of a posting in the reply-to field but dovecot at dovecot.org instead? That way one has to either use "reply to all" in the MUA or manually enter dovecot at dovecot.org in any replies. And a "reply to all" duplicates postings because the posting once goes to the list and once to the original poster, that get's the reply twice then. Or maybe I am missing something ... :-) Udo BestSolution.at GmbH http://www.bestsolution.at

Hi all, A few years ago, at popular request, I changed the default of the list to have a Reply-To: pointing at the list. I personally find it very annoying, and I would like to change the default back. Would people object to trying it? -hpa

Hello i need your help regarding the following issue : i have a hero touch ups from infosec. it is connected via USB to a raspberry pi 3. i?ve configure ups.conf file as below [HERO] driver = blazer_usb vendorid = 0665 productid = 5161 either with port = auto or port = /dev/hidraw0 or port = /dev/ttySo the connection never works i get the