search for: reflow

The control flow was: if (!y) { ppix = ... } if (y) { ... } else if (x) { use ppix for something } else { use ppix for something } Merge the if(!y) block with the two else branches. This avoids a false-positive in the clang static analyzer, it can't know that !y and x are mutually exclusive. The result looks something like this: if (y) { ... } else { ppix = ... if (x) {

Yeah, my issue with Option 2 was that it doesn't reflow. We could get the same side-by-side effect while allowing reflow on smaller screens using CSS flexbox or grid, but I don't know how to do that in asciidoc. Sometimes sites just hand-craft the HTML of the landing page, but I don't want to make work for people. Also, we should consider how we...

...? I heard somewhere that $target does not need to be used with static probes but the probes don''t show up unless Firefox is running and then only as mozillaNNNNN, i.e. mozilla$target. Thanks, Joel --- BEGIN { self->ts = 0; self->vts = 0; } mozilla$target:::process-xul-reflow-entry { self->ts = timestamp; self->vts = vtimestamp; self->roots = arg0; } mozilla$target:::process-xul-reflow-return /self->ts/ { this->ts = timestamp - self->ts; this->vts = vtimestamp - self->vts; printf("\n"); printf("# roots: %u\n&...

...> IMHO, the trivial trailing-space cleanup could be included in the same > commit too, instead of adding an additional commit just for it. That > is, if there is no additional correction / improvement required. I think it is a good thing to just accept a patch that is good enough and do reflow work in an additional patch. I see several advantages: * a clear signal of "patch accepted" * making visible how a patch is made better * no merge conflict for those who have the original patch applied Groeten Geert Stappers -- Leven en laten leven

..., > > const struct mmu_notifier_range *range, > > unsigned long cur_seq); > > Yes it is sorry, i got confuse with mmu_range_notifier and mmu_notifier_range :) > It is almost a palyndrome structure ;) Lets change the name then, this is clearly not working. I'll reflow everything tomorrow Jason

Instead of mixing printk and pr_<level> forms, just use pr_<level> Miscellaneous changes around these conversions: Add a missing newline to avoid message interleaving, coalesce formats, reflow modified lines to 80 columns. Signed-off-by: Joe Perches <joe at perches.com> --- drivers/net/xen-netback/netback.c | 7 +++---- drivers/net/xen-netfront.c | 28 +++++++++++++--------------- 2 files changed, 16 insertions(+), 19 deletions(-) diff --git a/drivers/net/xen-netback/net...

Instead of mixing printk and pr_<level> forms, just use pr_<level> Miscellaneous changes around these conversions: Add a missing newline to avoid message interleaving, coalesce formats, reflow modified lines to 80 columns. Signed-off-by: Joe Perches <joe at perches.com> --- drivers/net/xen-netback/netback.c | 7 +++---- drivers/net/xen-netfront.c | 28 +++++++++++++--------------- 2 files changed, 16 insertions(+), 19 deletions(-) diff --git a/drivers/net/xen-netback/net...

Instead of mixing printk and pr_<level> forms, just use pr_<level> Miscellaneous changes around these conversions: Add a missing newline to avoid message interleaving, coalesce formats, reflow modified lines to 80 columns. Signed-off-by: Joe Perches <joe at perches.com> --- drivers/net/xen-netback/netback.c | 7 +++---- drivers/net/xen-netfront.c | 28 +++++++++++++--------------- 2 files changed, 16 insertions(+), 19 deletions(-) diff --git a/drivers/net/xen-netback/net...

...ci_transport.c. This is risky since the value could be changed in one file and the other would be out of sync. Rename from SS_LISTEN to VSOCK_SS_LISTEN since the constant is not part of enum socket_state (SS_CONNECTED, ...). This way it is clear that the constant is vsock-specific. The big text reflow in af_vsock.c was necessary to keep to the maximum line length. Text is unchanged except for s/SS_LISTEN/VSOCK_SS_LISTEN/. Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> --- include/net/af_vsock.h | 3 +++ net/vmw_vsock/af_vsock.c | 37 ++++++++++++++++++------------...

Hi all, while Option 2 was my favorite as well and it looks great on wide screens, one concern is that it might not look as good on mobile devices. Since we had a sync-up call with Shaun last week, we added Option 4 which shows collapsible docs lists and categories under each major version. Hope that helps, Tomas On Fri, Mar 25, 2022 at 7:52 PM Amy Marrich <amy at redhat.com> wrote:

...ci_transport.c. This is risky since the value could be changed in one file and the other would be out of sync. Rename from SS_LISTEN to VSOCK_SS_LISTEN since the constant is not part of enum socket_state (SS_CONNECTED, ...). This way it is clear that the constant is vsock-specific. The big text reflow in af_vsock.c was necessary to keep to the maximum line length. Text is unchanged except for s/SS_LISTEN/VSOCK_SS_LISTEN/. Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> --- include/net/af_vsock.h | 3 +++ net/vmw_vsock/af_vsock.c | 37 ++++++++++++++++++------------...

...279). * A number of new intrinsics for constrained floating point operations have been added. [r293226](http://reviews.llvm.org/rL293226). ## Clang commits * A new TableGen-based generator for command line argument documentation was added. [r292968](http://reviews.llvm.org/rL292968). * Comment reflowing has been implemented for clang-format. [r293055](http://reviews.llvm.org/rL293055). ## Other project commits * XRay 'Flight Data Recorder' mode was implemented, which allows XRay to log in-memory and then write out data on-demand as required. [r293015](http://reviews.llvm.org/rL293015...

...t; > > > unsigned long cur_seq); > > > > > > Yes it is sorry, i got confuse with mmu_range_notifier and mmu_notifier_range :) > > > It is almost a palyndrome structure ;) > > > > Lets change the name then, this is clearly not working. I'll reflow > > everything tomorrow > > Semantic patch to do that run from your linux kernel directory with your patch > applied (you can run it one patch after the other and the git commit -a --fixup HEAD) > > spatch --sp-file name-of-the-file-below --dir . --all-includes --in-place &gt...

...mmu_notifier_range *range, > > > unsigned long cur_seq); > > > > Yes it is sorry, i got confuse with mmu_range_notifier and mmu_notifier_range :) > > It is almost a palyndrome structure ;) > > Lets change the name then, this is clearly not working. I'll reflow > everything tomorrow Semantic patch to do that run from your linux kernel directory with your patch applied (you can run it one patch after the other and the git commit -a --fixup HEAD) spatch --sp-file name-of-the-file-below --dir . --all-includes --in-place %< --------------------------...

...us devices. Eric Engestrom (6): xf86drmHash: remove unused loop variable meson: fix typo in compiler flag tests: skip drmdevice test if the machine doesn't have any drm device freedreno: remove always-defined #ifdef xf86atomic: #undef internal define README: reflow the project description to improve readability François Tigeot (2): xf86drm: implement drmParseSubsystemType for DragonFly libdrm: Use DRM_IOCTL_GET_PCIINFO on DragonFly Leo Liu (1): tests/amdgpu/vcn: fix the nop command in IBs Lucas De Marchi (2): gitignore: sort file...

...al trailing-space cleanup could be included in the same >> commit too, instead of adding an additional commit just for it. That >> is, if there is no additional correction / improvement required. > > I think it is a good thing to just accept a patch that is good enough > and do reflow work in an additional patch. > > I see several advantages: > > * a clear signal of "patch accepted" > * making visible how a patch is made better > * no merge conflict for those who have the original patch applied > > > Groeten > Geert Stappers > -- &gt...

...eanup could be included in the same >>> commit too, instead of adding an additional commit just for it. That >>> is, if there is no additional correction / improvement required. >> >> I think it is a good thing to just accept a patch that is good enough >> and do reflow work in an additional patch. >> >> I see several advantages: >> >> * a clear signal of "patch accepted" >> * making visible how a patch is made better >> * no merge conflict for those who have the original patch applied >> >> >> Gro...

...Provisioning Tool > menu INCLUDE pxelinux.cfg/graphics.conf > MENU AUTOBOOT Starting Local System in # seconds > MENU BACKGROUND splash.jpg > > label bootlocal > menu label ^Boot This Host > menu default > localboot 0 > timeout 80 Reflowing for clarity of scope: default vesamenu.c32 prompt 0 timeout 80 menu title Host Provisioning Tool menu INCLUDE pxelinux.cfg/graphics.conf MENU AUTOBOOT Starting Local System in # seconds MENU BACKGROUND splash.jpg label bootlocal menu label ^Boot This Host menu default localboot 0...

From: Geert Stappers <stappers at nero.gpm.stappers.nl> They were introduced by the patch for ELF64 support. --- com32/mboot/map.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/com32/mboot/map.c b/com32/mboot/map.c index 2e8641f..1992f14 100644 --- a/com32/mboot/map.c +++ b/com32/mboot/map.c @@ -281,7 +281,7 @@ struct multiboot_header *map_image(void *ptr, size_t

Hello All, this is my first post so I'll try to be as verbose as possible. We have a PXE deployment server serving mostly fujitsu RX300 rack mount servers with Intel 82575EB Gigabit Ethernet Controllers onboard. I recently upgraded from version 4.07 to version 6.02 and, without making any edits to my default menu, immediately noticed a regression. I use vesamenu.c32 to present a menu to the