From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 6A82A3858415 for ; Fri, 5 Apr 2024 12:59:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6A82A3858415 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6A82A3858415 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712321984; cv=none; b=KXZaSNJ0KwMUSpLp1dHnTCmHEQRQH4ugsIQ9htaWcf84jbRkjM/wk24P0jQpsMHiUKEUfXLmfEzQgS28/GTvDyrUHkBv7nVwe9OCPKD7mJxJKkOzv+1KE2vxWFt4Eft8QAYFHghZv2lzlBJXy6B3MMdv3UfRIBAM4uf4Z8p8tB4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712321984; c=relaxed/simple; bh=fSbT/HhBlvSlstDKOEnsFRuDC63P2Cx2hO49awPaelQ=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=atfzGmYjglSZiUFs5sn+7yZQvdqFA+ZOqqk5ZXK528R5XF2GBPeMDr/e3twUBpC3fLDPddU/sBudrRe2A4FI1moD2Rt59GIzdoJ6zL37kBPH1p15ESG+dcDzxs0R3z1vizCC10DiGy7zqEvPD8D9tbIZIvO1iPftIm0mjwnHROo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712321983; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0vwdgpCSLPd/eXUneJ0l2rcPrZPughO2cMm4cdBrMMc=; b=fi3tPun3QXtq1k18GJGBabHdZk8pDQmIGYeC2+viBHQn1diXOGtquIi69yMhi7zoF6j//w poEFOfEG5HBGNp+3YXqA4oTGnRKEETdqeux+NNHb7/CqaoifpFBAe6XeQY6utEcgjuQv6R egXDCFN6dLmcnUF3Q8UtQOlbg0S3GaQ= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-410-VFAKqZt6NISchzJvZ0IkzQ-1; Fri, 05 Apr 2024 08:59:41 -0400 X-MC-Unique: VFAKqZt6NISchzJvZ0IkzQ-1 Received: by mail-lf1-f72.google.com with SMTP id 2adb3069b0e04-516d2048ba1so1082786e87.1 for ; Fri, 05 Apr 2024 05:59:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712321980; x=1712926780; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0vwdgpCSLPd/eXUneJ0l2rcPrZPughO2cMm4cdBrMMc=; b=NOUSWuDlA1QytHtyoIVLaDSgH8ZQUj/48ii5dCnqyTL3V1GovZNRDGMCgWxcszmADX Fh3/x8b0Qhum6NNt8BXmzo717o8ReJJwA/iUURR8m3z8jx2L4uJPk2faplXojbTdZG+A 0Du0Ss9Z3e21Orvo1Gdu8J6NUDdL2gGTofZzeWGCi1MuEnCogAnhG02c5HawqmYcu16H SiNHQU1WX2iibkJaqgE1HV0LekgsjbU3rOKUXpcNQ9SW6hp0ep3h/xsm9N/ZxIv60C8X TCTOlSfhKIRsgpmGuiUCL9XIt4YDQIwGtA7y1TWFZjdU+X+00ENzYe0k4GE6gFjra6Bv lWBQ== X-Forwarded-Encrypted: i=1; AJvYcCWqsbFSaxrzZLOkYgHGZ3L5GhqLCMJSatST/fIgWVl6bY7I+1gTh91lxxepi0SQYem7EoDL5YHSiZ7IHod2lnY6py/oYK6zLRMzWw== X-Gm-Message-State: AOJu0YwLe4ulB5SAcKu4/aHFAi4b+dMDqT+GU/HY6+3ByOlItctS0mlY zG9qYNyYE4/TNpTVlH4hZhFRXAv8dfZBbglupy+gmg9WJf4zCVf83ebUfpvpcBcbFrw3oRCi5r3 haKt/cNPTtGL3ypqTPc+pCgTrnSVIJpg4+7BBdJaur2mtvtbUjXEBg1b9ORI= X-Received: by 2002:a05:6512:510:b0:516:c766:5b4f with SMTP id o16-20020a056512051000b00516c7665b4fmr965283lfb.67.1712321980229; Fri, 05 Apr 2024 05:59:40 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF5oFq9xJ+gPf/kkovMcs7wKNUiO/urJQ7sy/4p/StkBl0EB2rr0qCM/7s3F4W2CEbrGdBKAA== X-Received: by 2002:a05:6512:510:b0:516:c766:5b4f with SMTP id o16-20020a056512051000b00516c7665b4fmr965265lfb.67.1712321979709; Fri, 05 Apr 2024 05:59:39 -0700 (PDT) Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id xa16-20020a170907b9d000b00a474d2d87efsm809562ejc.139.2024.04.05.05.59.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Apr 2024 05:59:39 -0700 (PDT) From: Andrew Burgess To: "Aktemur, Tankut Baris" , Ciaran Woodward , "gdb-patches@sourceware.org" Cc: "tom@tromey.com" Subject: RE: [PATCH v2 3/4] rsp: add 'E' to escaped characters In-Reply-To: References: <2df4539dd59feb3b70f15ed679563a85bb286075.1710420898.git.tankut.baris.aktemur@intel.com> Date: Fri, 05 Apr 2024 13:59:38 +0100 Message-ID: <87msq82ced.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: "Aktemur, Tankut Baris" writes: > Hi Ciaran, > > On Thursday, March 14, 2024 2:47 PM, Ciaran Woodward wrote: >> Hi Tankut, >> >> > Add 'E' to the list of escaped characters when sending/receiving >> > binary data. This is a preparation for the next patch, to be able to >> > distinguish an error response from binary data that starts with 'E'. >> >> I wonder if there is a better way to do this, given that this is for a totally >> new packet. My concerns are twofold: >> >> 1. The other 'escaped' characters are part of the RSP packetization layer, >> which is conceptually below the message processing. This new packet is >> looking at both escaped and non-escaped message in order to figure out >> which type of response it is looking at, which is (in my opinion) >> unnecessary layer crossing. >> >> 2. The idea of allowing this list to grow when there are other possible >> solutions is just less scalable if other new binary packets are added >> in the future. >> >> Instead, I would propose a similar approach to other packets which would >> have the potential for 'ambiguous' replies, such as 'qCRC', 'qMemTags' etc. >> >> That is: Always have a leading byte (not just in the error case) in order >> to disambiguate what type of reply the message contains. >> >> So (for example) the message is something more like: >> >> 'E NN' for an error >> >> 'd XX...' for binary data >> >> Does that sound reasonable? >> (Note that I am not a maintainer, so would appreciate other opinions!) >> >> Thanks, >> Ciaran > > My goal was to keep similarity to packets like 'm', 'g', 'p'. Starting the reply with > a marker is certainly doable. Let's see what the maintainers will say. If that's the > direction, I can work on the change. I'd vote for using a prefix character. Yes it means we diverge from m/g/p, but those are some of our older packets, as you've pointed out in other messages, there are problems with those packets (w.r.t. the empty case). I think using a better solution is more important than consistency. Thanks, Andrew