CVSROOT:/cvs
Module name:src
Changes by: j...@cvs.openbsd.org2024/04/24 23:26:41
Modified files:
usr.bin/vi/docs/USD.doc/vi.ref: set.opt.roff
Log message:
add percentage to ruler after recent changes;
From: Jason Xing
At last, we should let it work by introducing this reset reason in
trace world.
One of the possible expected outputs is:
... tcp_send_reset: skbaddr=xxx skaddr=xxx src=xxx dest=xxx
state=TCP_ESTABLISHED reason=NOT_SPECIFIED
Signed-off-by: Jason Xing
Reviewed-by: Steven
From: Jason Xing
Since we have mapped every mptcp reset reason definition in enum
sk_rst_reason, introducing a new helper can cover some missing places
where we have already set the subflow->reset_reason.
Note: using SK_RST_REASON_NOT_SPECIFIED is the same as
SK_RST_REASON_MPTCP_RST_EUNS
From: Jason Xing
It relies on what reset options in the skb are as rfc8684 says. Reusing
this logic can save us much energy. This patch replaces most of the prior
NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
Reviewed-by: Matthieu Baerts (NGI0)
---
net/mptcp/protocol.h | 27
From: Jason Xing
Reuse the dropreason logic to show the exact reason of tcp reset,
so we can finally display the corresponding item in enum sk_reset_reason
instead of reinventing new reset reasons. This patch replaces all
the prior NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
include
From: Jason Xing
Like what we did to passive reset:
only passing possible reset reason in each active reset path.
No functional changes.
Signed-off-by: Jason Xing
Acked-by: Matthieu Baerts (NGI0)
---
include/net/tcp.h | 3 ++-
net/ipv4/tcp.c| 15 ++-
net/ipv4
From: Jason Xing
Adjust the parameter and support passing reason of reset which
is for now NOT_SPECIFIED. No functional changes.
Signed-off-by: Jason Xing
Acked-by: Matthieu Baerts (NGI0)
---
include/net/request_sock.h | 4 +++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c
From: Jason Xing
Add a new standalone file for the easy future extension to support
both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
This patch only does the preparations for reset reason mechanism,
nothing else changes.
The reset reasons are divided into three parts:
1
From: Jason Xing
In production, there are so many cases about why the RST skb is sent but
we don't have a very convenient/fast method to detect the exact underlying
reasons.
RST is implemented in two kinds: passive kind (like tcp_v4_send_reset())
and active kind (like tcp_send_active_reset
> + u16 vf_devid;
> +};
> +
> +struct octep_vdpa {
> + struct vdpa_device vdpa;
> + struct octep_hw *oct_hw;
> + struct pci_dev *pdev;
> +};
> +
> +struct octep_vdpa_mgmt_dev {
> + struct vdpa_mgmt_dev mdev;
> + struct octep_hw oct_hw;
> + struct pci_dev *pdev;
> + /* Work entry to handle device setup */
> + struct work_struct setup_task;
> + /* Device status */
> + atomic_t status;
> +};
> +
> +static struct octep_hw *vdpa_to_octep_hw(struct vdpa_device *vdpa_dev)
> +{
> + struct octep_vdpa *oct_vdpa;
> +
> + oct_vdpa = container_of(vdpa_dev, struct octep_vdpa, vdpa);
> +
> + return oct_vdpa->oct_hw;
> +}
> +
> +static irqreturn_t octep_vdpa_intr_handler(int irq, void *data)
> +{
> + struct octep_hw *oct_hw = data;
> + int i;
> +
> + for (i = 0; i < oct_hw->nr_vring; i++) {
> + if (oct_hw->vqs[i].cb.callback &&
> ioread32(oct_hw->vqs[i].cb_notify_addr)) {
> + /* Acknowledge the per queue notification to the
> device */
> + iowrite32(0, oct_hw->vqs[i].cb_notify_addr);
> + oct_hw->vqs[i].cb.callback(oct_hw->vqs[i].cb.private);
> + }
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +static void octep_free_irqs(struct octep_hw *oct_hw)
> +{
> + struct pci_dev *pdev = oct_hw->pdev;
> +
> + if (oct_hw->irq != -1) {
> + devm_free_irq(>dev, oct_hw->irq, oct_hw);
> + oct_hw->irq = -1;
> + }
> + pci_free_irq_vectors(pdev);
> +}
> +
> +static int octep_request_irqs(struct octep_hw *oct_hw)
> +{
> + struct pci_dev *pdev = oct_hw->pdev;
> + int ret, irq;
> +
> + /* Currently HW device provisions one IRQ per VF, hence
> +* allocate one IRQ for all virtqueues call interface.
> +*/
> + ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSIX);
> + if (ret < 0) {
> + dev_err(>dev, "Failed to alloc msix vector");
> + return ret;
> + }
> +
> + snprintf(oct_hw->vqs->msix_name, sizeof(oct_hw->vqs->msix_name),
> +OCTEP_VDPA_DRIVER_NAME "-vf-%d", pci_iov_vf_id(pdev));
> +
> + irq = pci_irq_vector(pdev, 0);
> + ret = devm_request_irq(>dev, irq, octep_vdpa_intr_handler, 0,
> + oct_hw->vqs->msix_name, oct_hw);
> + if (ret) {
> + dev_err(>dev, "Failed to register interrupt handler\n");
> + goto free_irq_vec;
> + }
> + oct_hw->irq = irq;
> +
> + return 0;
> +
> +free_irq_vec:
> + pci_free_irq_vectors(pdev);
> + return ret;
> +}
> +
> +static u64 octep_vdpa_get_device_features(struct vdpa_device *vdpa_dev)
> +{
> + struct octep_hw *oct_hw = vdpa_to_octep_hw(vdpa_dev);
> +
> + return oct_hw->features;
> +}
> +
> +static int octep_vdpa_set_driver_features(struct vdpa_device *vdpa_dev, u64
> features)
> +{
> + struct octep_hw *oct_hw = vdpa_to_octep_hw(vdpa_dev);
> + int ret;
> +
> + pr_debug("Driver Features: %llx\n", features);
> +
> + ret = octep_verify_features(features);
> + if (ret)
> + return ret;
Nit: I think we need a warning or something here.
Other part looks good.
With those fixed.
Acked-by: Jason Wang
Thanks
On Wed, Apr 24, 2024 at 5:51 PM Michael S. Tsirkin wrote:
>
> On Wed, Apr 24, 2024 at 08:44:10AM +0800, Jason Wang wrote:
> > On Tue, Apr 23, 2024 at 4:42 PM Michael S. Tsirkin wrote:
> > >
> > > On Tue, Apr 23, 2024 at 11:09:59AM +0800, Jason Wang wrote:
> >
Module Name:src
Committed By: thorpej
Date: Thu Apr 25 01:33:04 UTC 2024
Modified Files:
src/sys/dev/usb: uftdi.c
Log Message:
Add a match quirk to prevent matching any interface on SiPEED FPGA
development boards (e.g. Tang Nano 9K). The FT2232s on these boards
are wired
Module Name:src
Committed By: thorpej
Date: Thu Apr 25 01:33:04 UTC 2024
Modified Files:
src/sys/dev/usb: uftdi.c
Log Message:
Add a match quirk to prevent matching any interface on SiPEED FPGA
development boards (e.g. Tang Nano 9K). The FT2232s on these boards
are wired
On Wed, Apr 24, 2024 at 11:59:18PM +, Zeng, Oak wrote:
> Hi Jason,
>
> I went through the conversation b/t you and Matt. I think we are pretty much
> aligned. Here is what I get from this threads:
>
> 1) hmm range fault size, gpu page table map size : you prefer big
On 4/24/24 15:47, Jakub Jelinek wrote:
On Wed, Apr 24, 2024 at 06:39:33PM -0400, Jason Merrill wrote:
--- gcc/cp/decl2.cc.jj 2024-04-23 14:49:41.933186265 +0200
+++ gcc/cp/decl2.cc 2024-04-24 15:17:09.043625729 +0200
@@ -3314,7 +3314,16 @@ tentative_decl_linkage (tree decl
> On Apr 24, 2024, at 3:54 PM, matthew green wrote:
>
> "Jonathan A. Kollasch" writes:
>> On Wed, Apr 24, 2024 at 05:51:32PM +0200, Paolo Pisati wrote:
>>> I'm slimming down a GENERIC i386 kernel[1] for an embedded board[2], when i
>>> discovered that turning off MULTIPROCESSOR, leads to:
>>
*/
maybe_make_one_only (decl);
?
Jason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114841
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason at gcc dot gnu.org
Target Milestone: ---
Created attachment 58029
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58029=edit
WIP patch against r8-7277-g515f874faf4562
In the 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114840
Jason Merrill changed:
What|Removed |Added
Alias||c++-ttp
Ever confirmed|0
++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason at gcc dot gnu.org
Target Milestone: ---
Meta-bug for issues with C++ template template parameters.
be, i.e. pp_take_prefix should call it instead of
directly setting NULL.
Some _take_ callers do set(NULL) and others don't; they should
definitely be consistent one way or the other.
David, what do you think?
Jason
take place in virtual
communities called servers".
If anyone out there can get some more information, feel free to post
it here in this thread!
I would be open to caravanning down there during Salt Lake Weekend if
the bird is still present and being seen on Saturday.
On Wed, Apr 24, 2024 at 2:1
the bird, where to
view, where to park, etc.
Coordinates I've been given are:
43.9635603, -95.3770522
If anyone who uses Facebook notices that there are sustained sightings
of this bird leading up to the weekend, please keep me informed via
email!
Thanks,
Jason Frank
Ortonville
General
I can fix without too much
risk.
Jason Szumlanski
Principal Solar Designer | Florida Solar Design Group
NABCEP Certified Solar Professional (PVIP)
Florida State Certified Solar Contractor CVC56956
Florida Certified Electrical Contractor EC13013208
On Wed, Apr 24, 2024 at 2:19 PM Dave Angelini Off
the different requirements of
> these specific classes in a single code path.
Which is back to my first thesis, this is all about trying to bolt on
an existing PTE scheme which is ill suited to the needs of SVA and
hmm_range_fault.
Jason
On Wed, Apr 24, 2024 at 04:35:17PM +, Matthew Brost wrote:
> On Wed, Apr 24, 2024 at 10:57:54AM -0300, Jason Gunthorpe wrote:
> > On Wed, Apr 24, 2024 at 02:31:36AM +, Matthew Brost wrote:
> >
> > > AMD seems to register notifiers on demand for parts of the ad
by recursively walking through inputs
and cargo-inputs for the package specs in a manifest/profile?
Jason
Module Name:src
Committed By: thorpej
Date: Wed Apr 24 14:41:13 UTC 2024
Modified Files:
src/sys/dev/goldfish: gfpic.c
Log Message:
Remove a superflouous printf().
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/sys/dev/goldfish/gfpic.c
Please note that
Module Name:src
Committed By: thorpej
Date: Wed Apr 24 14:41:13 UTC 2024
Modified Files:
src/sys/dev/goldfish: gfpic.c
Log Message:
Remove a superflouous printf().
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/sys/dev/goldfish/gfpic.c
Please note that
t32_t domid, int force)
{
int rc;
@@ -82,6 +92,32 @@ int main_unpause(int argc, char **argv)
return EXIT_SUCCESS;
}
+int main_suspendtoram(int argc, char **argv)
Maybe main_suspend_to_ram to be closer to the command line suspend-to-ram.
Thanks,
Jason
On 4/24/24 05:49, Patrick Palka wrote:
On Tue, 23 Apr 2024, Jason Merrill wrote:
On 4/23/24 11:28, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Is the test being run for multiple standard levels? I'd rather restrict it to
one and keep fully testing GC
f CPU VMAs.
That is something else. If you want to mess with migration during your
GPU fault path then fine that is some "migration module", but it
should have NOTHING to do with how hmm_range_fault() is invoked or how
the *SVA* flow operates.
You are mixing things up here, this thread is talking about
hmm_range_fault() and SVA.
migration is something that happens before doing the SVA mirroring
flows.
Jason
gt; migration.
I want to be very clear, there should be no interaction of your
hmm_range_fault based code with MM centric VMAs. You MUST NOT look up
the CPU vma_area_struct in your driver.
> It only need to dma-map the system memory pages and use
> them to fill RDMA page table. so RDMA don't need another memory
> manager such as our buddy. RDMA only deal with system memory which
> is completely struct page based management. Page by page make 100 %
> sense for RDMA.
I don't think this is the issue at hand, you just have some historical
poorly designed page table manipulation code from what I can
understand..
Jason
oad
should be pretty minimal.
I could use a separate 12V battery, but I would like to eliminate that cost
and complexity if possible.
And yeah, I am not considering this a money making opportunity. It's really
just a challenge to ward off boredom from the daily grind.
Jason Szumlanski
Princi
I made one small tweak: adding the name of the new "thin" SolrClient
to the relevant list item so readers can look it up more easily.
Otherwise the release notes look great!
On Tue, Apr 23, 2024 at 2:01 PM James Dyer wrote:
>
> For the second item, instead of "Solrj now offers async HTTP/2
>
Hi Maria,
Ok. I just saw this email which seemed late. If you applied, you will be
fully considered.
Jason
moorepants.info
+01 530-601-9791
On Wed, Apr 24, 2024 at 1:27 PM Марія Гартованець <
marisagartovan...@gmail.com> wrote:
> Dear Jason,
> I am so grateful for your reply!
>
they have overload protection, but what is the reset procedure?
Jason Szumlanski
Principal Solar Designer | Florida Solar Design Group
NABCEP Certified Solar Professional (PVIP)
Florida State Certified Solar Contractor CVC56956
Florida Certified Electrical Contractor EC13013208
[data:image/gif
Fortunately, the owner is pretty handy and is willing to live with any
negative consequences. That said, I want to offer him something as simple
and bulletproof as possible. I am walking into this with eyes wide open,
for sure.
Jason Szumlanski
Principal Solar Designer | Florida Solar Design
Dear Maria,
The submission period for applications is unfortunately already over.
Jason
moorepants.info
+01 530-601-9791
On Tue, Apr 23, 2024 at 9:25 PM Марія Гартованець <
marisagartovan...@gmail.com> wrote:
>
> *Dear community of Sympy,*
> I am interested into this *
On Wed, Apr 24, 2024 at 11:15 AM Cindy Lu wrote:
>
> On Wed, Apr 24, 2024 at 8:44 AM Jason Wang wrote:
> >
> > On Tue, Apr 23, 2024 at 4:42 PM Michael S. Tsirkin wrote:
> > >
> > > On Tue, Apr 23, 2024 at 11:09:59AM +0800, Jason Wang wrote:
> > >
Module Name:src
Committed By: thorpej
Date: Wed Apr 24 02:08:03 UTC 2024
Modified Files:
src/sys/kern: subr_vmem.c
Log Message:
vmem_init(): Ensure that the quantum is a power of 2, and that if private
tags are being used, they are added to the arena before the first span
Module Name:src
Committed By: thorpej
Date: Wed Apr 24 02:31:26 UTC 2024
Modified Files:
src/sys/dev/pci: btvmeii.c
Log Message:
b3_2706_map_vme(): Use VM_BESTFIT.
To generate a diff of this commit:
cvs rdiff -u -r1.27 -r1.28 src/sys/dev/pci/btvmeii.c
Please note that
Module Name:src
Committed By: thorpej
Date: Wed Apr 24 02:31:26 UTC 2024
Modified Files:
src/sys/dev/pci: btvmeii.c
Log Message:
b3_2706_map_vme(): Use VM_BESTFIT.
To generate a diff of this commit:
cvs rdiff -u -r1.27 -r1.28 src/sys/dev/pci/btvmeii.c
Please note that
Module Name:src
Committed By: thorpej
Date: Wed Apr 24 02:27:33 UTC 2024
Modified Files:
src/sys/dev/vme: vme.c
Log Message:
_vme_space_get(): Use VM_BESTFIT.
To generate a diff of this commit:
cvs rdiff -u -r1.30 -r1.31 src/sys/dev/vme/vme.c
Please note that diffs are
Module Name:src
Committed By: thorpej
Date: Wed Apr 24 02:27:33 UTC 2024
Modified Files:
src/sys/dev/vme: vme.c
Log Message:
_vme_space_get(): Use VM_BESTFIT.
To generate a diff of this commit:
cvs rdiff -u -r1.30 -r1.31 src/sys/dev/vme/vme.c
Please note that diffs are
Module Name:src
Committed By: thorpej
Date: Wed Apr 24 02:08:03 UTC 2024
Modified Files:
src/sys/kern: subr_vmem.c
Log Message:
vmem_init(): Ensure that the quantum is a power of 2, and that if private
tags are being used, they are added to the arena before the first span
On Tue, Apr 23, 2024 at 4:42 PM Michael S. Tsirkin wrote:
>
> On Tue, Apr 23, 2024 at 11:09:59AM +0800, Jason Wang wrote:
> > On Tue, Apr 23, 2024 at 4:05 AM Michael S. Tsirkin wrote:
> > >
> > > On Thu, Apr 18, 2024 at 08:57:51AM +0800, Jason Wang wrote:
> >
and not sure how to
size it.
Jason Szumlanski
Florida Solar Design Group
___
List sponsored by Redwood Alliance
Pay optional member dues here: http://re-wrenches.org
List Address: RE-wrenches@lists.re-wrenches.org
Change listserver email address & sett
On 4/23/24 11:28, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Is the test being run for multiple standard levels? I'd rather restrict
it to one and keep fully testing GC-safety.
-- >8 --
The below testcase uses --param=ggc-min-expand=0 which forces a
On Tue, 23 Apr 2024 16:08:13 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 164:
>>
>>> 162: public void writeTo(OutputStream out) throws IOException {
>>> 163: if (Thread.currentThread().isVirtual()) {
>>> 164:
ady deduced. */
+ if (undeduced_auto_decl (existing) && !undeduced_auto_decl (decl))
+ TREE_TYPE (existing) = change_return_type (TREE_TYPE (d_type), e_type);
Perhaps this should dump a note like the noexcept merge does? OK either
way.
Jason
ing-xfinity-xfi-advanced-security)
and maintains a site to report these sorts of issues
(https://www.xfinity.com/support/articles/report-blocked-website).
Jason
On 4/21/24 19:59, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
This fixes a null dereference issue when decl_specifiers.type is not yet
provided.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_parameter_declaration): Check if
On Tue, Apr 23, 2024 at 7:57 PM Simon Horman wrote:
>
> On Tue, Apr 23, 2024 at 10:17:31AM +0800, Jason Xing wrote:
> > On Tue, Apr 23, 2024 at 10:14 AM Jason Xing
> > wrote:
> > >
> > > Hi Simon,
> > >
> > > On Tue, Apr 23, 2024 at 2:28
On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since
Hello Matthieu,
On Tue, Apr 23, 2024 at 6:02 PM Matthieu Baerts wrote:
>
> Hi Jason,
>
> On 23/04/2024 09:21, Jason Xing wrote:
> > From: Jason Xing
> >
> > It relys on what reset options in the skb are as rfc8684 says. Reusing
>
> (if you have something els
From: Jason Xing
At last, we should let it work by introducing this reset reason in
trace world.
One of the possible expected outputs is:
... tcp_send_reset: skbaddr=xxx skaddr=xxx src=xxx dest=xxx
state=TCP_ESTABLISHED reason=NOT_SPECIFIED
Signed-off-by: Jason Xing
Reviewed-by: Steven
From: Jason Xing
Since we have mapped every mptcp reset reason definition in enum
sk_rst_reason, introducing a new helper can cover some missing places
where we have already set the subflow->reset_reason.
Note: using SK_RST_REASON_NOT_SPECIFIED is the same as
SK_RST_REASON_MPTCP_RST_EUNS
From: Jason Xing
It relys on what reset options in the skb are as rfc8684 says. Reusing
this logic can save us much energy. This patch replaces most of the prior
NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/mptcp/protocol.h | 28
net/mptcp/subflow.c
From: Jason Xing
Reuse the dropreason logic to show the exact reason of tcp reset,
so we can finally display the corresponding item in enum sk_reset_reason
instead of reinventing new reset reasons. This patch replaces all
the prior NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
include
From: Jason Xing
Like what we did to passive reset:
only passing possible reset reason in each active reset path.
No functional changes.
Signed-off-by: Jason Xing
---
include/net/tcp.h | 3 ++-
net/ipv4/tcp.c| 15 ++-
net/ipv4/tcp_output.c | 3 ++-
net/ipv4
From: Jason Xing
Add a new standalone file for the easy future extension to support
both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
This patch only does the preparations for reset reason mechanism,
nothing else changes.
The reset reasons are divided into three parts:
1
From: Jason Xing
Adjust the parameter and support passing reason of reset which
is for now NOT_SPECIFIED. No functional changes.
Signed-off-by: Jason Xing
---
include/net/request_sock.h | 4 +++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c| 10 ++
net/dccp
From: Jason Xing
In production, there are so many cases about why the RST skb is sent but
we don't have a very convenient/fast method to detect the exact underlying
reasons.
RST is implemented in two kinds: passive kind (like tcp_v4_send_reset())
and active kind (like tcp_send_active_reset
On Mon, Apr 22, 2024 at 11:24 PM Tom Tromey wrote:
> Jason> Someone mentioned earlier that gerrit was previously tried
> Jason> unsuccessfully.
>
> We tried it and gdb and then abandoned it. We tried to integrate it
> into the traditional gdb development style, having i
On 4/21/24 19:59, Patrick Palka wrote:
On Sat, 20 Apr 2024, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
A class allocation member function is implicitly 'static' by
[class.free] p3, so cannot have an explicit object parameter.
PR
nodes for
something that might not be needed later on at all), so maybe_clone_body
clones the bodies, but doesn't make them as aliases.
Hmm, cloning the bodies and then discarding them later seems like more
extra work than creating the cgraph nodes.
Jason
On Tue, Apr 23, 2024 at 4:05 AM Michael S. Tsirkin wrote:
>
> On Thu, Apr 18, 2024 at 08:57:51AM +0800, Jason Wang wrote:
> > On Wed, Apr 17, 2024 at 5:29 PM Michael S. Tsirkin wrote:
> > >
> > > On Fri, Apr 12, 2024 at 09:28:23PM +0800, Cindy Lu w
On 4/22/24 08:54, Jakub Jelinek wrote:
Hi!
The following testcase is rejected with
error: inlining failed in call to 'always_inline' '...': call is unlikely and
code size would grow
errors. The problem is that starting with the r14-2149 change
we try to copy most of the attributes from the
On 4/22/24 15:18, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/13/12?
OK with a rationale comment.
-- >8 --
The object/offset canonicalization performed in cxx_fold_indirect_ref
is undesirable for union member accesses because it loses
logy; people are more or less
comfortable with their current workflow and uninclined to experiment with
someone else's new thing, even if it could eventually be a big improvement.
I think that the office hours, for both sourceware and the toolchain, offer
a better path for building enthusiasm about a new direction.
Is gerrit still installed?
Jason
On Mon, Apr 22, 2024 at 11:11 AM Anthony PERARD
wrote:
>
> On Sun, Apr 07, 2024 at 04:49:51PM -0400, Jason Andryuk wrote:
> > diff --git a/tools/hotplug/Linux/block-tap b/tools/hotplug/Linux/block-tap
> > index 89247921b9..126e472786 100755
> > --- a/tools/hotplug/Linux/b
On Tue, Apr 23, 2024 at 10:14 AM Jason Xing wrote:
>
> Hi Simon,
>
> On Tue, Apr 23, 2024 at 2:28 AM Simon Horman wrote:
> >
> > On Mon, Apr 22, 2024 at 11:01:03AM +0800, Jason Xing wrote:
> >
> > ...
> >
> > > diff --git
Hi Simon,
On Tue, Apr 23, 2024 at 2:28 AM Simon Horman wrote:
>
> On Mon, Apr 22, 2024 at 11:01:03AM +0800, Jason Xing wrote:
>
> ...
>
> > diff --git a/include/net/rstreason.h b/include/net/rstreason.h
>
> ...
>
> > +/**
> > + * There are three parts
This isn't a vote at all, but here's my +1. It'll be great to be more current
with Quarkus.
On 2024/04/19 19:01:47 Alex Porcelli wrote:
> I have been exploring the possibility of upgrading Quarkus to the
> latest LTS version, 3.8.x, as the current 3.2.x version is nearing the
> end of its
: meet.google.com/rju-vqau-gqt
Meetup.com:
https://www.meetup.com/apache-solr-virtual-community-meetups/events/300577073
On Mon, Apr 22, 2024 at 2:49 PM Jason Gerlowski wrote:
>
> Alright, I'm happy to volunteer for April.
>
> Pending any more input on "when", let's shoot for Monda
of recent meetings so it seems like a
safe choice unless someone says otherwise.)
I'll create the Meeting Notes page and send out announcements in
Slack, etc. shortly.
On Fri, Apr 19, 2024 at 7:56 AM Eric Pugh
wrote:
>
> I vote for 26th, or 29 or 30 ;-)
>
>
> > On Apr 17, 2024,
https://github.com/jasonmolenda approved this pull request.
Yes please, very long overdue, I've felt bad about not trying to do something
here myself.
https://github.com/llvm/llvm-project/pull/89587
___
lldb-commits mailing list
Thanks Jose. +1. Great KIP!
On Fri, Mar 29, 2024 at 11:16 AM Jun Rao wrote:
> Hi, Jose,
>
> Thanks for the KIP. +1
>
> Jun
>
> On Fri, Mar 29, 2024 at 9:55 AM José Armando García Sancio
> wrote:
>
> > Hi all,
> >
> > I would like to call a vote to adopt KIP-853.
> >
> > KIP:
CVSROOT:/cvs
Module name:src
Changes by: j...@cvs.openbsd.org2024/04/22 08:16:14
Modified files:
usr.bin/newsyslog: newsyslog.8
Log message:
mark the "signal" field as optional; from alvar penning
ok millert
Thanks all for the kind words, and thanks especially to David for
serving this past year!
On Fri, Apr 19, 2024 at 9:00 AM Anshum Gupta wrote:
>
> Thank you for your effort, David!
>
> Congratulations, Jason!
>
> On Thu, Apr 18, 2024 at 7:47 PM David Smiley wrote:
>
> &
[
https://issues.apache.org/jira/browse/SOLR-17066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski resolved SOLR-17066.
Fix Version/s: 9.5
Assignee: Jason Gerlowski
Resolution: Fixed
Closing
[
https://issues.apache.org/jira/browse/SOLR-17234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839647#comment-17839647
]
Jason Gerlowski commented on SOLR-17234:
Hey [~jdyer] - I believe I introduced this, and I can
Hello Matthieu,
On Mon, Apr 22, 2024 at 4:47 PM Matthieu Baerts wrote:
>
> Hi Jason,
>
> On 22/04/2024 05:01, Jason Xing wrote:
> > From: Jason Xing
> >
> > Add a new standalone file for the easy future extension to support
> > both active reset and passive r
From: Jason Xing
At last, we should let it work by introducing this reset reason in
trace world.
One of the possible expected outputs is:
... tcp_send_reset: skbaddr=xxx skaddr=xxx src=xxx dest=xxx
state=TCP_ESTABLISHED reason=NOT_SPECIFIED
Signed-off-by: Jason Xing
Reviewed-by: Steven
From: Jason Xing
Since we have mapped every mptcp reset reason definition in enum
sk_rst_reason, introducing a new helper can cover some missing places
where we have already set the subflow->reset_reason.
Note: using SK_RST_REASON_NOT_SPECIFIED is the same as
SK_RST_REASON_MPTCP_RST_EUNS
From: Jason Xing
It relys on what reset options in the skb are as rfc8684 says. Reusing
this logic can save us much energy. This patch replaces most of the prior
NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/mptcp/subflow.c | 22 +-
1 file changed, 17 insertions
From: Jason Xing
Reuse the dropreason logic to show the exact reason of tcp reset,
so we can finally display the corresponding item in enum sk_reset_reason
instead of reinventing new reset reasons. This patch replaces all
the prior NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/ipv4
From: Jason Xing
Like what we did to passive reset:
only passing possible reset reason in each active reset path.
No functional changes.
Signed-off-by: Jason Xing
---
include/net/tcp.h | 3 ++-
net/ipv4/tcp.c| 15 ++-
net/ipv4/tcp_output.c | 3 ++-
net/ipv4
From: Jason Xing
Adjust the parameter and support passing reason of reset which
is for now NOT_SPECIFIED. No functional changes.
Signed-off-by: Jason Xing
---
include/net/request_sock.h | 4 +++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c| 10 ++
net/dccp
From: Jason Xing
In production, there are so many cases about why the RST skb is sent but
we don't have a very convenient/fast method to detect the exact underlying
reasons.
RST is implemented in two kinds: passive kind (like tcp_v4_send_reset())
and active kind (like tcp_send_active_reset
From: Jason Xing
Add a new standalone file for the easy future extension to support
both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
This patch only does the preparations for reset reason mechanism,
nothing else changes.
The reset reasons are divided into three parts:
1
Hi Dmitry,
On Thu, Mar 28, 2024 at 2:05 PM Dmitry Torokhov
wrote:
>
> Hi Jason,
>
> On Wed, Mar 20, 2024 at 01:42:27PM -0400, Jason Andryuk wrote:
> > Hi Dmitry,
> >
> > Do you have any feedback, or can you pick up this patch? It solves a
> > real issue affe
the files from
each package output.
On the surface option (b) seems cleaner, but maybe you had a
reason for generating the index contents during the build?
Jason
Hello Steven,
On Sat, Apr 20, 2024 at 10:36 AM Steven Rostedt wrote:
>
> On Fri, 19 Apr 2024 16:00:20 +0800
> Jason Xing wrote:
>
> > If other experts see this thread, please help me. I would appreciate
> > it. I have strong interests and feel strong responsibility to
CVSROOT:/cvs
Module name:src
Changes by: j...@cvs.openbsd.org2024/04/19 13:16:26
Modified files:
usr.sbin/dhcpd : dhcpd.8
Log message:
replace a (technically incorrect) instance of "IP" with "address";
issue reported by tech3599 at posteo net via henning;
discussed
On 2024-04-19 13:53, Jason Yip wrote:
On 2024-04-19 12:51, Colin Campbell - cpkc.music(a)shaw.ca wrote:
I see that developers have branches on gitlab, showing as >
origin/dev//username/; I gather that this is The Way It's Done®, but I
can't find direction in CG as to how to cre
am" with `git remote set-url
--push upstream NULL`.
--
- Jason Yip
I was the user who ported KitchenSink to NetRexx.
I still consider Pivot as the best GUI for Java.
Looking forward to final release.
Roger, enjoy your retirement and thank you for your hard work on Pivot
Sent with [Proton Mail](https://proton.me/) secure email.
1 - 100 of 425531 matches
Mail list logo
