Re: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v15]

[Alan Bateman]

On Tue, 11 Jun 2024 21:05:38 GMT, Inigo Mediavilla Saiz  
wrote:

>> Print the stack traces of mounted virtual threads when calling `jcmd  
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Require continuations to run the test

test/hotspot/jtreg/serviceability/dcmd/thread/PrintMountedVirtualThread.java 
line 54:

> 52: output.shouldMatch(".*at " + 
> Pattern.quote(DummyRunnable.class.getName()) + "\\.compute.*");
> 53: output.shouldMatch("Mounted virtual thread " + "\"Dummy 
> Vthread\"" + " #" + vthread.threadId());
> 54: shouldFinish.set(true);

One other suggestion is to use a try-finally block here. Put L48-53 in the 
block and set shouldFinish in the finally block. That way if the test fails 
then it won't leave a spinning thread to disrupt the next test that runs in the 
agent VM.

Also just to say that we've mostly used JUnit for new tests in recent releases, 
moving away from TestNG for new tests.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1635872465

Re: Bluetooth advertising broken on ESP32

[Alan C. Assis]

Hi Robert,

Nice to know you are interested in improving Bluetooth support on NuttX.

Last time I tested it (more than 1 year) it was working fine to scan for
devices, but I never tried to advertise from the board and connect.

I think NuttX needs some Bluetooth demo for advertising and sending data,
like a temperature sensor, etc.

Best Regards,

Alan

On Tue, Jun 11, 2024 at 4:23 PM Robert-Alexandru COMAN (110095) <
robert.coman1...@stud.acs.upb.ro> wrote:

> Hi all,
>
> I am looking into contributing to enhance the Bluetooth stack on Nuttx. I
> have begun testing the BLE stack in order to familiarize myself with it.
> For that, I am using the ESP32-DevKitC development board with the
> esp32-devkitc configuration loaded.
>
> The problem I encountered is that the advertising of packets is broken (at
> least on ESP32). I am unable to detect any advertising packets being sent,
> thus I am unable to pair the device running Nuttx with any other device.
>
> I tried to investigate the issue by printing byte by byte the HCI packets
> sent by the host to the controller and the responses received, hoping to
> maybe discover some fault in the initialization of the controller or in the
> enabling of the advertising process. From the logs, it seems that
> everything is fine; for each command that is sent, there is a response with
> a 'success' return code. In theory, this means that advertising should
> work, but in my case, it does not. I also tried different values for the
> advertising parameters, but to no avail.
>
> I am using my smartphone as a way to sniff the advertising packets from
> the BLE stack and I found the following: on some occasions, in around 1 out
> of 10 system boots, right after the BLE stack is initialized and
> advertising enabled by default, I receive only one advertising packet.
> After that, advertising seems to stop because I am not seeing other
> advertising packets being sent after that. Apart from that, in the majority
> of system boots, no advertising packets are seen at all.
>
> Firstly, I would like to know if this issue has been encountered with
> other development boards as well. Does advertising work with other boards
> or is it just an esp32 related issue? This might help to narrow down the
> problem. Secondly, I would like to know if anyone has successfully tested
> BLE on the ESP32 in the past (with a different version of NuttX) and
> encountered no issues. Do you think it is a driver issue, a linker issue,
> or something else further up in the stack?
>
> I am looking forward to hearing from you and would appreciate any
> assistance in resolving this issue.
>
> Best regards,
> Robert
>

Re: RFR: 8327793: Deprecate jstatd for removal [v4]

[Alan Bateman]

On Tue, 11 Jun 2024 18:11:55 GMT, Kevin Walls  wrote:

>> jstatd is an RMI server application which monitors HotSpot VMs, and provides 
>> an interface to the monitoring tool jstat, for use across a remote RMI 
>> connection.
>> 
>> RMI is not how modern applications communicate. It is an old transport with 
>> long term security concerns, and configuration difficulties with firewalls.
>> 
>> The jstatd tool should be removed. Deprecating and removing jstatd will not 
>> affect usage of jstat for monitoring local VMs using the Attach API.
>
> Kevin Walls has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Remove annotations

Changes look okay now. Will you update the CSR to align with the PR?

src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java line 84:

> 82: 
> 83: System.err.println("Warning: jstatd is deprecated for removal in 
> a future release.");
> 84: 

I think we've put "WARNING" in caps in other usages.

-

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19658#pullrequestreview-2111296929
PR Review Comment: https://git.openjdk.org/jdk/pull/19658#discussion_r1635388247

Re: RFR: 8327793: Deprecate jstatd for removal [v4]

[Alan Bateman]

On Tue, 11 Jun 2024 18:11:55 GMT, Kevin Walls  wrote:

>> jstatd is an RMI server application which monitors HotSpot VMs, and provides 
>> an interface to the monitoring tool jstat, for use across a remote RMI 
>> connection.
>> 
>> RMI is not how modern applications communicate. It is an old transport with 
>> long term security concerns, and configuration difficulties with firewalls.
>> 
>> The jstatd tool should be removed. Deprecating and removing jstatd will not 
>> affect usage of jstat for monitoring local VMs using the Attach API.
>
> Kevin Walls has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Remove annotations

Changes look okay now. Will you update the CSR to align with the PR?

src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java line 84:

> 82: 
> 83: System.err.println("Warning: jstatd is deprecated for removal in 
> a future release.");
> 84: 

I think we've put "WARNING" in caps in other usages.

-

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19658#pullrequestreview-2111296929
PR Review Comment: https://git.openjdk.org/jdk/pull/19658#discussion_r1635388247

Re: RFR: 8334036: Update JCov for class file version 68

[Alan Bateman]

On Tue, 11 Jun 2024 19:02:29 GMT, Alexandre Iline  
wrote:

> Update JCov for class file version 68

Marked as reviewed by alanb (Reviewer).

-

PR Review: https://git.openjdk.org/jdk/pull/19665#pullrequestreview-2111285609

[blink-dev] Intent to Experiment: WebGPU Subgroups experimentation

['Alan Baker' via blink-dev]

Contact emailsalanba...@google.com

Explainerhttps://github.com/gpuweb/gpuweb/blob/main/proposals/subgroups.md

SpecificationNone

Summary

Adds subgroup functionality to WebGPU. Subgroup operations perform SIMT
operations to provide efficient communication and data sharing among groups
of invocations. These operations can be used to accelerate applications by
reducing memory overheads incurred by inter-invocation communication.


Blink componentBlink>WebGPU


TAG reviewNone

TAG review statusPending

Risks


Interoperability and Compatibility

None


*Gecko*: No signal

*WebKit*: No signal

*Web developers*: No signals

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None


Goals for experimentation

We wish to more broadly test portability, performance, and reach beyond our
accessible test devices. We have partners that could leverage these
features in existing products to provide feedback. For example, Mediapipe
would be able to leverage this feature easily.

We also wish to gather feedback to help shape the API and answer the
following questions:
* Which parts are essential?
* What additions would make a meaningful impact?
* Can we mitigate non-portable behaviours for common usages?

Ongoing technical constraints

None


Debuggability

None


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, ChromeOS, Android, and Android WebView)?No

Is this feature fully tested by web-platform-tests

?No

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5126409856221184

This intent message was generated by Chrome Platform Status
.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg%2BrB7%2B-cAZNO-mckZ%2BaK8D0ZPZ4iJYi1kmU%2Bt60i%3DFzvL-gw%40mail.gmail.com.

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

[Alan Bateman]

On 11/06/2024 18:19, David Lloyd wrote:

:

I thought that might be where Alan was headed with this. I would 
support this solution; it would solve the problem for conformant 
serialization libraries. If a class has a `readObject`/etc. then we 
use it - we wouldn't care if it was "natural" or generated. This also 
gives us the option to allow the user to use `opens` selectively to 
opt-in to special optimizations, without a major penalty if they do not.


Is there already someone assigned for this task


Not to my knowledge so you have cycles to prototype and have these 
methods return a MH that work like a "default" readObject/writeObject 
then it would help the discussion.


-Alan

Re: RFR: 8327793: Deprecate jstatd for removal [v2]

[Alan Bateman]

On Tue, 11 Jun 2024 16:54:36 GMT, Kevin Walls  wrote:

>> jstatd is an RMI server application which monitors HotSpot VMs, and provides 
>> an interface to the monitoring tool jstat, for use across a remote RMI 
>> connection.
>> 
>> RMI is not how modern applications communicate. It is an old transport with 
>> long term security concerns, and configuration difficulties with firewalls.
>> 
>> The jstatd tool should be removed. Deprecating and removing jstatd will not 
>> affect usage of jstat for monitoring local VMs using the Attach API.
>
> Kevin Walls has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   No annotations for src/jdk.jstatd/share/classes/sun/jvmstat/monitor/remote

BTW: Are you going to include the update to the man page (jstatd.1) in the PR 
or is that for another update?

-

PR Comment: https://git.openjdk.org/jdk/pull/19658#issuecomment-2161239976

Re: RFR: 8327793: Deprecate jstatd for removal [v2]

[Alan Bateman]

On Tue, 11 Jun 2024 16:54:36 GMT, Kevin Walls  wrote:

>> jstatd is an RMI server application which monitors HotSpot VMs, and provides 
>> an interface to the monitoring tool jstat, for use across a remote RMI 
>> connection.
>> 
>> RMI is not how modern applications communicate. It is an old transport with 
>> long term security concerns, and configuration difficulties with firewalls.
>> 
>> The jstatd tool should be removed. Deprecating and removing jstatd will not 
>> affect usage of jstat for monitoring local VMs using the Attach API.
>
> Kevin Walls has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   No annotations for src/jdk.jstatd/share/classes/sun/jvmstat/monitor/remote

BTW: Are you going to include the update to the man page (jstatd.1) in the PR 
or is that for another update?

-

PR Comment: https://git.openjdk.org/jdk/pull/19658#issuecomment-2161239976

Re: RFR: 8327793: Deprecate jstatd for removal

[Alan Bateman]

On Tue, 11 Jun 2024 16:52:13 GMT, Kevin Walls  wrote:

> Sure, happy to not add annotations in sun.jvmstat.monitor.remote 
> (RemoteHost.java, RemoteVm.java).

Right, you can drop it from all the source files except for module-info.java.

-

PR Comment: https://git.openjdk.org/jdk/pull/19658#issuecomment-2161219889

Re: RFR: 8327793: Deprecate jstatd for removal

[Alan Bateman]

On Tue, 11 Jun 2024 16:52:13 GMT, Kevin Walls  wrote:

> Sure, happy to not add annotations in sun.jvmstat.monitor.remote 
> (RemoteHost.java, RemoteVm.java).

Right, you can drop it from all the source files except for module-info.java.

-

PR Comment: https://git.openjdk.org/jdk/pull/19658#issuecomment-2161219889

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

[Alan Bateman]

On 11/06/2024 17:27, David Lloyd wrote:

:

Yes, all of the method-access methods on ReflectionFactory are used, 
not just for readObject/writeObject but also readObjectNoData, 
readResolve, and writeReplace, the constructor accessors, and the 
factory methods for OptionalDataException. We don't use the static 
initializer one though (maybe the ORB does, I'm not sure).


Okay, next question is whether you are also using Unsafe to access the 
fields of classes where you've got a MH to invoke the readXXX/writeXXX 
methods? Ignore SVUID for the moment.


-Alan.

[NetBehaviour] Improvisation on Afghani Rubab

[Alan Sondheim via NetBehaviour]

Improvisation on Afghani Rubab

https://youtu.be/6X58UCa0k8w video

very old afghan rubab, the lunar instrument to play, the
ancestor of the sarod, and my rubab is rubab is beautifully
described and played by the ethnomusicology music, difference
between rubab and rebab, issues of Japanese tuning and retuning
rubab, and thinking about 'amenable,' this rubab with noise
reduction in no discernible order, the girt steel of the
modulated rubab, rubab rebake Kebara jabbled webboard webcam
cyber Cybermind rebab, rubab, should be played with a pick, not
fingernails inv-dyn why today, kay, graphics above, oddly,
recorded rubab, rubab6jpg rubabdemojpg rubbavi rubbbmov
rubbingtheskinMOV deathcamp say,rubab babur ranul closeness
catatonic Stopped hasapi. Providence, bit later; miniature
Afghan rubab (hardly instrumentality aside playable hasapi
miniature afghan rubab rookery rosie rosin rotifera RSS rubab
says the rubab sarangi, down antique history. Most rubab, Rubab
rubab, Decorated, piano sarangi, rubab near rubab sarangi, piano
Decorated, Clark Rubab please Rubab again Most with rubab, i
happened today, in in why today, again Rubab rubab, Decorated,
piano sarangi, rubab near Pentagon - the rubab sarangi, piano
Decorated, Rubab please Rubab antique history. Most with rubab,
i happened today, in in in why today, again Rubab rubab,
Decorated, piano sarangi, rubab near Pentagon rubab or rebab
(Afghani). I improvise on these, always thinking amazing and
prescient, rubab leading to sarod for example. So most likely
19th-century French, the rubab is undecorated and maybe rubab is
the real name - seems different - lost again Afghani rebab or
rubab for example, as opposed to one spike and rubab rubab to
live another day if not the Spikes the rubab dear book for me,
for identification.) Accompanied by Afghani rubab playing, but
playing the rubab my own way, with respect. And at it. it's
harder than guitar, harder than rubab for me. rubab rubab as I
mentioned, is difficult for me; it's designed for piece up (I
hadn't touched the rubab for a while and felt rubab, taciturn,
unbearably old, remaining near the lower, the instrumentality
aside playable hasapi miniature afghan rubab hasapi.


__

___
NetBehaviour mailing list
NetBehaviour@lists.netbehaviour.org
https://lists.netbehaviour.org/mailman/listinfo/netbehaviour

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

[Alan Bateman]

On 06/06/2024 18:37, David Lloyd wrote:
Just bumping this one more time. I intend to start by opening a JIRA 
to add the two proposed methods to `ReflectionFactory`, and go from 
there. I guess that we might need a JEP for the proposed serialization 
restrictions, which is going to be considerably more involved, so I'm 
putting that off as a second step for now, pending further discussion.




I don't think the JDK should be adding another backdoor for 
serialization libs to do deep reflection.


I'm curious, does your serialization library uses the ReflectionFactory 
to get method handles to the readObject/writeObject methods (if they are 
defined)?


-Alan

[webkit-changes] [WebKit/WebKit] e86dfb: Move RenderElement::checkForRepaintDuringLayout to...

[Alan Baradlay]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e86dfb0a3cd022ceb447f40207b537b5b4eec922
  
https://github.com/WebKit/WebKit/commit/e86dfb0a3cd022ceb447f40207b537b5b4eec922
  Author: Alan Baradlay 
  Date:   2024-06-11 (Tue, 11 Jun 2024)

  Changed paths:
M Source/WebCore/Headers.cmake
M Source/WebCore/rendering/LayoutRepainter.cpp
M Source/WebCore/rendering/LayoutRepainter.h
M Source/WebCore/rendering/RenderBlockFlow.cpp
M Source/WebCore/rendering/RenderDeprecatedFlexibleBox.cpp
M Source/WebCore/rendering/RenderFlexibleBox.cpp
M Source/WebCore/rendering/RenderGrid.cpp
M Source/WebCore/rendering/RenderReplaced.cpp
M Source/WebCore/rendering/RenderTable.cpp
M Source/WebCore/rendering/mathml/RenderMathMLBlock.cpp
M Source/WebCore/rendering/svg/RenderSVGContainer.cpp
M Source/WebCore/rendering/svg/RenderSVGForeignObject.cpp
M Source/WebCore/rendering/svg/RenderSVGImage.cpp
M Source/WebCore/rendering/svg/RenderSVGRoot.cpp
M Source/WebCore/rendering/svg/RenderSVGShape.cpp
M Source/WebCore/rendering/svg/RenderSVGText.cpp
M Source/WebCore/rendering/svg/SVGRenderSupport.cpp
M Source/WebCore/rendering/svg/SVGRenderSupport.h
M Source/WebCore/rendering/svg/legacy/LegacyRenderSVGContainer.cpp
M Source/WebCore/rendering/svg/legacy/LegacyRenderSVGImage.cpp
M Source/WebCore/rendering/svg/legacy/LegacyRenderSVGRoot.cpp
M Source/WebCore/rendering/svg/legacy/LegacyRenderSVGShape.cpp

  Log Message:
  ---
  Move RenderElement::checkForRepaintDuringLayout to LayoutRepainter
https://bugs.webkit.org/show_bug.cgi?id=275337

Reviewed by Antti Koivisto.

This is in preparation for being able to suspend repaints on child boxes by 
their parents.

* Source/WebCore/rendering/LayoutRepainter.cpp:
(WebCore::LayoutRepainter::LayoutRepainter):
* Source/WebCore/rendering/LayoutRepainter.h:
(WebCore::LayoutRepainter::LayoutRepainter):
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::layoutBlock):
* Source/WebCore/rendering/RenderDeprecatedFlexibleBox.cpp:
(WebCore::RenderDeprecatedFlexibleBox::layoutBlock):
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::layoutBlock):
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::layoutGrid):
(WebCore::RenderGrid::layoutMasonry):
* Source/WebCore/rendering/RenderReplaced.cpp:
(WebCore::RenderReplaced::layout):
* Source/WebCore/rendering/RenderTable.cpp:
(WebCore::RenderTable::layout):
* Source/WebCore/rendering/mathml/RenderMathMLBlock.cpp:
(WebCore::RenderMathMLBlock::layoutBlock):
* Source/WebCore/rendering/svg/RenderSVGContainer.cpp:
(WebCore::RenderSVGContainer::layout):
* Source/WebCore/rendering/svg/RenderSVGForeignObject.cpp:
(WebCore::RenderSVGForeignObject::layout):
* Source/WebCore/rendering/svg/RenderSVGImage.cpp:
(WebCore::RenderSVGImage::layout):
* Source/WebCore/rendering/svg/RenderSVGRoot.cpp:
(WebCore::RenderSVGRoot::layout):
* Source/WebCore/rendering/svg/RenderSVGShape.cpp:
(WebCore::RenderSVGShape::layout):
* Source/WebCore/rendering/svg/RenderSVGText.cpp:
(WebCore::RenderSVGText::layout):
* Source/WebCore/rendering/svg/SVGRenderSupport.cpp:
(WebCore::SVGRenderSupport::checkForSVGRepaintDuringLayout):
* Source/WebCore/rendering/svg/SVGRenderSupport.h:
* Source/WebCore/rendering/svg/legacy/LegacyRenderSVGContainer.cpp:
(WebCore::LegacyRenderSVGContainer::layout):
* Source/WebCore/rendering/svg/legacy/LegacyRenderSVGImage.cpp:
(WebCore::LegacyRenderSVGImage::layout):
* Source/WebCore/rendering/svg/legacy/LegacyRenderSVGRoot.cpp:
(WebCore::LegacyRenderSVGRoot::layout):
* Source/WebCore/rendering/svg/legacy/LegacyRenderSVGShape.cpp:
(WebCore::LegacyRenderSVGShape::layout):

Canonical link: https://commits.webkit.org/279909@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Re: RFR: 8327793: Deprecate jstatd for removal

[Alan Bateman]

On Tue, 11 Jun 2024 13:09:06 GMT, Kevin Walls  wrote:

> jstatd is an RMI server application which monitors HotSpot VMs, and provides 
> an interface to the monitoring tool jstat, for use across a remote RMI 
> connection.
> 
> RMI is not how modern applications communicate. It is an old transport with 
> long term security concerns, and configuration difficulties with firewalls.
> 
> The jstatd tool should be removed. Deprecating and removing jstatd will not 
> affect usage of jstat for monitoring local VMs using the Attach API.

The sun.jvmstat.monitor.remote package is not exported so I don't think adding 
`@Deprecated` makes sense. 

Look at JDK-8245068 when rmid was deprecated and see the warning that it 
printed. I think it's the warning piece that you'll need here.

-

PR Comment: https://git.openjdk.org/jdk/pull/19658#issuecomment-2160786798

Re: RFR: 8327793: Deprecate jstatd for removal

[Alan Bateman]

On Tue, 11 Jun 2024 13:09:06 GMT, Kevin Walls  wrote:

> jstatd is an RMI server application which monitors HotSpot VMs, and provides 
> an interface to the monitoring tool jstat, for use across a remote RMI 
> connection.
> 
> RMI is not how modern applications communicate. It is an old transport with 
> long term security concerns, and configuration difficulties with firewalls.
> 
> The jstatd tool should be removed. Deprecating and removing jstatd will not 
> affect usage of jstat for monitoring local VMs using the Attach API.

The sun.jvmstat.monitor.remote package is not exported so I don't think adding 
`@Deprecated` makes sense. 

Look at JDK-8245068 when rmid was deprecated and see the warning that it 
printed. I think it's the warning piece that you'll need here.

-

PR Comment: https://git.openjdk.org/jdk/pull/19658#issuecomment-2160786798

Re: Examining device state via monitor for debugging (was: [PATCH 0/2] hw/misc/mos6522: Do not open-code hmp_info_human_readable_text())

[Dr. David Alan Gilbert]

* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On Tue, 11 Jun 2024 at 06:50, Markus Armbruster  wrote:
> >
> > Philippe Mathieu-Daudé  writes:
> >
> > > Officialise the QMP command, use the existing
> > > hmp_info_human_readable_text() helper.
> >
> > I'm not sure "officialise" is a word :)
> >
> > Taking a step back...  "info via" and its new QMP counterpart
> > x-query-mos6522-devices dump device state.  I understand why examining
> > device state via monitor can be useful for debugging.  However, we have
> > more than 2000 devices in the tree.  Clearly, we don't want 2000 device
> > state queries.  Not even 100.  Could we have more generic means instead?
> >
> > We could use QOM (read-only) properties to expose device state.
> >
> > If we use one QOM property per "thing", examining device state becomes
> > quite tedious.  Also, you'd have to stop the guest to get a consistent
> > view, and adding lots of QOM properties bloats the code.
> >
> > If we use a single, object-valued property for the entire state, we get
> > to define the objects in QAPI.  Differently tedious, and bloats the
> > generated code.
> 
> We already have a machine readable mandatory-for-every-device
> representation of its entire state -- it's the vmstate struct.
> Admittedly this is sometimes a bit different from the guest-facing
> view of a device and we don't machine-record the field names...

vmstate might not contain everything needed for debug; devices
do a lot of fiddling to create a consistent vmstate, and there may
be more that someone debugging wants (e.g. fd's or host memory addresses).
It's also hopelessly cryptic.

From an HMP point, a 'info debug ' seems good to me,
possibly with some options as to whether to recurse or perhaps
add flags to 'info qtree' to also call it.

Dave




> -- PMM
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Re: [PATCH 2/6] drm/nouveau: remove unused struct 'init_exec'

[Dr. David Alan Gilbert]

* Danilo Krummrich (d...@redhat.com) wrote:
> On 5/18/24 01:26, li...@treblig.org wrote:
> > From: "Dr. David Alan Gilbert" 
> > 
> > 'init_exec' is unused since
> > commit cb75d97e9c77 ("drm/nouveau: implement devinit subdev, and new
> > init table parser")
> > Remove it.
> > 
> > Signed-off-by: Dr. David Alan Gilbert 
> 
> Acked-by: Danilo Krummrich 
> 
> To which series does this patch belong?

Actually all of them were independent patches on drm
some of which are all in, so it can be taken by itself.

> Need me to apply it?

Yes please!

Thanks,

Dave

> - Danilo
> 
> > ---
> >   drivers/gpu/drm/nouveau/nouveau_bios.c | 5 -
> >   1 file changed, 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
> > b/drivers/gpu/drm/nouveau/nouveau_bios.c
> > index 79cfab53f80e..8c3c1f1e01c5 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bios.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
> > @@ -43,11 +43,6 @@
> >   #define BIOSLOG(sip, fmt, arg...) NV_DEBUG(sip->dev, fmt, ##arg)
> >   #define LOG_OLD_VALUE(x)
> > -struct init_exec {
> > -   bool execute;
> > -   bool repeat;
> > -};
> > -
> >   static bool nv_cksum(const uint8_t *data, unsigned int length)
> >   {
> > /*
> 
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Re: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v12]

[Alan Bateman]

On Mon, 10 Jun 2024 07:36:50 GMT, Inigo Mediavilla Saiz  
wrote:

>> Print the stack traces of mounted virtual threads when calling `jcmd  
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request with a new target base due 
> to a merge or a rebase. The incremental webrev excludes the unrelated changes 
> brought in by the merge/rebase. The pull request contains 15 additional 
> commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 
> txominpelu_8330846_add_stack_vthreads
>  - Include virtual thread name in output
>  - Incorporate @tstuefe's remarks
>  - Remove dead code
>  - Remove extra indentation (leave it for the next PR)
>  - Cleanup test
>
>- Stop virtualthread
>- Remove unneeded imports
>- Remove modules that are not needed
>  - Fix copyright year
>  - Print mounted virtual thread after carrier
>  - Add indentation for virtual thread stack
>  - Update 
> test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java
>
>Co-authored-by: Andrey Turbanov 
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/0b955462...ba3385a4

test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 
40:

> 38:  * @run testng PrintVirtualThreadTest
> 39:  */
> 40: public class PrintVirtualThreadTest {

It might be helpful to put  "Mounted" into the test name as this is a test to 
check that a mounted virtual thread appears in the Thread.print output, 
something like PrintMountedVirtualThread.

test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 
52:

> 50: output.shouldMatch(".*at " + 
> Pattern.quote(DummyRunnable.class.getName()) + "\\.run.*");
> 51: output.shouldMatch(".*at " + 
> Pattern.quote(DummyRunnable.class.getName()) + "\\.compute.*");
> 52: shouldFinish.set(true);

This just checks that the stack frames are printed. I think you also want to 
check that the output contains and line with "Mounted virtual thread and the 
thread ID.

test/hotspot/jtreg/serviceability/dcmd/thread/PrintVirtualThreadTest.java line 
78:

> 76: while (true) {
> 77: if (shouldFinish.get()) {
> 78: break;

You can use Thread.onSpinWait in the loop to reduce the impact of the tight 
loop.

Also you can use `while (!shouldFinish.get())` to avoid the explicit break.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1634372088
PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1634377680
PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1634374957

Re: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v8]

[Alan Bateman]

On Tue, 4 Jun 2024 08:06:28 GMT, Alan Bateman  wrote:

>> Inigo Mediavilla Saiz has updated the pull request incrementally with two 
>> additional commits since the last revision:
>> 
>>  - Cleanup test
>>
>>- Stop virtualthread
>>- Remove unneeded imports
>>- Remove modules that are not needed
>>  - Fix copyright year
>
> I think the presentation of the carrier the mounted virtual thread in update 
> (b122cc05) looks quite good.
> 
> I think it would be helpful to include the thread name too. Many virtual 
> threads are unnamed so it will show as "" but that is okay. In addition to 
> being useful it means the format of the "Mounted virtual thread ..." line 
> will be consistent the first part of the line for platform threads.
> 
> I'm wondering if we should remove the existing "Carrying virtual thread ..." 
> line as part of this. It's redundant now, @pron ?

> @AlanBateman @dholmes-ora would you be OK with leaving the current PR as-is 
> and handling the indentation topic in a separate PR ?

I assume the follow-up to improve the alignment will be a small change. No 
objection if you do it here or in a follow-up PR.

-

PR Comment: https://git.openjdk.org/jdk/pull/19482#issuecomment-2160047420

[NetBehaviour] mourning, a story based on a sad truth

[Alan Sondheim via NetBehaviour]

mourning, a story based on a sad truth

https://youtu.be/337h76MaAAE video

a body was just found next to the hurricane barrier in the
Providence River, about a half mile away, and I was thinking
that the body was mine, that i should claim the body as mine,
that i did not own a body since no one 'owns' their body except
perhaps in legal terms, a body is what i have, an odd ontology,
or it's just here, but not around me, not me either, perhaps i
should claim the body as mine, perhaps i should think otherwise.

and thinking the above - it sounds obscene to me now, what was i
thinking, what does it matter what i'm thinking, someone died,
and if anything is sacrosanct, inspires care, inspire silence,
this surely is such, and in fact since we are there a great deal
on our walks, near there, this is sad, is here and now in a city
i still cannot see as my own, at least not since i was alienated
from brown university, which previously i had felt comfortable
within and more comfortable without, and this aside is also not
of or within the above, to return at the least to the water and
the


__

___
NetBehaviour mailing list
NetBehaviour@lists.netbehaviour.org
https://lists.netbehaviour.org/mailman/listinfo/netbehaviour

[clang] [llvm] [MC/DC][Coverage] Loosen the limit of NumConds from 6 (PR #82448)

[Alan Phipps via cfe-commits]

https://github.com/evodius96 approved this pull request.

LGTM but I'd like to see if @ornata or others can definitively approve.

Thanks for this work! Comprehensively I think LLVM MC/DC is really good, and 
there's still more we can do.

https://github.com/llvm/llvm-project/pull/82448
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [MC/DC][Coverage] Loosen the limit of NumConds from 6 (PR #82448)

[Alan Phipps via cfe-commits]

evodius96 wrote:

> Could I update release notes later? I am afraid since I have been always 
> missing release schedules.

I think I'm OK with this; I think the changes make sense. I'd like to see how 
others feel.


https://github.com/llvm/llvm-project/pull/82448
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [MC/DC][Coverage] Loosen the limit of NumConds from 6 (PR #82448)

[Alan Phipps via cfe-commits]

@@ -484,10 +484,31 @@ MC/DC Instrumentation
 -
 
 When instrumenting for Modified Condition/Decision Coverage (MC/DC) using the
-clang option ``-fcoverage-mcdc``, users are limited to at most **six** 
leaf-level
-conditions in a boolean expression.  A warning will be generated for boolean
-expressions that contain more than six, and they will not be instrumented for
-MC/DC.
+clang option ``-fcoverage-mcdc``, there are two hard limits.
+
+The maximum number of terms is limited to 32767. It would be practical for
+handwritten expressions. To be more retrictive in order to enfoce conding 
rules,

evodius96 wrote:

Nit: "retrictive" --> "restrictive" and "enfoce" --> "enforce"

https://github.com/llvm/llvm-project/pull/82448
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH 1/3] hw/s390x: Declare target specific monitor commands in hmp-target.h

[Dr. David Alan Gilbert]

* Philippe Mathieu-Daudé (phi...@linaro.org) wrote:
> "monitor/hmp-target.h" is meant to hold target-specific commands.
> Move s390x specific commands there, slightly simplifying hmp-target.c.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  include/hw/s390x/storage-attributes.h | 4 
>  include/hw/s390x/storage-keys.h   | 4 
>  include/monitor/hmp-target.h  | 5 +
>  hw/s390x/s390-skeys.c | 2 ++
>  hw/s390x/s390-stattrib.c  | 2 ++
>  monitor/hmp-target.c  | 5 -
>  6 files changed, 9 insertions(+), 13 deletions(-)
> 
> diff --git a/include/hw/s390x/storage-attributes.h 
> b/include/hw/s390x/storage-attributes.h
> index 8921a04d51..4916c75936 100644
> --- a/include/hw/s390x/storage-attributes.h
> +++ b/include/hw/s390x/storage-attributes.h
> @@ -13,7 +13,6 @@
>  #define S390_STORAGE_ATTRIBUTES_H
>  
>  #include "hw/qdev-core.h"
> -#include "monitor/monitor.h"
>  #include "qom/object.h"
>  
>  #define TYPE_S390_STATTRIB "s390-storage_attributes"
> @@ -73,7 +72,4 @@ static inline Object *kvm_s390_stattrib_create(void)
>  }
>  #endif
>  
> -void hmp_info_cmma(Monitor *mon, const QDict *qdict);
> -void hmp_migrationmode(Monitor *mon, const QDict *qdict);
> -
>  #endif /* S390_STORAGE_ATTRIBUTES_H */
> diff --git a/include/hw/s390x/storage-keys.h b/include/hw/s390x/storage-keys.h
> index aa2ec2aae5..1d9b7ead44 100644
> --- a/include/hw/s390x/storage-keys.h
> +++ b/include/hw/s390x/storage-keys.h
> @@ -13,7 +13,6 @@
>  #define S390_STORAGE_KEYS_H
>  
>  #include "hw/qdev-core.h"
> -#include "monitor/monitor.h"
>  #include "qom/object.h"
>  
>  #define TYPE_S390_SKEYS "s390-skeys"
> @@ -114,7 +113,4 @@ void s390_skeys_init(void);
>  
>  S390SKeysState *s390_get_skeys_device(void);
>  
> -void hmp_dump_skeys(Monitor *mon, const QDict *qdict);
> -void hmp_info_skeys(Monitor *mon, const QDict *qdict);
> -
>  #endif /* S390_STORAGE_KEYS_H */
> diff --git a/include/monitor/hmp-target.h b/include/monitor/hmp-target.h
> index b679aaebbf..024cff0052 100644
> --- a/include/monitor/hmp-target.h
> +++ b/include/monitor/hmp-target.h
> @@ -61,4 +61,9 @@ void hmp_gva2gpa(Monitor *mon, const QDict *qdict);
>  void hmp_gpa2hva(Monitor *mon, const QDict *qdict);
>  void hmp_gpa2hpa(Monitor *mon, const QDict *qdict);
>  
> +void hmp_dump_skeys(Monitor *mon, const QDict *qdict);
> +void hmp_info_skeys(Monitor *mon, const QDict *qdict);
> +void hmp_info_cmma(Monitor *mon, const QDict *qdict);
> +void hmp_migrationmode(Monitor *mon, const QDict *qdict);
> +

Could you please add a comment here saying that these are all s390,
since it's not obvious from their names.
(and if we're lucky the other s390 commands will stay with them).

Dave

>  #endif /* MONITOR_HMP_TARGET_H */
> diff --git a/hw/s390x/s390-skeys.c b/hw/s390x/s390-skeys.c
> index 5c535d483e..7b2ccb94a5 100644
> --- a/hw/s390x/s390-skeys.c
> +++ b/hw/s390x/s390-skeys.c
> @@ -23,6 +23,8 @@
>  #include "sysemu/kvm.h"
>  #include "migration/qemu-file-types.h"
>  #include "migration/register.h"
> +#include "monitor/hmp-target.h"
> +#include "monitor/monitor.h"
>  
>  #define S390_SKEYS_BUFFER_SIZE (128 * KiB)  /* Room for 128k storage keys */
>  #define S390_SKEYS_SAVE_FLAG_EOS 0x01
> diff --git a/hw/s390x/s390-stattrib.c b/hw/s390x/s390-stattrib.c
> index c4259b5327..9b4b8d8d0c 100644
> --- a/hw/s390x/s390-stattrib.c
> +++ b/hw/s390x/s390-stattrib.c
> @@ -19,6 +19,8 @@
>  #include "exec/ram_addr.h"
>  #include "qapi/error.h"
>  #include "qapi/qmp/qdict.h"
> +#include "monitor/hmp-target.h"
> +#include "monitor/monitor.h"
>  #include "cpu.h"
>  
>  /* 512KiB cover 2GB of guest memory */
> diff --git a/monitor/hmp-target.c b/monitor/hmp-target.c
> index 1eb72ac1bf..0466474354 100644
> --- a/monitor/hmp-target.c
> +++ b/monitor/hmp-target.c
> @@ -36,11 +36,6 @@
>  #include "qapi/error.h"
>  #include "qemu/cutils.h"
>  
> -#if defined(TARGET_S390X)
> -#include "hw/s390x/storage-keys.h"
> -#include "hw/s390x/storage-attributes.h"
> -#endif
> -
>  /* Make devices configuration available for use in hmp-commands*.hx 
> templates */
>  #include CONFIG_DEVICES
>  
> -- 
> 2.41.0
> 
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Re: consolidating CI builds

[Alan Coopersmith]

On 5/24/24 03:12, Enrico Weigelt, metux IT consult wrote:

So, I'm thinking about creating some standard templates that all drivers
can use. The interesting question now becomes: where to put these ?

Abuse xorg/util/cf or xorg/util/macros or create an entirely new repo ?


I wouldn't use either of those - util/cf is specifically for building with
Imake and util/macro is for building with autoconf.  No X.Org packages (other
than perhaps Imake itself, if anyone ever added some testing to the CI) should
have the cf package installed in their CI environment and once packages finish
converting to meson and drop autoconf support, they shouldn't need util/macro
either.  In our dream world, both of those repos will be archived someday as
no longer needed by anyone (in reality, we know that's still a ways away).

The closest existing repo is the freedesktop/ci-templates repo we use already,
but that's for freedesktop-wide stuff, and I'm not sure they want stuff specific
to things like xorg drivers in there - repos are cheap though, so we could make
a new xorg/util/ci-templates or similar if it's useful.

--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Re: git: 91d35fb663e0 - main - Remove WITHOUT_CAPSICUM build support

[Alan Somers]

On Tue, Apr 23, 2024 at 6:27 AM Ed Maste  wrote:
>
> The branch main has been updated by emaste:
>
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=91d35fb663e0276abc4963ae559e4759ea929842
>
> commit 91d35fb663e0276abc4963ae559e4759ea929842
> Author: Ed Maste 
> AuthorDate: 2024-04-23 11:20:59 +
> Commit: Ed Maste 
> CommitDate: 2024-04-23 12:26:28 +
>
> Remove WITHOUT_CAPSICUM build support
>
> Capsicum is non-optional as of c24c117b9644 ("Remove
> WITHOUT_{CAPSICUM,CASPER} options").
>
> `#ifndef WITHOUT_CAPSICUM` is left in the source for the benefit of
> downstream consumers, but is never defined in FreeBSD.
>
> Reviewed by:oshogbo
> Sponsored by:   The FreeBSD Foundation
> Differential Revision:  https://reviews.freebsd.org/D42077

Should we now remove the caph_enter family of functions?  Or do they
still have utility for downstream consumers?

Re: git: 91d35fb663e0 - main - Remove WITHOUT_CAPSICUM build support

[Alan Somers]

On Tue, Apr 23, 2024 at 6:27 AM Ed Maste  wrote:
>
> The branch main has been updated by emaste:
>
> URL: 
> https://cgit.FreeBSD.org/src/commit/?id=91d35fb663e0276abc4963ae559e4759ea929842
>
> commit 91d35fb663e0276abc4963ae559e4759ea929842
> Author: Ed Maste 
> AuthorDate: 2024-04-23 11:20:59 +
> Commit: Ed Maste 
> CommitDate: 2024-04-23 12:26:28 +
>
> Remove WITHOUT_CAPSICUM build support
>
> Capsicum is non-optional as of c24c117b9644 ("Remove
> WITHOUT_{CAPSICUM,CASPER} options").
>
> `#ifndef WITHOUT_CAPSICUM` is left in the source for the benefit of
> downstream consumers, but is never defined in FreeBSD.
>
> Reviewed by:oshogbo
> Sponsored by:   The FreeBSD Foundation
> Differential Revision:  https://reviews.freebsd.org/D42077

Should we now remove the caph_enter family of functions?  Or do they
still have utility for downstream consumers?

git: 81ef0a89fcc0 - main - Fix mtree entry for ctladm tests

[Alan Somers]

The branch main has been updated by asomers:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=81ef0a89fcc055bdf3d0f1affbadb643412ebce9

commit 81ef0a89fcc055bdf3d0f1affbadb643412ebce9
Author: Alan Somers 
AuthorDate: 2024-06-10 17:29:48 +
Commit: Alan Somers 
CommitDate: 2024-06-10 17:29:48 +

Fix mtree entry for ctladm tests

MFC after:  2 weeks
MFC with:   9747d11d91642cb9b81602d88e8aebeb388543c7
Sponsored by:   Axcient
---
 etc/mtree/BSD.tests.dist | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/etc/mtree/BSD.tests.dist b/etc/mtree/BSD.tests.dist
index 86db4304b932..92501766ef88 100644
--- a/etc/mtree/BSD.tests.dist
+++ b/etc/mtree/BSD.tests.dist
@@ -90,8 +90,6 @@
 ..
 ..
 usr.sbin
-ctladm
-..
 dtrace
 common
 aggs
@@ -1225,6 +1223,8 @@
 usr.sbin
 chown
 ..
+ctladm
+..
 daemon
 ..
 etcupdate

git: 81ef0a89fcc0 - main - Fix mtree entry for ctladm tests

[Alan Somers]

The branch main has been updated by asomers:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=81ef0a89fcc055bdf3d0f1affbadb643412ebce9

commit 81ef0a89fcc055bdf3d0f1affbadb643412ebce9
Author: Alan Somers 
AuthorDate: 2024-06-10 17:29:48 +
Commit: Alan Somers 
CommitDate: 2024-06-10 17:29:48 +

Fix mtree entry for ctladm tests

MFC after:  2 weeks
MFC with:   9747d11d91642cb9b81602d88e8aebeb388543c7
Sponsored by:   Axcient
---
 etc/mtree/BSD.tests.dist | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/etc/mtree/BSD.tests.dist b/etc/mtree/BSD.tests.dist
index 86db4304b932..92501766ef88 100644
--- a/etc/mtree/BSD.tests.dist
+++ b/etc/mtree/BSD.tests.dist
@@ -90,8 +90,6 @@
 ..
 ..
 usr.sbin
-ctladm
-..
 dtrace
 common
 aggs
@@ -1225,6 +1223,8 @@
 usr.sbin
 chown
 ..
+ctladm
+..
 daemon
 ..
 etcupdate

git: edbd489d09ba - main - ctladm: don't require the use of "-p" with "port -r"

[Alan Somers]

The branch main has been updated by asomers:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=edbd489d09babebdc6c03924a912013be584c409

commit edbd489d09babebdc6c03924a912013be584c409
Author: Alan Somers 
AuthorDate: 2024-06-06 19:14:43 +
Commit: Alan Somers 
CommitDate: 2024-06-10 16:01:25 +

ctladm: don't require the use of "-p" with "port -r"

When removing a port, the ioctl frontend requires the "-p" argument.
But other frontends, like cfiscsi, do not.  So don't require that
argument in the ctladm command.  The frontend driver will report an
error if any required argument is missing.

MFC after:  2 weeks
Sponsored by:   Axcient
Reviewed by:mav
Pull Request:   https://github.com/freebsd/freebsd-src/pull/1279
---
 sys/cam/ctl/ctl_frontend_ioctl.c |  2 +-
 usr.sbin/ctladm/ctladm.8 |  3 +--
 usr.sbin/ctladm/ctladm.c | 10 +++---
 usr.sbin/ctladm/tests/port.sh| 28 +++-
 4 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/sys/cam/ctl/ctl_frontend_ioctl.c b/sys/cam/ctl/ctl_frontend_ioctl.c
index 7fc8deac82b3..3449154afb38 100644
--- a/sys/cam/ctl/ctl_frontend_ioctl.c
+++ b/sys/cam/ctl/ctl_frontend_ioctl.c
@@ -267,7 +267,7 @@ cfi_ioctl_port_remove(struct ctl_req *req)
if (port_id == -1) {
req->status = CTL_LUN_ERROR;
snprintf(req->error_str, sizeof(req->error_str),
-   "port_id not provided");
+   "Missing required argument: port_id");
return;
}
 
diff --git a/usr.sbin/ctladm/ctladm.8 b/usr.sbin/ctladm/ctladm.8
index 5c6e4aa04c77..72f0162eed54 100644
--- a/usr.sbin/ctladm/ctladm.8
+++ b/usr.sbin/ctladm/ctladm.8
@@ -673,8 +673,7 @@ and
 Specify the frontend port number.
 The port numbers can be found in the frontend port list.
 .It Fl r
-Remove port specified with
-.Pq Fl p Ar targ_port .
+Remove a port.
 .It Fl t Ar fe_type
 Specify the frontend type used by the
 .Pq Fl o ,
diff --git a/usr.sbin/ctladm/ctladm.c b/usr.sbin/ctladm/ctladm.c
index 14951797ddf1..46b7b88547dd 100644
--- a/usr.sbin/ctladm/ctladm.c
+++ b/usr.sbin/ctladm/ctladm.c
@@ -580,11 +580,6 @@ cctl_port(int fd, int argc, char **argv, char *combinedopt)
break;
}
case CCTL_PORT_MODE_REMOVE:
-   if (targ_port == -1) {
-   warnx("%s: -r requires -p", __func__);
-   retval = 1;
-   goto bailout;
-   }
/* FALLTHROUGH */
case CCTL_PORT_MODE_CREATE: {
bzero(, sizeof(req));
@@ -594,8 +589,9 @@ cctl_port(int fd, int argc, char **argv, char *combinedopt)
 
if (port_mode == CCTL_PORT_MODE_REMOVE) {
req.reqtype = CTL_REQ_REMOVE;
-   nvlist_add_stringf(option_list, "port_id", "%d",
-   targ_port);
+   if (targ_port != -1)
+   nvlist_add_stringf(option_list, "port_id", "%d",
+   targ_port);
} else
req.reqtype = CTL_REQ_CREATE;
 
diff --git a/usr.sbin/ctladm/tests/port.sh b/usr.sbin/ctladm/tests/port.sh
index 1f2c9aaed5c1..139e1a7d29a0 100644
--- a/usr.sbin/ctladm/tests/port.sh
+++ b/usr.sbin/ctladm/tests/port.sh
@@ -37,8 +37,6 @@ cleanup() {
;;
"iscsi")
TARGET=`awk '/target:/ {print $2}' port-create.txt`
-   # PORTNUM is ignored, but must be set
-   PORTNUM=
ctladm port -r -d $driver -p "$PORTNUM" -O 
cfiscsi_portal_group_tag=$PGTAG -O cfiscsi_target=$TARGET
;;
esac
@@ -68,6 +66,25 @@ create_ioctl_cleanup()
cleanup ioctl
 }
 
+atf_test_case remove_ioctl_without_required_args cleanup
+remove_ioctl_without_required_args_head()
+{
+   atf_set "descr" "ctladm will gracefully fail to remove an ioctl target 
if required arguments are missing"
+   atf_set "require.user" "root"
+}
+remove_ioctl_without_required_args_body()
+{
+   skip_if_ctld
+
+   atf_check -o save:port-create.txt ctladm port -c -d "ioctl"
+   atf_check egrep -q "Port created successfully" port-create.txt
+   atf_check -s exit:1 -e match:"Missing required argument: port_id" 
ctladm port -r -d "ioctl"
+}
+remove_ioctl_without_required_args_cleanup()
+{
+   cleanup ioctl
+}
+
 atf_test_case create_iscsi cleanup
 create_iscsi_head()
 {
@@ -246,7 +263,7 @@ remove_iscsi_body()
atf_check -o save:port-create.txt ctladm port -c -d "iscsi" -O 
cfiscsi_portal_group_tag=$PGTAG -O cfiscsi_target="$TAR

git: 591de7534fb3 - main - ctladm: print port number with a succesful "port -c" command

[Alan Somers]

The branch main has been updated by asomers:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=591de7534fb3acb2e6eef94a1e5e92000d2cf83d

commit 591de7534fb3acb2e6eef94a1e5e92000d2cf83d
Author: Alan Somers 
AuthorDate: 2024-06-05 23:54:46 +
Commit: Alan Somers 
CommitDate: 2024-06-10 16:01:25 +

ctladm: print port number with a succesful "port -c" command

Make "ctladm port -c" print the port number of the newly successful
port.  This way it won't have to be guessed by a subsequent "ctladm
portlist" command.  That means it's safe to use it concurrently with
other ctladm processes.  In particular, this allows the tests to be run
in parallel.

MFC after:  2 weeks
Sponsored by:   Axcient
Reviewed by:mav
Pull Request:   https://github.com/freebsd/freebsd-src/pull/1279
---
 usr.sbin/ctladm/ctladm.c   | 18 +++
 usr.sbin/ctladm/tests/Makefile |  4 ---
 usr.sbin/ctladm/tests/port.sh  | 70 --
 3 files changed, 52 insertions(+), 40 deletions(-)

diff --git a/usr.sbin/ctladm/ctladm.c b/usr.sbin/ctladm/ctladm.c
index 28f9a39386d3..14951797ddf1 100644
--- a/usr.sbin/ctladm/ctladm.c
+++ b/usr.sbin/ctladm/ctladm.c
@@ -397,7 +397,9 @@ static struct ctladm_opts cctl_fe_table[] = {
 static int
 cctl_port(int fd, int argc, char **argv, char *combinedopt)
 {
+   char result_buf[1024];
int c;
+   uint64_t created_port = -1;
int32_t targ_port = -1;
int retval = 0;
int wwnn_set = 0, wwpn_set = 0;
@@ -587,6 +589,8 @@ cctl_port(int fd, int argc, char **argv, char *combinedopt)
case CCTL_PORT_MODE_CREATE: {
bzero(, sizeof(req));
strlcpy(req.driver, driver, sizeof(req.driver));
+   req.result = result_buf;
+   req.result_len = sizeof(result_buf);
 
if (port_mode == CCTL_PORT_MODE_REMOVE) {
req.reqtype = CTL_REQ_REMOVE;
@@ -619,6 +623,20 @@ cctl_port(int fd, int argc, char **argv, char *combinedopt)
warnx("warning: %s", req.error_str);
break;
case CTL_LUN_OK:
+   if (port_mode == CCTL_PORT_MODE_CREATE) {
+   req.result_nvl = nvlist_unpack(result_buf, 
req.result_len, 0);
+   if (req.result_nvl == NULL) {
+   warnx("error unpacking result nvlist");
+   break;
+   }
+   created_port = 
nvlist_get_number(req.result_nvl, "port_id");
+   printf("Port created successfully\n"
+   "frontend: %s\n"
+   "port: %ju\n", driver,
+   (uintmax_t) created_port);
+   nvlist_destroy(req.result_nvl);
+   } else
+   printf("Port destroyed successfully\n");
break;
default:
warnx("unknown status: %d", req.status);
diff --git a/usr.sbin/ctladm/tests/Makefile b/usr.sbin/ctladm/tests/Makefile
index 73ac94d77d21..825e38e6c6e3 100644
--- a/usr.sbin/ctladm/tests/Makefile
+++ b/usr.sbin/ctladm/tests/Makefile
@@ -3,8 +3,4 @@ PACKAGE=tests
 
 ATF_TESTS_SH=  port
 
-# "ctladm port" does not report the name of the port just created, so we can't
-# cleanup unless we assume that no other test created a port too.
-TEST_METADATA+= is_exclusive="true"
-
 .include 
diff --git a/usr.sbin/ctladm/tests/port.sh b/usr.sbin/ctladm/tests/port.sh
index b2cdea6f1de2..ccc4a6fc502e 100644
--- a/usr.sbin/ctladm/tests/port.sh
+++ b/usr.sbin/ctladm/tests/port.sh
@@ -20,8 +20,9 @@ skip_if_ctld() {
 cleanup() {
driver=$1
 
-   if [ -e after-ports ]; then
-   diff before-ports after-ports | awk "/$driver/ {print \$2}" | 
xargs -n1 ctladm port -r -d ioctl -p
+   if [ -e port-create.txt ]; then
+   portnum=`awk '/port:/ {print $2}' port-create.txt`
+   ctladm port -r -d $driver -p $portnum
fi
 }
 
@@ -35,12 +36,13 @@ create_ioctl_body()
 {
skip_if_ctld
 
-   atf_check -o save:before-ports ctladm portlist -qf ioctl
-   atf_check ctladm port -c -d "ioctl"
-   atf_check -o save:after-ports ctladm portlist -qf ioctl
-   if test `wc -l before-ports | cut -w -f2` -ge `wc -l after-ports | cut 
-w -f2`; then
-   atf_fail "Did not create a new ioctl port"
-   fi
+   atf_check -o save:port-create.txt ctladm port -c -d "ioctl"
+   atf_check egrep -q "Port created successfully" port-create.txt
+   atf_check eg

git: afecc74cd715 - main - ctladm: better documentation for adding and removing cfiscsi ports

[Alan Somers]

The branch main has been updated by asomers:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=afecc74cd7158da8e89c26c5267bc715c2417fe7

commit afecc74cd7158da8e89c26c5267bc715c2417fe7
Author: Alan Somers 
AuthorDate: 2024-06-06 17:19:19 +
Commit: Alan Somers 
CommitDate: 2024-06-10 16:01:25 +

ctladm: better documentation for adding and removing cfiscsi ports

MFC after:  2 weeks
Sponsored by:   Axcient
Reviewed by:mav
Pull Request:   https://github.com/freebsd/freebsd-src/pull/1279
---
 sys/cam/ctl/ctl_frontend_iscsi.c |  27 ++--
 usr.sbin/ctladm/ctladm.8 |  32 +++--
 usr.sbin/ctladm/tests/port.sh| 146 ++-
 3 files changed, 191 insertions(+), 14 deletions(-)

diff --git a/sys/cam/ctl/ctl_frontend_iscsi.c b/sys/cam/ctl/ctl_frontend_iscsi.c
index fe3b1a943206..e8a3fe7cd36a 100644
--- a/sys/cam/ctl/ctl_frontend_iscsi.c
+++ b/sys/cam/ctl/ctl_frontend_iscsi.c
@@ -2149,17 +2149,24 @@ cfiscsi_ioctl_port_create(struct ctl_req *req)
uint16_t tag;
 
target = dnvlist_get_string(req->args_nvl, "cfiscsi_target", NULL);
-   alias = dnvlist_get_string(req->args_nvl, "cfiscsi_target_alias", NULL);
+   if (target == NULL) {
+   req->status = CTL_LUN_ERROR;
+   snprintf(req->error_str, sizeof(req->error_str),
+   "Missing required argument: cfiscsi_target");
+   return;
+   }
+
val = dnvlist_get_string(req->args_nvl, "cfiscsi_portal_group_tag",
NULL);
-
-   if (target == NULL || val == NULL) {
+   if (val == NULL) {
req->status = CTL_LUN_ERROR;
snprintf(req->error_str, sizeof(req->error_str),
-   "Missing required argument");
+   "Missing required argument: cfiscsi_portal_group_tag");
return;
}
 
+   alias = dnvlist_get_string(req->args_nvl, "cfiscsi_target_alias", NULL);
+
tag = strtoul(val, NULL, 0);
ct = cfiscsi_target_find_or_create(_softc, target, alias, tag);
if (ct == NULL) {
@@ -2250,13 +2257,19 @@ cfiscsi_ioctl_port_remove(struct ctl_req *req)
uint16_t tag;
 
target = dnvlist_get_string(req->args_nvl, "cfiscsi_target", NULL);
+   if (target == NULL) {
+   req->status = CTL_LUN_ERROR;
+   snprintf(req->error_str, sizeof(req->error_str),
+   "Missing required argument: cfiscsi_target");
+   return;
+   }
+
val = dnvlist_get_string(req->args_nvl, "cfiscsi_portal_group_tag",
NULL);
-
-   if (target == NULL || val == NULL) {
+   if (val == NULL) {
req->status = CTL_LUN_ERROR;
snprintf(req->error_str, sizeof(req->error_str),
-   "Missing required argument");
+   "Missing required argument: cfiscsi_portal_group_tag");
return;
}
 
diff --git a/usr.sbin/ctladm/ctladm.8 b/usr.sbin/ctladm/ctladm.8
index b3af4b45ba26..5c6e4aa04c77 100644
--- a/usr.sbin/ctladm/ctladm.8
+++ b/usr.sbin/ctladm/ctladm.8
@@ -35,7 +35,7 @@
 .\"
 .\" $Id: //depot/users/kenm/FreeBSD-test2/usr.sbin/ctladm/ctladm.8#3 $
 .\"
-.Dd June 5, 2024
+.Dd June 6, 2024
 .Dt CTLADM 8
 .Os
 .Sh NAME
@@ -166,7 +166,7 @@
 .Op Fl o Ar on|off
 .Op Fl w Ar wwpn
 .Op Fl W Ar wwnn
-.Op Fl O Ar pp|vp
+.Op Fl O Ar name=value
 .Op Fl p Ar targ_port
 .Op Fl r
 .Op Fl t Ar fe_type
@@ -625,7 +625,7 @@ The WWNN and WWPN may both be specified at the same time, 
but cannot be
 combined with enabling/disabling or listing ports.
 .Bl -tag -width 12n
 .It Fl c
-Create new frontend port using free pp and vp=0.
+Create new frontend port.
 .It Fl d Ar driver
 Specify the name of the frontend driver used by the
 .Pq Fl c
@@ -644,7 +644,31 @@ If no port number or port type is specified, all ports are 
turned on or
 off.
 .It Fl O Ar pp|vp
 Specify generic options on the ioctl frontend port.
-At present, only pp and vp port numbers can be set.
+The list of recognized options is driver-dependent.
+The
+.Dq ioctl
+driver recognizes
+.Dq pp
+and
+.Dq vp .
+The
+.Dq iscsi
+driver recongizes
+.Dq cfiscsi_portal_group_tag ,
+.Dq cfiscsi_target ,
+and
+.Dq cfiscsi_target_alias .
+The
+.Dq nvmf
+driver recognizes
+.Dq subnqn ,
+.Dq portid ,
+.Dq max_io_qsize ,
+.Dq enable_timeout ,
+.Dq ioccsz ,
+.Dq nn ,
+and
+.Dq serial .
 .It Fl p Ar targ_port
 Specify the frontend port number.
 The port numbers can be found in the frontend port list.
diff --git a/usr.sbin/ctladm/tests/port.sh b/usr.sbin/ctladm/tests/port.sh
index ccc4a6fc502e..1f2c9aaed5c1 100644
--- a/usr.sbin/ctladm/tests/port.sh
+++ b/usr.sbin/ctladm/tests/port.sh
@@ -5,11 +5,20 @@
 # * Creating umass ports
 
 # TODO
-# * Creating iscsi ports
 

git: edbd489d09ba - main - ctladm: don't require the use of "-p" with "port -r"

[Alan Somers]

The branch main has been updated by asomers:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=edbd489d09babebdc6c03924a912013be584c409

commit edbd489d09babebdc6c03924a912013be584c409
Author: Alan Somers 
AuthorDate: 2024-06-06 19:14:43 +
Commit: Alan Somers 
CommitDate: 2024-06-10 16:01:25 +

ctladm: don't require the use of "-p" with "port -r"

When removing a port, the ioctl frontend requires the "-p" argument.
But other frontends, like cfiscsi, do not.  So don't require that
argument in the ctladm command.  The frontend driver will report an
error if any required argument is missing.

MFC after:  2 weeks
Sponsored by:   Axcient
Reviewed by:mav
Pull Request:   https://github.com/freebsd/freebsd-src/pull/1279
---
 sys/cam/ctl/ctl_frontend_ioctl.c |  2 +-
 usr.sbin/ctladm/ctladm.8 |  3 +--
 usr.sbin/ctladm/ctladm.c | 10 +++---
 usr.sbin/ctladm/tests/port.sh| 28 +++-
 4 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/sys/cam/ctl/ctl_frontend_ioctl.c b/sys/cam/ctl/ctl_frontend_ioctl.c
index 7fc8deac82b3..3449154afb38 100644
--- a/sys/cam/ctl/ctl_frontend_ioctl.c
+++ b/sys/cam/ctl/ctl_frontend_ioctl.c
@@ -267,7 +267,7 @@ cfi_ioctl_port_remove(struct ctl_req *req)
if (port_id == -1) {
req->status = CTL_LUN_ERROR;
snprintf(req->error_str, sizeof(req->error_str),
-   "port_id not provided");
+   "Missing required argument: port_id");
return;
}
 
diff --git a/usr.sbin/ctladm/ctladm.8 b/usr.sbin/ctladm/ctladm.8
index 5c6e4aa04c77..72f0162eed54 100644
--- a/usr.sbin/ctladm/ctladm.8
+++ b/usr.sbin/ctladm/ctladm.8
@@ -673,8 +673,7 @@ and
 Specify the frontend port number.
 The port numbers can be found in the frontend port list.
 .It Fl r
-Remove port specified with
-.Pq Fl p Ar targ_port .
+Remove a port.
 .It Fl t Ar fe_type
 Specify the frontend type used by the
 .Pq Fl o ,
diff --git a/usr.sbin/ctladm/ctladm.c b/usr.sbin/ctladm/ctladm.c
index 14951797ddf1..46b7b88547dd 100644
--- a/usr.sbin/ctladm/ctladm.c
+++ b/usr.sbin/ctladm/ctladm.c
@@ -580,11 +580,6 @@ cctl_port(int fd, int argc, char **argv, char *combinedopt)
break;
}
case CCTL_PORT_MODE_REMOVE:
-   if (targ_port == -1) {
-   warnx("%s: -r requires -p", __func__);
-   retval = 1;
-   goto bailout;
-   }
/* FALLTHROUGH */
case CCTL_PORT_MODE_CREATE: {
bzero(, sizeof(req));
@@ -594,8 +589,9 @@ cctl_port(int fd, int argc, char **argv, char *combinedopt)
 
if (port_mode == CCTL_PORT_MODE_REMOVE) {
req.reqtype = CTL_REQ_REMOVE;
-   nvlist_add_stringf(option_list, "port_id", "%d",
-   targ_port);
+   if (targ_port != -1)
+   nvlist_add_stringf(option_list, "port_id", "%d",
+   targ_port);
} else
req.reqtype = CTL_REQ_CREATE;
 
diff --git a/usr.sbin/ctladm/tests/port.sh b/usr.sbin/ctladm/tests/port.sh
index 1f2c9aaed5c1..139e1a7d29a0 100644
--- a/usr.sbin/ctladm/tests/port.sh
+++ b/usr.sbin/ctladm/tests/port.sh
@@ -37,8 +37,6 @@ cleanup() {
;;
"iscsi")
TARGET=`awk '/target:/ {print $2}' port-create.txt`
-   # PORTNUM is ignored, but must be set
-   PORTNUM=
ctladm port -r -d $driver -p "$PORTNUM" -O 
cfiscsi_portal_group_tag=$PGTAG -O cfiscsi_target=$TARGET
;;
esac
@@ -68,6 +66,25 @@ create_ioctl_cleanup()
cleanup ioctl
 }
 
+atf_test_case remove_ioctl_without_required_args cleanup
+remove_ioctl_without_required_args_head()
+{
+   atf_set "descr" "ctladm will gracefully fail to remove an ioctl target 
if required arguments are missing"
+   atf_set "require.user" "root"
+}
+remove_ioctl_without_required_args_body()
+{
+   skip_if_ctld
+
+   atf_check -o save:port-create.txt ctladm port -c -d "ioctl"
+   atf_check egrep -q "Port created successfully" port-create.txt
+   atf_check -s exit:1 -e match:"Missing required argument: port_id" 
ctladm port -r -d "ioctl"
+}
+remove_ioctl_without_required_args_cleanup()
+{
+   cleanup ioctl
+}
+
 atf_test_case create_iscsi cleanup
 create_iscsi_head()
 {
@@ -246,7 +263,7 @@ remove_iscsi_body()
atf_check -o save:port-create.txt ctladm port -c -d "iscsi" -O 
cfiscsi_portal_group_tag=$PGTAG -O cfiscsi_target="$TAR

git: afecc74cd715 - main - ctladm: better documentation for adding and removing cfiscsi ports

[Alan Somers]

The branch main has been updated by asomers:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=afecc74cd7158da8e89c26c5267bc715c2417fe7

commit afecc74cd7158da8e89c26c5267bc715c2417fe7
Author: Alan Somers 
AuthorDate: 2024-06-06 17:19:19 +
Commit: Alan Somers 
CommitDate: 2024-06-10 16:01:25 +

ctladm: better documentation for adding and removing cfiscsi ports

MFC after:  2 weeks
Sponsored by:   Axcient
Reviewed by:mav
Pull Request:   https://github.com/freebsd/freebsd-src/pull/1279
---
 sys/cam/ctl/ctl_frontend_iscsi.c |  27 ++--
 usr.sbin/ctladm/ctladm.8 |  32 +++--
 usr.sbin/ctladm/tests/port.sh| 146 ++-
 3 files changed, 191 insertions(+), 14 deletions(-)

diff --git a/sys/cam/ctl/ctl_frontend_iscsi.c b/sys/cam/ctl/ctl_frontend_iscsi.c
index fe3b1a943206..e8a3fe7cd36a 100644
--- a/sys/cam/ctl/ctl_frontend_iscsi.c
+++ b/sys/cam/ctl/ctl_frontend_iscsi.c
@@ -2149,17 +2149,24 @@ cfiscsi_ioctl_port_create(struct ctl_req *req)
uint16_t tag;
 
target = dnvlist_get_string(req->args_nvl, "cfiscsi_target", NULL);
-   alias = dnvlist_get_string(req->args_nvl, "cfiscsi_target_alias", NULL);
+   if (target == NULL) {
+   req->status = CTL_LUN_ERROR;
+   snprintf(req->error_str, sizeof(req->error_str),
+   "Missing required argument: cfiscsi_target");
+   return;
+   }
+
val = dnvlist_get_string(req->args_nvl, "cfiscsi_portal_group_tag",
NULL);
-
-   if (target == NULL || val == NULL) {
+   if (val == NULL) {
req->status = CTL_LUN_ERROR;
snprintf(req->error_str, sizeof(req->error_str),
-   "Missing required argument");
+   "Missing required argument: cfiscsi_portal_group_tag");
return;
}
 
+   alias = dnvlist_get_string(req->args_nvl, "cfiscsi_target_alias", NULL);
+
tag = strtoul(val, NULL, 0);
ct = cfiscsi_target_find_or_create(_softc, target, alias, tag);
if (ct == NULL) {
@@ -2250,13 +2257,19 @@ cfiscsi_ioctl_port_remove(struct ctl_req *req)
uint16_t tag;
 
target = dnvlist_get_string(req->args_nvl, "cfiscsi_target", NULL);
+   if (target == NULL) {
+   req->status = CTL_LUN_ERROR;
+   snprintf(req->error_str, sizeof(req->error_str),
+   "Missing required argument: cfiscsi_target");
+   return;
+   }
+
val = dnvlist_get_string(req->args_nvl, "cfiscsi_portal_group_tag",
NULL);
-
-   if (target == NULL || val == NULL) {
+   if (val == NULL) {
req->status = CTL_LUN_ERROR;
snprintf(req->error_str, sizeof(req->error_str),
-   "Missing required argument");
+   "Missing required argument: cfiscsi_portal_group_tag");
return;
}
 
diff --git a/usr.sbin/ctladm/ctladm.8 b/usr.sbin/ctladm/ctladm.8
index b3af4b45ba26..5c6e4aa04c77 100644
--- a/usr.sbin/ctladm/ctladm.8
+++ b/usr.sbin/ctladm/ctladm.8
@@ -35,7 +35,7 @@
 .\"
 .\" $Id: //depot/users/kenm/FreeBSD-test2/usr.sbin/ctladm/ctladm.8#3 $
 .\"
-.Dd June 5, 2024
+.Dd June 6, 2024
 .Dt CTLADM 8
 .Os
 .Sh NAME
@@ -166,7 +166,7 @@
 .Op Fl o Ar on|off
 .Op Fl w Ar wwpn
 .Op Fl W Ar wwnn
-.Op Fl O Ar pp|vp
+.Op Fl O Ar name=value
 .Op Fl p Ar targ_port
 .Op Fl r
 .Op Fl t Ar fe_type
@@ -625,7 +625,7 @@ The WWNN and WWPN may both be specified at the same time, 
but cannot be
 combined with enabling/disabling or listing ports.
 .Bl -tag -width 12n
 .It Fl c
-Create new frontend port using free pp and vp=0.
+Create new frontend port.
 .It Fl d Ar driver
 Specify the name of the frontend driver used by the
 .Pq Fl c
@@ -644,7 +644,31 @@ If no port number or port type is specified, all ports are 
turned on or
 off.
 .It Fl O Ar pp|vp
 Specify generic options on the ioctl frontend port.
-At present, only pp and vp port numbers can be set.
+The list of recognized options is driver-dependent.
+The
+.Dq ioctl
+driver recognizes
+.Dq pp
+and
+.Dq vp .
+The
+.Dq iscsi
+driver recongizes
+.Dq cfiscsi_portal_group_tag ,
+.Dq cfiscsi_target ,
+and
+.Dq cfiscsi_target_alias .
+The
+.Dq nvmf
+driver recognizes
+.Dq subnqn ,
+.Dq portid ,
+.Dq max_io_qsize ,
+.Dq enable_timeout ,
+.Dq ioccsz ,
+.Dq nn ,
+and
+.Dq serial .
 .It Fl p Ar targ_port
 Specify the frontend port number.
 The port numbers can be found in the frontend port list.
diff --git a/usr.sbin/ctladm/tests/port.sh b/usr.sbin/ctladm/tests/port.sh
index ccc4a6fc502e..1f2c9aaed5c1 100644
--- a/usr.sbin/ctladm/tests/port.sh
+++ b/usr.sbin/ctladm/tests/port.sh
@@ -5,11 +5,20 @@
 # * Creating umass ports
 
 # TODO
-# * Creating iscsi ports
 

git: 9747d11d9164 - main - Add some ATF tests for ctladm

[Alan Somers]

The branch main has been updated by asomers:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=9747d11d91642cb9b81602d88e8aebeb388543c7

commit 9747d11d91642cb9b81602d88e8aebeb388543c7
Author: Alan Somers 
AuthorDate: 2024-06-05 20:16:25 +
Commit: Alan Somers 
CommitDate: 2024-06-10 16:01:25 +

Add some ATF tests for ctladm

So far only "ctladm port -c" and "ctladm port -r" are covered.

MFC after:  2 weeks
Sponsored by:   Axcient
Reviewed by:mav
Pull Request:   https://github.com/freebsd/freebsd-src/pull/1279
---
 etc/mtree/BSD.tests.dist   |   2 +
 usr.sbin/ctladm/Makefile   |   3 +
 usr.sbin/ctladm/tests/Makefile |  10 +++
 usr.sbin/ctladm/tests/port.sh  | 155 +
 4 files changed, 170 insertions(+)

diff --git a/etc/mtree/BSD.tests.dist b/etc/mtree/BSD.tests.dist
index 3f447f9ec25e..86db4304b932 100644
--- a/etc/mtree/BSD.tests.dist
+++ b/etc/mtree/BSD.tests.dist
@@ -90,6 +90,8 @@
 ..
 ..
 usr.sbin
+ctladm
+..
 dtrace
 common
 aggs
diff --git a/usr.sbin/ctladm/Makefile b/usr.sbin/ctladm/Makefile
index 5e0df8065cce..b563891672be 100644
--- a/usr.sbin/ctladm/Makefile
+++ b/usr.sbin/ctladm/Makefile
@@ -23,4 +23,7 @@ MAN=  ctladm.8
 CFLAGS+=   -DWANT_ISCSI
 .endif
 
+HAS_TESTS=
+SUBDIR.${MK_TESTS}+=   tests
+
 .include 
diff --git a/usr.sbin/ctladm/tests/Makefile b/usr.sbin/ctladm/tests/Makefile
new file mode 100644
index ..73ac94d77d21
--- /dev/null
+++ b/usr.sbin/ctladm/tests/Makefile
@@ -0,0 +1,10 @@
+
+PACKAGE=   tests
+
+ATF_TESTS_SH=  port
+
+# "ctladm port" does not report the name of the port just created, so we can't
+# cleanup unless we assume that no other test created a port too.
+TEST_METADATA+= is_exclusive="true"
+
+.include 
diff --git a/usr.sbin/ctladm/tests/port.sh b/usr.sbin/ctladm/tests/port.sh
new file mode 100644
index ..b2cdea6f1de2
--- /dev/null
+++ b/usr.sbin/ctladm/tests/port.sh
@@ -0,0 +1,155 @@
+# Things that aren't tested due to lack of kernel support:
+# * Creating camsim ports
+# * Creating tpc ports
+# * Creating camtgt ports
+# * Creating umass ports
+
+# TODO
+# * Creating iscsi ports
+# * Creating nvmf ports
+# * Creating ha ports
+# * Creating fc ports
+
+skip_if_ctld() {
+   if service ctld onestatus > /dev/null; then
+   # If ctld is running on this server, let's not interfere.
+   atf_skip "Cannot run this test while ctld is running"
+   fi
+}
+
+cleanup() {
+   driver=$1
+
+   if [ -e after-ports ]; then
+   diff before-ports after-ports | awk "/$driver/ {print \$2}" | 
xargs -n1 ctladm port -r -d ioctl -p
+   fi
+}
+
+atf_test_case create_ioctl cleanup
+create_ioctl_head()
+{
+   atf_set "descr" "ctladm can create a new ioctl port"
+   atf_set "require.user" "root"
+}
+create_ioctl_body()
+{
+   skip_if_ctld
+
+   atf_check -o save:before-ports ctladm portlist -qf ioctl
+   atf_check ctladm port -c -d "ioctl"
+   atf_check -o save:after-ports ctladm portlist -qf ioctl
+   if test `wc -l before-ports | cut -w -f2` -ge `wc -l after-ports | cut 
-w -f2`; then
+   atf_fail "Did not create a new ioctl port"
+   fi
+}
+create_ioctl_cleanup()
+{
+   cleanup ioctl
+}
+
+atf_test_case create_ioctl_options cleanup
+create_ioctl_options_head()
+{
+   atf_set "descr" "ctladm can set options when creating a new ioctl port"
+   atf_set "require.user" "root"
+}
+create_ioctl_options_body()
+{
+   skip_if_ctld
+
+   atf_check -o save:before-ports ctladm portlist -qf ioctl
+   atf_check ctladm port -c -d "ioctl" -O pp=101 -O vp=102
+   atf_check -o save:after-ports ctladm portlist -qf ioctl
+   if test `wc -l before-ports | cut -w -f2` -ge `wc -l after-ports | cut 
-w -f2`; then
+   atf_fail "Did not create a new ioctl port"
+   fi
+   if ! egrep -q '101[[:space:]]+102' after-ports; then
+   ctladm portlist
+   atf_fail "Did not create the port with the specified options"
+   fi
+}
+create_ioctl_options_cleanup()
+{
+   cleanup ioctl
+}
+
+
+atf_test_case disable_ioctl cleanup
+disable_ioctl_head()
+{
+   atf_set "descr" "ctladm can disable an ioctl port"
+   atf_set "require.user" "root"
+}
+disable_ioctl_body()
+{
+   skip_if_ctld
+
+   atf_check -o save:before-ports ctladm portlist -qf ioctl
+   atf_check ctladm port -c -d "ioctl"
+   atf_check -o save:after-ports ctladm portlist -qf ioctl
+   if test `wc -l before-ports | cut -w -f2` -ge `wc -l after-ports | cut 
-w -f2`; then
+   atf_

git: 591de7534fb3 - main - ctladm: print port number with a succesful "port -c" command

[Alan Somers]

The branch main has been updated by asomers:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=591de7534fb3acb2e6eef94a1e5e92000d2cf83d

commit 591de7534fb3acb2e6eef94a1e5e92000d2cf83d
Author: Alan Somers 
AuthorDate: 2024-06-05 23:54:46 +
Commit: Alan Somers 
CommitDate: 2024-06-10 16:01:25 +

ctladm: print port number with a succesful "port -c" command

Make "ctladm port -c" print the port number of the newly successful
port.  This way it won't have to be guessed by a subsequent "ctladm
portlist" command.  That means it's safe to use it concurrently with
other ctladm processes.  In particular, this allows the tests to be run
in parallel.

MFC after:  2 weeks
Sponsored by:   Axcient
Reviewed by:mav
Pull Request:   https://github.com/freebsd/freebsd-src/pull/1279
---
 usr.sbin/ctladm/ctladm.c   | 18 +++
 usr.sbin/ctladm/tests/Makefile |  4 ---
 usr.sbin/ctladm/tests/port.sh  | 70 --
 3 files changed, 52 insertions(+), 40 deletions(-)

diff --git a/usr.sbin/ctladm/ctladm.c b/usr.sbin/ctladm/ctladm.c
index 28f9a39386d3..14951797ddf1 100644
--- a/usr.sbin/ctladm/ctladm.c
+++ b/usr.sbin/ctladm/ctladm.c
@@ -397,7 +397,9 @@ static struct ctladm_opts cctl_fe_table[] = {
 static int
 cctl_port(int fd, int argc, char **argv, char *combinedopt)
 {
+   char result_buf[1024];
int c;
+   uint64_t created_port = -1;
int32_t targ_port = -1;
int retval = 0;
int wwnn_set = 0, wwpn_set = 0;
@@ -587,6 +589,8 @@ cctl_port(int fd, int argc, char **argv, char *combinedopt)
case CCTL_PORT_MODE_CREATE: {
bzero(, sizeof(req));
strlcpy(req.driver, driver, sizeof(req.driver));
+   req.result = result_buf;
+   req.result_len = sizeof(result_buf);
 
if (port_mode == CCTL_PORT_MODE_REMOVE) {
req.reqtype = CTL_REQ_REMOVE;
@@ -619,6 +623,20 @@ cctl_port(int fd, int argc, char **argv, char *combinedopt)
warnx("warning: %s", req.error_str);
break;
case CTL_LUN_OK:
+   if (port_mode == CCTL_PORT_MODE_CREATE) {
+   req.result_nvl = nvlist_unpack(result_buf, 
req.result_len, 0);
+   if (req.result_nvl == NULL) {
+   warnx("error unpacking result nvlist");
+   break;
+   }
+   created_port = 
nvlist_get_number(req.result_nvl, "port_id");
+   printf("Port created successfully\n"
+   "frontend: %s\n"
+   "port: %ju\n", driver,
+   (uintmax_t) created_port);
+   nvlist_destroy(req.result_nvl);
+   } else
+   printf("Port destroyed successfully\n");
break;
default:
warnx("unknown status: %d", req.status);
diff --git a/usr.sbin/ctladm/tests/Makefile b/usr.sbin/ctladm/tests/Makefile
index 73ac94d77d21..825e38e6c6e3 100644
--- a/usr.sbin/ctladm/tests/Makefile
+++ b/usr.sbin/ctladm/tests/Makefile
@@ -3,8 +3,4 @@ PACKAGE=tests
 
 ATF_TESTS_SH=  port
 
-# "ctladm port" does not report the name of the port just created, so we can't
-# cleanup unless we assume that no other test created a port too.
-TEST_METADATA+= is_exclusive="true"
-
 .include 
diff --git a/usr.sbin/ctladm/tests/port.sh b/usr.sbin/ctladm/tests/port.sh
index b2cdea6f1de2..ccc4a6fc502e 100644
--- a/usr.sbin/ctladm/tests/port.sh
+++ b/usr.sbin/ctladm/tests/port.sh
@@ -20,8 +20,9 @@ skip_if_ctld() {
 cleanup() {
driver=$1
 
-   if [ -e after-ports ]; then
-   diff before-ports after-ports | awk "/$driver/ {print \$2}" | 
xargs -n1 ctladm port -r -d ioctl -p
+   if [ -e port-create.txt ]; then
+   portnum=`awk '/port:/ {print $2}' port-create.txt`
+   ctladm port -r -d $driver -p $portnum
fi
 }
 
@@ -35,12 +36,13 @@ create_ioctl_body()
 {
skip_if_ctld
 
-   atf_check -o save:before-ports ctladm portlist -qf ioctl
-   atf_check ctladm port -c -d "ioctl"
-   atf_check -o save:after-ports ctladm portlist -qf ioctl
-   if test `wc -l before-ports | cut -w -f2` -ge `wc -l after-ports | cut 
-w -f2`; then
-   atf_fail "Did not create a new ioctl port"
-   fi
+   atf_check -o save:port-create.txt ctladm port -c -d "ioctl"
+   atf_check egrep -q "Port created successfully" port-create.txt
+   atf_check eg

git: 9747d11d9164 - main - Add some ATF tests for ctladm

[Alan Somers]

The branch main has been updated by asomers:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=9747d11d91642cb9b81602d88e8aebeb388543c7

commit 9747d11d91642cb9b81602d88e8aebeb388543c7
Author: Alan Somers 
AuthorDate: 2024-06-05 20:16:25 +
Commit: Alan Somers 
CommitDate: 2024-06-10 16:01:25 +

Add some ATF tests for ctladm

So far only "ctladm port -c" and "ctladm port -r" are covered.

MFC after:  2 weeks
Sponsored by:   Axcient
Reviewed by:mav
Pull Request:   https://github.com/freebsd/freebsd-src/pull/1279
---
 etc/mtree/BSD.tests.dist   |   2 +
 usr.sbin/ctladm/Makefile   |   3 +
 usr.sbin/ctladm/tests/Makefile |  10 +++
 usr.sbin/ctladm/tests/port.sh  | 155 +
 4 files changed, 170 insertions(+)

diff --git a/etc/mtree/BSD.tests.dist b/etc/mtree/BSD.tests.dist
index 3f447f9ec25e..86db4304b932 100644
--- a/etc/mtree/BSD.tests.dist
+++ b/etc/mtree/BSD.tests.dist
@@ -90,6 +90,8 @@
 ..
 ..
 usr.sbin
+ctladm
+..
 dtrace
 common
 aggs
diff --git a/usr.sbin/ctladm/Makefile b/usr.sbin/ctladm/Makefile
index 5e0df8065cce..b563891672be 100644
--- a/usr.sbin/ctladm/Makefile
+++ b/usr.sbin/ctladm/Makefile
@@ -23,4 +23,7 @@ MAN=  ctladm.8
 CFLAGS+=   -DWANT_ISCSI
 .endif
 
+HAS_TESTS=
+SUBDIR.${MK_TESTS}+=   tests
+
 .include 
diff --git a/usr.sbin/ctladm/tests/Makefile b/usr.sbin/ctladm/tests/Makefile
new file mode 100644
index ..73ac94d77d21
--- /dev/null
+++ b/usr.sbin/ctladm/tests/Makefile
@@ -0,0 +1,10 @@
+
+PACKAGE=   tests
+
+ATF_TESTS_SH=  port
+
+# "ctladm port" does not report the name of the port just created, so we can't
+# cleanup unless we assume that no other test created a port too.
+TEST_METADATA+= is_exclusive="true"
+
+.include 
diff --git a/usr.sbin/ctladm/tests/port.sh b/usr.sbin/ctladm/tests/port.sh
new file mode 100644
index ..b2cdea6f1de2
--- /dev/null
+++ b/usr.sbin/ctladm/tests/port.sh
@@ -0,0 +1,155 @@
+# Things that aren't tested due to lack of kernel support:
+# * Creating camsim ports
+# * Creating tpc ports
+# * Creating camtgt ports
+# * Creating umass ports
+
+# TODO
+# * Creating iscsi ports
+# * Creating nvmf ports
+# * Creating ha ports
+# * Creating fc ports
+
+skip_if_ctld() {
+   if service ctld onestatus > /dev/null; then
+   # If ctld is running on this server, let's not interfere.
+   atf_skip "Cannot run this test while ctld is running"
+   fi
+}
+
+cleanup() {
+   driver=$1
+
+   if [ -e after-ports ]; then
+   diff before-ports after-ports | awk "/$driver/ {print \$2}" | 
xargs -n1 ctladm port -r -d ioctl -p
+   fi
+}
+
+atf_test_case create_ioctl cleanup
+create_ioctl_head()
+{
+   atf_set "descr" "ctladm can create a new ioctl port"
+   atf_set "require.user" "root"
+}
+create_ioctl_body()
+{
+   skip_if_ctld
+
+   atf_check -o save:before-ports ctladm portlist -qf ioctl
+   atf_check ctladm port -c -d "ioctl"
+   atf_check -o save:after-ports ctladm portlist -qf ioctl
+   if test `wc -l before-ports | cut -w -f2` -ge `wc -l after-ports | cut 
-w -f2`; then
+   atf_fail "Did not create a new ioctl port"
+   fi
+}
+create_ioctl_cleanup()
+{
+   cleanup ioctl
+}
+
+atf_test_case create_ioctl_options cleanup
+create_ioctl_options_head()
+{
+   atf_set "descr" "ctladm can set options when creating a new ioctl port"
+   atf_set "require.user" "root"
+}
+create_ioctl_options_body()
+{
+   skip_if_ctld
+
+   atf_check -o save:before-ports ctladm portlist -qf ioctl
+   atf_check ctladm port -c -d "ioctl" -O pp=101 -O vp=102
+   atf_check -o save:after-ports ctladm portlist -qf ioctl
+   if test `wc -l before-ports | cut -w -f2` -ge `wc -l after-ports | cut 
-w -f2`; then
+   atf_fail "Did not create a new ioctl port"
+   fi
+   if ! egrep -q '101[[:space:]]+102' after-ports; then
+   ctladm portlist
+   atf_fail "Did not create the port with the specified options"
+   fi
+}
+create_ioctl_options_cleanup()
+{
+   cleanup ioctl
+}
+
+
+atf_test_case disable_ioctl cleanup
+disable_ioctl_head()
+{
+   atf_set "descr" "ctladm can disable an ioctl port"
+   atf_set "require.user" "root"
+}
+disable_ioctl_body()
+{
+   skip_if_ctld
+
+   atf_check -o save:before-ports ctladm portlist -qf ioctl
+   atf_check ctladm port -c -d "ioctl"
+   atf_check -o save:after-ports ctladm portlist -qf ioctl
+   if test `wc -l before-ports | cut -w -f2` -ge `wc -l after-ports | cut 
-w -f2`; then
+   atf_

Re: RFR: 8333344: JMX attaching of Subject does not work when security manager not allowed

[Alan Bateman]

On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls  wrote:

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of 
> AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  
> -Djava.security.manager=allow to use JMX authentication.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
 line 1634:

> 1632: } else {
> 1633: // We have ACC therefore SM is permitted, and 
> Subject must be non-null:
> 1634: return Subject.doAs(subject, 
> (PrivilegedExceptionAction) () -> 
> AccessController.doPrivileged((PrivilegedExceptionAction) () -> 
> wrappedClass.cast(mo.get()), acc));

This is not readable. If you create the PAEs explicitly then the casts will go 
away and it will be much easier to read.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1633351429

Re: jmx-dev RFR: 8333344: JMX attaching of Subject does not work when security manager not allowed

[Alan Bateman]

On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls  wrote:

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of 
> AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  
> -Djava.security.manager=allow to use JMX authentication.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
 line 1634:

> 1632: } else {
> 1633: // We have ACC therefore SM is permitted, and 
> Subject must be non-null:
> 1634: return Subject.doAs(subject, 
> (PrivilegedExceptionAction) () -> 
> AccessController.doPrivileged((PrivilegedExceptionAction) () -> 
> wrappedClass.cast(mo.get()), acc));

This is not readable. If you create the PAEs explicitly then the casts will go 
away and it will be much easier to read.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1633351429

Re: RFR: 8333344: JMX attaching of Subject does not work when security manager not allowed

[Alan Bateman]

On Mon, 10 Jun 2024 11:28:28 GMT, Kevin Walls  wrote:

> JMX uses APIs related to the Security Mananger which are deprecated.  Use of 
> AccessControlContext will be removed when Security Manager is removed.
> 
> Until then, updates are needed to not require setting  
> -Djava.security.manager=allow to use JMX authentication.

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
 line 1634:

> 1632: } else {
> 1633: // We have ACC therefore SM is permitted, and 
> Subject must be non-null:
> 1634: return Subject.doAs(subject, 
> (PrivilegedExceptionAction) () -> 
> AccessController.doPrivileged((PrivilegedExceptionAction) () -> 
> wrappedClass.cast(mo.get()), acc));

This is not readable. If you create the PAEs explicitly then the casts will go 
away and it will be much easier to read.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19624#discussion_r1633351429

Re: [PATCH] monitor: Remove obsolete stubs

[Dr. David Alan Gilbert]

* Philippe Mathieu-Daudé (phi...@linaro.org) wrote:
> hmp_info_roms() was removed in commit dd98234c05 ("qapi:
> introduce x-query-roms QMP command"),
> 
> hmp_info_numa() in commit 1b8ae799d8 ("qapi: introduce
> x-query-numa QMP command"),
> 
> hmp_info_ramblock() in commit ca411b7c8a ("qapi: introduce
> x-query-ramblock QMP command")
> 
> and hmp_info_irq() in commit 91f2fa7045 ("qapi: introduce
> x-query-irq QMP command").
> 
> Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Dr. David Alan Gilbert 

> ---
> Note x-query-roms is used as example in
> docs/devel/writing-monitor-commands.rst
> but was removed in commit dd98234c05
> ("qapi: introduce x-query-roms QMP command").
> ---
>  include/hw/loader.h   | 1 -
>  include/monitor/hmp.h | 3 ---
>  2 files changed, 4 deletions(-)
> 
> diff --git a/include/hw/loader.h b/include/hw/loader.h
> index 8685e27334..9844c5e3cf 100644
> --- a/include/hw/loader.h
> +++ b/include/hw/loader.h
> @@ -338,7 +338,6 @@ void *rom_ptr(hwaddr addr, size_t size);
>   * rom_ptr().
>   */
>  void *rom_ptr_for_as(AddressSpace *as, hwaddr addr, size_t size);
> -void hmp_info_roms(Monitor *mon, const QDict *qdict);
>  
>  #define rom_add_file_fixed(_f, _a, _i)  \
>  rom_add_file(_f, NULL, _a, _i, false, NULL, NULL)
> diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
> index 954f3c83ad..ae116d9804 100644
> --- a/include/monitor/hmp.h
> +++ b/include/monitor/hmp.h
> @@ -35,7 +35,6 @@ void hmp_info_cpus(Monitor *mon, const QDict *qdict);
>  void hmp_info_vnc(Monitor *mon, const QDict *qdict);
>  void hmp_info_spice(Monitor *mon, const QDict *qdict);
>  void hmp_info_balloon(Monitor *mon, const QDict *qdict);
> -void hmp_info_irq(Monitor *mon, const QDict *qdict);
>  void hmp_info_pic(Monitor *mon, const QDict *qdict);
>  void hmp_info_pci(Monitor *mon, const QDict *qdict);
>  void hmp_info_tpm(Monitor *mon, const QDict *qdict);
> @@ -102,7 +101,6 @@ void hmp_chardev_send_break(Monitor *mon, const QDict 
> *qdict);
>  void hmp_object_add(Monitor *mon, const QDict *qdict);
>  void hmp_object_del(Monitor *mon, const QDict *qdict);
>  void hmp_info_memdev(Monitor *mon, const QDict *qdict);
> -void hmp_info_numa(Monitor *mon, const QDict *qdict);
>  void hmp_info_memory_devices(Monitor *mon, const QDict *qdict);
>  void hmp_qom_list(Monitor *mon, const QDict *qdict);
>  void hmp_qom_get(Monitor *mon, const QDict *qdict);
> @@ -141,7 +139,6 @@ void hmp_rocker_ports(Monitor *mon, const QDict *qdict);
>  void hmp_rocker_of_dpa_flows(Monitor *mon, const QDict *qdict);
>  void hmp_rocker_of_dpa_groups(Monitor *mon, const QDict *qdict);
>  void hmp_info_dump(Monitor *mon, const QDict *qdict);
> -void hmp_info_ramblock(Monitor *mon, const QDict *qdict);
>  void hmp_hotpluggable_cpus(Monitor *mon, const QDict *qdict);
>  void hmp_info_vm_generation_id(Monitor *mon, const QDict *qdict);
>  void hmp_info_memory_size_summary(Monitor *mon, const QDict *qdict);
> -- 
> 2.41.0
> 
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Re: [PATCH-for-9.1 v2 2/3] migration: Remove RDMA protocol handling

[Dr. David Alan Gilbert]

* Peter Xu (pet...@redhat.com) wrote:
> Hey, Dave!

Hey!

> On Wed, Jun 05, 2024 at 12:31:56AM +, Dr. David Alan Gilbert wrote:
> > * Michael Galaxy (mgal...@akamai.com) wrote:
> > > One thing to keep in mind here (despite me not having any hardware to 
> > > test)
> > > was that one of the original goals here
> > > in the RDMA implementation was not simply raw throughput nor raw latency,
> > > but a lack of CPU utilization in kernel
> > > space due to the offload. While it is entirely possible that newer 
> > > hardware
> > > w/ TCP might compete, the significant
> > > reductions in CPU usage in the TCP/IP stack were a big win at the time.
> > > 
> > > Just something to consider while you're doing the testing
> > 
> > I just noticed this thread; some random notes from a somewhat
> > fragmented memory of this:
> > 
> >   a) Long long ago, I also tried rsocket; 
> >   https://lists.gnu.org/archive/html/qemu-devel/2015-01/msg02040.html
> >  as I remember the library was quite flaky at the time.
> 
> Hmm interesting.  There also looks like a thread doing rpoll().

Yeh, I can't actually remember much more about what I did back then!

> Btw, not sure whether you noticed, but there's the series posted for the
> latest rsocket conversion here:
> 
> https://lore.kernel.org/r/1717503252-51884-1-git-send-email-arei.gong...@huawei.com

Oh I hadn't; I think all of the stack of qemu's file abstractions had
changed in the ~10 years since I wrote my version!

> I hope Lei and his team has tested >4G mem, otherwise definitely worth
> checking.  Lei also mentioned there're rsocket bugs they found in the cover
> letter, but not sure what's that about.

It would probably be a good idea to keep track of what bugs
are in flight with it, and try it on a few RDMA cards to see
what problems get triggered.
I think I reported a few at the time, but I gave up after
feeling it was getting very hacky.

> Yes, and zero-copy requires multifd for now. I think it's because we didn't
> want to complicate the header processings in the migration stream where it
> may not be page aligned.

Ah yes.

> > 
> >   e) Someone made a good suggestion (sorry can't remember who) - that the
> >  RDMA migration structure was the wrong way around - it should be the
> >  destination which initiates an RDMA read, rather than the source
> >  doing a write; then things might become a LOT simpler; you just need
> >  to send page ranges to the destination and it can pull it.
> >  That might work nicely for postcopy.
> 
> I'm not sure whether it'll still be a problem if rdma recv side is based on
> zero-copy.  It would be a matter of whether atomicity can be guaranteed so
> that we don't want the guest vcpus to see a partially copied page during
> on-flight DMAs.  UFFDIO_COPY (or friend) is currently the only solution for
> that.

Yes, but even ignoring that (and the UFFDIO_CONTINUE idea you mention), if
the destination can issue an RDMA read itself, it doesn't need to send messages
to the source to ask for a page fetch; it just goes and grabs it itself,
that's got to be good for latency.

Dave

> 
> Thanks,
> 
> -- 
> Peter Xu
> 
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Re: [PATCH 0/4] hw/s390x: Alias @dump-skeys -> @dump-s390-skey and deprecate

[Dr. David Alan Gilbert]

* Markus Armbruster (arm...@redhat.com) wrote:
> Philippe Mathieu-Daudé  writes:
> 
> > Hi Daniel, Dave, Markus & Thomas.
> >
> > On 4/6/24 06:58, Markus Armbruster wrote:
> >> "Dr. David Alan Gilbert"  writes:
> >>> * Daniel P. Berrangé (berra...@redhat.com) wrote:
> >>>> On Fri, May 31, 2024 at 06:47:45AM +0200, Thomas Huth wrote:
> >>>>> On 30/05/2024 09.45, Philippe Mathieu-Daudé wrote:
> >>>>>> We are trying to unify all qemu-system-FOO to a single binary.
> >>>>>> In order to do that we need to remove QAPI target specific code.
> >>>>>>
> >>>>>> @dump-skeys is only available on qemu-system-s390x. This series
> >>>>>> rename it as @dump-s390-skey, making it available on other
> >>>>>> binaries. We take care of backward compatibility via deprecation.
> >>>>>>
> >>>>>> Philippe Mathieu-Daudé (4):
> >>>>>> hw/s390x: Introduce the @dump-s390-skeys QMP command
> >>>>>> hw/s390x: Introduce the 'dump_s390_skeys' HMP command
> >>>>>> hw/s390x: Deprecate the HMP 'dump_skeys' command
> >>>>>> hw/s390x: Deprecate the QMP @dump-skeys command
> >>>>>
> >>>>> Why do we have to rename the command? Just for the sake of it? I think
> >>>>> renaming HMP commands is maybe ok, but breaking the API in QMP is 
> >>>>> something
> >>>>> you should consider twice.
> >
> > I'm looking at how to include this command in the new "single binary".
> >
> > Markus explained in an earlier series, just expanding this command as
> > stub to targets that don't implement it is not backward compatible and
> > breaks QMP introspection. Currently on s390x we get a result, on other
> > targets the command doesn't exist. If we add a stubs, then other targets
> > return something (even if it is an empty list), confusing management
> > interface.
> 
> Loss of introspection precision is a concern, not a hard "no".
> 
> We weigh all the concerns, and pick a solution we hate the least :)
> 
> > So this approach use to deprecate process to include a new command
> > which behaves differently on non-s390x targets.
> >
> > If we don't care for this particular case, better. However I'd still
> > like to discuss this approach for other target-specific commands.
> >
> >> PRO rename: the command's tie to S390 is them immediately obvious, which
> >> may be useful when the command becomes available in qemu-systems capable
> >> of running other targets.
> >>
> >> CON rename: users need to adapt.
> >>
> >> What are the users?  Not libvirt, as far as I can tell.
> >
> > Years ago we said, "all HMP must be based on QMP".
> 
> In practice, it's closer to "HMP must be base on QMP when the
> functionality does or should exist in QMP."
> 
> >Now we realize HMP
> > became stable because QMP-exposed, although not consumed externally...
> 
> I'm afraid I didn't get this part.
> 
> > Does the concept of "internal QMP commands" makes sense for HMP debug
> > ones? (Looking at a way to not expose them). We could use the "x-"
> > prefix to not care about stable / backward compat, but what is the point
> > of exposing to QMP commands that will never be accessed there?
> >
> >>>> That was going to be my question too. Seems like its possible to simply
> >>>> stub out the existing command for other targets.
> >>
> >> That's going to happen whether we rename the commands or not.
> >> 
> >>> Are these commands really supposed to be stable, or are they just debug
> >>> commands?  If they are debug, then add the x- and don't worry too much.
> >
> > OK.
> >
> >> docs/devel/qapi-code-gen.rst:
> >>
> >>  Names beginning with ``x-`` used to signify "experimental".  This
> >>  convention has been replaced by special feature "unstable".
> >>
> >> Feature "unstable" is what makes something unstable, and is what
> >> machines should check.
> >
> > What I mentioned earlier could be 'Feature "internal" or "debug"'.
> 
> What's the difference to "unstable"?

It should be clear *why* something is marked x- - something that's
marked 'x-' because the featu

Re: [PATCH-for-9.1 v2 2/3] migration: Remove RDMA protocol handling

[Dr. David Alan Gilbert]

 DPU card.
> > > > 
> > > > > > In some scenarios where fast live migration is needed (extremely 
> > > > > > short
> > > > > > interruption duration and migration duration) is very useful. To 
> > > > > > this
> > > > > > end, we have also developed RDMA support for multifd.
> > > > > Will any of you upstream that work?  I'm curious how intrusive would 
> > > > > it be
> > > > > when adding it to multifd, if it can keep only 5 exported functions 
> > > > > like what
> > > > > rdma.h does right now it'll be pretty nice.  We also want to make 
> > > > > sure it works
> > > > > with arbitrary sized loads and buffers, e.g. vfio is considering to 
> > > > > add IO loads to
> > > > > multifd channels too.
> > > > > 
> > > > In fact, we sent the patchset to the community in 2021. Pls see:
> > > > https://urldefense.com/v3/__https://lore.kernel.org/all/20210203185906.GT2950@work-vm/T/__;!!GjvTz_vk!VfP_SV-8uRya7rBdopv8OUJkmnSi44Ktpqq1E7sr_Xcwt6zvveW51qboWOBSTChdUG1hJwfAl7HZl4NUEGc$
> > Yes, I have sent the patchset of multifd support for rdma migration by 
> > taking over my colleague, and also
> > sorry for not keeping on this work at that time due to some reasons.
> > And also I am strongly agree with Lei that the RDMA protocol has some 
> > special advantages against with TCP
> > in some scenario, and we are indeed to use it in our product.
> > 
> > > I wasn't aware of that for sure in the past..
> > > 
> > > Multifd has changed quite a bit in the last 9.0 release, that may not 
> > > apply
> > > anymore.  One thing to mention is please look at Dan's comment on possible
> > > use of rsocket.h:
> > > 
> > > https://urldefense.com/v3/__https://lore.kernel.org/all/zjjm6rcqs5eho...@redhat.com/__;!!GjvTz_vk!VfP_SV-8uRya7rBdopv8OUJkmnSi44Ktpqq1E7sr_Xcwt6zvveW51qboWOBSTChdUG1hJwfAl7HZ0CFSE-o$
> > > 
> > > And Jinpu did help provide an initial test result over the library:
> > > 
> > > https://urldefense.com/v3/__https://lore.kernel.org/qemu-devel/camgffek8wiknqmouyxcathgtiem2dwocf_w7t0vmcd-i30t...@mail.gmail.com/__;!!GjvTz_vk!VfP_SV-8uRya7rBdopv8OUJkmnSi44Ktpqq1E7sr_Xcwt6zvveW51qboWOBSTChdUG1hJwfAl7HZxPNcdb4$
> > > 
> > > It looks like we have a chance to apply that in QEMU.
> > > 
> > > > 
> > > > > One thing to note that the question here is not about a pure 
> > > > > performance
> > > > > comparison between rdma and nics only.  It's about help us make a 
> > > > > decision
> > > > > on whether to drop rdma, iow, even if rdma performs well, the 
> > > > > community still
> > > > > has the right to drop it if nobody can actively work and maintain it.
> > > > > It's just that if nics can perform as good it's more a reason to 
> > > > > drop, unless
> > > > > companies can help to provide good support and work together.
> > > > > 
> > > > We are happy to provide the necessary review and maintenance work for 
> > > > RDMA
> > > > if the community needs it.
> > > > 
> > > > CC'ing Chuan Zheng.
> > > I'm not sure whether you and Jinpu's team would like to work together and
> > > provide a final solution for rdma over multifd.  It could be much simpler
> > > than the original 2021 proposal if the rsocket API will work out.
> > > 
> > > Thanks,
> > > 
> > That's a good news to see the socket abstraction for RDMA!
> > When I was developed the series above, the most pain is the RDMA migration 
> > has no QIOChannel abstraction and i need to take a 'fake channel'
> > for it which is awkward in code implementation.
> > So, as far as I know, we can do this by
> > i. the first thing is that we need to evaluate the rsocket is good enough 
> > to satisfy our QIOChannel fundamental abstraction
> > ii. if it works right, then we will continue to see if it can give us 
> > opportunity to hide the detail of rdma protocol
> >  into rsocket by remove most of code in rdma.c and also some hack in 
> > migration main process.
> > iii. implement the advanced features like multi-fd and multi-uri for rdma 
> > migration.
> > 
> > Since I am not familiar with rsocket, I need some times to look at it and 
> > do some quick verify with rdma migration based on rsocket.
> > But, yes, I am willing to involved in this refactor work and to see if we 
> > can make this migration feature more better:）
> > 
> > 
> 
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Re: RFR: 8330205: Initial troff manpage generation for JDK 24

[Alan Bateman]

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes  wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in 
> java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default @since for a nested class to that of its 
> enclosing class
> 
> Thanks

Marked as reviewed by alanb (Reviewer).

-

PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2106832118

Re: RFR: 8330205: Initial troff manpage generation for JDK 24

[Alan Bateman]

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes  wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in 
> java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default @since for a nested class to that of its 
> enclosing class
> 
> Thanks

Marked as reviewed by alanb (Reviewer).

-

PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2106832118

Re: RFR: 8330205: Initial troff manpage generation for JDK 24

[Alan Bateman]

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes  wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in 
> java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default @since for a nested class to that of its 
> enclosing class
> 
> Thanks

Marked as reviewed by alanb (Reviewer).

-

PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2106832118

Re: RFR: 8330205: Initial troff manpage generation for JDK 24

[Alan Bateman]

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes  wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in 
> java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default @since for a nested class to that of its 
> enclosing class
> 
> Thanks

Marked as reviewed by alanb (Reviewer).

-

PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2106832118

Re: RFR: 8330205: Initial troff manpage generation for JDK 24

[Alan Bateman]

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes  wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in 
> java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default @since for a nested class to that of its 
> enclosing class
> 
> Thanks

Marked as reviewed by alanb (Reviewer).

-

PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2106832118

[NetBehaviour] the stay , a narrative

[Alan Sondheim via NetBehaviour]

the stay , a narrative

https://youtu.be/FVwgccY8Coc video

OK, we'll just stay or will this go period shall I stay or shall
I go period will they come or will they go period is this moving
a resiststationary period no, that's wrong. Uh, take that back
period is this. Is this moving or is this still period is it
still moving or is this moving stills period that's better
period So this is another adventure into the dissolution of
language and specific content. Specific objects, specific. Genre
fixed John Rose specific notions of what is or is not an object
or what is or is not a barrier or what is or is not.  A
classification or what is or is not something complete period
obviously one can say nothing is ever complete period I'll go
along with that period this is certainly a complete period this
is definitely a complete period this is why it's called the stay
because it's days period but it's so a femoral it will
disappear.  God knows how soon it all disappears period I can
guarantee we'll be going alone before this one period

___
NetBehaviour mailing list
NetBehaviour@lists.netbehaviour.org
https://lists.netbehaviour.org/mailman/listinfo/netbehaviour

Re: [NetBehaviour] dark rasa / sickness

[Alan Sondheim via NetBehaviour]

i'd go for the anti-fascist rhetoric to be sure!

On Thu, 6 Jun 2024, Mark Hancock via NetBehaviour wrote:


Date: Thu, 6 Jun 2024 09:13:59 +0100
From: Mark Hancock via NetBehaviour 
To: NetBehaviour for networked distributed creativity

Cc: Mark Hancock 
Subject: Re: [NetBehaviour] dark rasa / sickness

Hey Alan,
I second Agee's comment, keep posting.

Frankly, (based on my social media) if I were to post regularly, it would
mostly be adolescent fart jokes, anti-fascist rhetoric, and about once every
6 weeks, a piece of video art.

I suspect that only two of those would be welcome. And I'm not sure about
the anti-fascist rhetoric.

Love to all wherever and whatever you're going through right now.

Mark

On Thu, 6 Jun 2024 at 08:00, AGF  wrote:
  hi dear, your posts are welcome!
  agee

  > On 6. Jun 2024, at 6.56, Alan Sondheim via NetBehaviour
   wrote:
  >
  >
  > */i'm honestly not trying to dominate this list, i am more
  than
  > willing to stop posting here if others will post, sad to see
  this
  > quiet/*
  >
  > dark rasa / sickness
  >
  > https://youtu.be/IkW_-wzOIgY video
  >
  > Experiments possible worlds and natural kinds are exhausted,
  i'm
  > so tired now, editing, listening, with phenomena, exhausted
  with
  > debris, granular, articulation, sick with phenomena, exhausted
  > with debris, granular, exhausted, afterthoughts, contraries,
  > waywards, unutterables, hirsute, ill, sick with phenomena,
  > exhausted with debris, exhausted as usual, moody as usual.
  Been
  > reading Giorgio Agam- fall to the ground . they're so tired of
  > shooting machinery. exhausted being. what "out there" never
  > "what," there"; what's the tiredness didn't notice anything.
  But
  > one thing I can continue to a tired keening. The corpse is
  mine,
  > jus a hhngar for sleep; always exhausted, my judgamant ls not
  of
  > tha exhausted with debris, granular, articulation,
  catastrophic
  > and too tired to think about it. The last section of the music
  > Your psychotic other other people. I'm tired of being inserted
  > have exhausted me; diary have nothing to say, have exhausted
  > signals. we have exhausted ourselves. we have exhausted me,
  none
  > of object or subject, waves which dissolve as if exhausted
  > tended get get of rid weak weak exhausted people by exhausted
  > there is, nothing more; it exhausts itself and is exhausted
  and
  > needed medical attention soon. They also felt exhausted and sm
  > exits in name only, and tired bartenders pour wine and
  dreaming
  > beside the gendered or exhausted body (the second the obdurate
  > and obstructive real, absorb the exhausted language so tired
  > from working and worrying this particular video of the I'm
  still
  > exhausted a lot of the time. I don't seem to be able I'm so
  > tired of these shapes which seem inconceivable catastrophe
  > theory exhausted within and without an inconceivable give
  devils
  > their side: less, exhausted, myriad beings while anything,
  > plague increased less, exhausted, myriad beings while ers are
  > there numbers here I'm so tired of this please tell me tired
  of
  > defending myself. stdin. i'm tired of armageddon andre a joke
  > ers are there numbers here I'm so tired of this please
  > limitless, collapsing, extinguishing./* exhausted discoruse
  you
  > looking for numbers are there numbers here I'm so tired of
  > significant effects, the name Agnes was retired in the spring
  of
  > complaynt as it might be written, people are tired of reading
  > the left and the other other people. I'm tired of being
  >
  > I am tired as a car, but I'm not falling asleep. I'm following
  > being out w/ long covid, so tired of saying there's not much
  to
  > go on I'm so tired of these shapes which It's completely
  > understandable to feel tired, and typing with ers tired Hoq
  sis
  > qhf fwr rlal qhwn yuou ewnor nar ro muxh did this and I'm
  wrong
  > in it where is I'm so tired I can't think less, exhausted,
  > myriad beings while is warfare, by P or global decathected,
  > defuge, exhausted: the Border - the ontological otherthe
  > people.other tiredI'm inserted finalthe realmfinal when we're
  > talking I'm lucky that they're so damn tired when I'm number
  I'm
  > getting a lot of these I'm so tired damn it I'm glitch, cata
  > theory exhausted within and without an exhausted?Wed Mar 27
  > 14:28:25 EDT 2024 must i continue, what can This

[gentoo-user] major problem with X keyborad.

[Alan Grimes]

The standard control keys aren't working in X anymore, mainly the arrow 
keys and normal edit buttons, workaround is to use the numpad. Keys are 
functional as tested from normal linux console.  Problem started when I 
rebooted after the emptytree world build the other day due to the stupid 
profile change


I have to run this manually at x launch because xorg.conf stopped 
honoring keymaps:


setxkbmap -layout us -variant dvorak

Once again, the penguins invent a new and innovative way to fail in a 
way that I had not previously imagined possible


--
You can't out-crazy a Democrat.
#EggCrisis  #BlackWinter
White is the new Kulak.
Powers are not rights.

[oss-security] vte 0.76.3 released with fix for CVE-2024-37535

[Alan Coopersmith]

https://www.cve.org/CVERecord?id=CVE-2024-37535 states:

GNOME VTE before 0.76.3 allows an attacker to cause a denial of service 
(memory consumption) via a window resize escape sequence, a related issue

to CVE-2000-0476.


https://gitlab.gnome.org/GNOME/vte/-/issues/2786 explains further:


The ANSI escape sequence "e[4;;t" can be used to resize the terminal
window, where "" is the height and ""is the width. By providing a
large number such as 65535 for both values will lead to a local denial
of service, where the whole machine can be frozen.

This same vulnerability found was in XTerm back in 2000. The CVE for
the vulnerability in XTerm is CVE-2000-0476

Steps to reproduce:

Open gnome-terminal
Execute printf "e[4;65535;65535t" in the terminal


--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris

[webkit-changes] [WebKit/WebKit] b424c8: neowin.net: 'share' drop-down layout is broken and...

[Alan Baradlay]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: b424c89ef6900030cc7298e28909b1f826bbb25f
  
https://github.com/WebKit/WebKit/commit/b424c89ef6900030cc7298e28909b1f826bbb25f
  Author: Alan Baradlay 
  Date:   2024-06-09 (Sun, 09 Jun 2024)

  Changed paths:
A LayoutTests/fast/block/float/non-intrusive-float-overlap-expected.html
A LayoutTests/fast/block/float/non-intrusive-float-overlap.html
M Source/WebCore/layout/floats/FloatingContext.cpp
M Source/WebCore/layout/floats/FloatingContext.h

  Log Message:
  ---
  neowin.net: 'share' drop-down layout is broken and overlaps
https://bugs.webkit.org/show_bug.cgi?id=275290


Reviewed by Antti Koivisto.

Floats, somewhat surprisingly may overlap each other, but only when an already 
placed float coming from outside of
the current containing block does not overlap the containing block's content 
box.
In such cases, newly placed floats may overlap such non-intrusive floats at 
their non-floating side.

e.g.

F - float box
C - containing block for (F)
N - non-overlapping box, sibling of C, also float but not overlapping C's 
content box.

 
 
   

  _
 |N|  This is where (C)'s content box starts (see padding-left: 20px)
 |_|_|
 |C ___|_|__ |
 | |   | | F||
 | |   | |  ||
 | |   | |  ||
 | |___|_|__||
 |_|_|___|
 | |
 |_|

Note that (F) float box overlaps (N -also float) with its non-floating (left) 
side.

* Source/WebCore/layout/floats/FloatingContext.cpp:
(WebCore::Layout::findAvailablePosition):
(WebCore::Layout::FloatingContext::positionForFloat const):
(WebCore::Layout::FloatingContext::positionForNonFloatingFloatAvoider const):
(WebCore::Layout::FloatingContext::findPositionForFormattingContextRoot const):
* Source/WebCore/layout/floats/FloatingContext.h:

Canonical link: https://commits.webkit.org/279867@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Re: IDLE: clearing the screen

[Alan Gauld via Python-list]

On 08/06/2024 20:18, Rob Cliffe via Python-list wrote:
> OK, here is the advanced version:
> import os
> class _cls(object):
>      def __repr__(self):
>          os.system('cls')
>          return ''
> cls = _cls()
> 
> Now when you type
> cls
> it clears the screen.  

For me on a Mac it clears the terminal screen that I used
to launch IDLE and prints a single blank line on the IDLE
shell. (And I have to use "clear" instead of "cls" of course.

A quick Google suggests that printing Ctrl-L (formfeed?) might
be a platform agnostic solution. But that didn't work for me
in IDLE either. I think this is one where the best bet is to go
into the IDLE code and add a Shell submenu to clear screen!
Apparently it's been on the workstack at idle-dev for a long
time but is considered low priority...

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

[webkit-changes] [WebKit/WebKit] 097eb3: Add missing layout flag to ASSERT in RenderElement...

[Alan Baradlay]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 097eb3c0d63c8022abd05a1c2f1cdb1fb8d91957
  
https://github.com/WebKit/WebKit/commit/097eb3c0d63c8022abd05a1c2f1cdb1fb8d91957
  Author: Alan Baradlay 
  Date:   2024-06-09 (Sun, 09 Jun 2024)

  Changed paths:
M Source/WebCore/rendering/RenderElement.cpp

  Log Message:
  ---
  Add missing layout flag to ASSERT in 
RenderElement::setOutOfFlowChildNeedsStaticPositionLayout
https://bugs.webkit.org/show_bug.cgi?id=275264


Reviewed by Antti Koivisto.

The parent of a newly inserted out of flow box may already have lost an out of 
flow box (and getting it marked "needs simplified layout").

* Source/WebCore/rendering/RenderElement.cpp:
(WebCore::RenderElement::setOutOfFlowChildNeedsStaticPositionLayout):

Canonical link: https://commits.webkit.org/279866@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[agi] Oh boy....

[Alan Grimes via AGI]

I'm sorry for having to bring all these other subjects onto the list but 
I really love AGI people and I want you guys to be ready for what's 
coming. As it turns out, the dipshits in Washington DC are both 
infinitely stupider and infinitely eviler than anyone has given them 
credit for, heck even more so than would seem to be physically possible.


It has gotten so bad that they've driven Putin to the point where he 
believes he must provide a practical demonstration of a modern nuclear 
arsenal. He is now planning a tactical strike on military targets that 
he feels that are most threatening to his country. The tea-leaves point 
to July 18 (+/- 3 days) as the date of this event. No sane person wants 
this to happen. The question is whether the assholes in Washinton will 
escelate. If not, then we will be spared.


In all cases, this will be a single-day event. IF YOU RECEIVE ANY KIND 
OF WARNING FROM RUSSIA THAT YOUR AREA IS TARGEGETED HEED THAT WARNING!! 
MAKE SURE YOU ARE AT LEAST A FEW HUNDRED MILES FROM ANY SUCH TARGET ZONE.


--
You can't out-crazy a Democrat.
#EggCrisis  #BlackWinter
White is the new Kulak.
Powers are not rights.


--
Artificial General Intelligence List: AGI
Permalink: 
https://agi.topicbox.com/groups/agi/Tfad15c64a6d3c7ed-M6b228585adbaccff1265773e
Delivery options: https://agi.topicbox.com/groups/agi/subscription

[NTG-context] Re: Bibliography: separating different kinds of literature OR Sectioning bibliography by type

[Alan Braslau via ntg-context]

Try something like:

  \flushbtxrendering [bibrendering]
   [method=dataset,
sorttype=index,
filter=match(category:article)]

I have used the filtering mechanism to select fields, such as 
filter=match(year:2023).

Alan




On Tue, 4 Jun 2024 15:20:14 +0200
Ben Moon via ntg-context  wrote:

> Hey there,
> I would like to place a list of bibliography according to types
> (article, book, in proceedings) in my document. Similar like here:
> https://tex.stackexchange.com/questions/112874/sectioning-bibliography-by-type-with-multiple-types-per-section
> Sectioning bibliography by type (with multiple types per section)
> tex.stackexchange.com
> 
> and here:
> https://www.mail-archive.com/ntg-context@ntg.nl/msg77056.html
> The example provided by Hans doesn’t seem to properly work any more,
> and I cannot make the suggestion work of using two different datasets
> work as suggested in the same thread. So this is where I’m stuck:
> 
> \definebtxdataset[main]
> \usebtxdataset[main][maindata.buffer]
> \definebtxdataset[images]
> \usebtxdataset[images][imagedata.buffer]
> \usebtxdefinitions[mycustom, aps]
> \setupbtx[dataset=main]
> \definebtxrendering[bibrendering][mycustom, aps][dataset=main]
> \definebtxrendering[bibimgrendering][mycustom, aps][dataset=images]
> 
> \placelistofpublications[bibrendering]
> \placelistofpublications[bibimgrendering]
> 
> It would be much appreciated if someone could provide a working
> example?
> 
> Thank you very much
> 
> Ben

___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

[NetBehaviour] Impossible Theory: clarity compression

[Alan Sondheim via NetBehaviour]

*/all-nighter on this one/*

Impossible Theory: clarity compression

https://www.youtube.com/watch?v=ZjV7DoiMN7w video

ofthe1970 Several1970 1913 genocidemp3 15:58:34 1970:2008:
theusual: annihilation: notes: thinkthis: geol.mov: happened;
accessgrid; genocide; unutterable; massacre; theMing; totheMing;
beheading; bandwidth; radio; worlds; species; skintears;
without; genocide? whatthen? massacres? that? this:A WORLD
good.BYTE old,I massacre.I ofplague.I promising.I weak.I
I'mweak.I genocides.I radio;I amongI wantwrongI newI withanAK
Plutonium Iplutonium genocide;NY massacre.] [China] forme,a
massacre,a hacking,a thepunch,a guts,a fornow,a massacre]a
it'snotaa filmaba Rwanda arounda genocidea amassacrea theyhavea
ofa spiritofa becominga froma trauma remainana intoa stupa
slaughtera it'sa war,it'sa ifit'sa Itwasa Thisisa Sothisisa
whatisa isn'ta It'snota it'snota butcherya b=gb [Youmayabc
andmagic therhetoric micro-plastic pessimistic playhavoc
ranch.he'd genocide,3d dead liquiddead here,read wide-spread
that'sread instead binged fullinged energiesinged itsinged
Scorched scorched cried emptied masked abandoned hasturned
retuned hisretuned massacred ormassacred andmurdered gathered
ofcharred related limited 3d-printed characterized liquid
NewWorld and ISIS,and China,and blood,and +/-and your?and
somaticand andand Godand genocideand **genocideand theand areand
moreand believeand surviveand mewlingand dreamland foreignand
andonand withbrand militiasand ridesand refugeesand studiesand
poisonsand saywaitand recommend around justaround swampfood
noteword tobe nottobe mathmaybe Everyplace everyplace space
edgespace beganspace alliance massacre/disappearance violence
difference source isasource trade patricide genocide up,genocide
andgenocide ofgenocide ingenocide norgenocide aroadside
modernguide worldwide areandsee waitandsee letterslife marriage
stage boaststage Strange playlarge purge FarThe the US,the
head,the mind,the byfire,the julu,the itse/f-the itself-the
runout-the [::]:the andthe genocidethe beforethe ofthe withthe
inthe kickinthe onthe cameonthe ofonthe deathonthe bookonthe
tothe stopthe orthe ...forthe asthe aboutthe sorrowthe bythe
slowlythe tradeie cantellie movie like male available fumble
girdle mangle meanwhile thewhole thispeople butpeople goodtime
genome some hangfume Ukraine guillotine one northisone everyone
we're toyou're they're guillo-are inBuchaare Weare peopleare
toearthare massacre amassacre themassacre ofmassacre marmassacre
limit.There where elsewhere campswhere everywhere literature
monoculture thetorture future thethese makingnoise deliberate
deliberate State cameState thestate site disk.site placesite
Everysite everysite garrote wrote constitute asvalue continue
have limbshave performative helpresolve died.we emphasize
stones.Of polishoff stuff genocide,if notewordif whoknowsif
win,butif yourself of of earths,of massacre.of ofus?of isaof
ridof genocideof massacreof Becauseof asiteof isasiteof
bullyingof songof thinkof China.inof shownof sweep-upof
survivorof imagesof impulsesof denialsof victimsof accountsof
daysof Whatof greatestof ghostof holocaustof andoutof bodyof
reading spreading descending hewounding begging something
beijing breaking taking filling killing thekilling gloaming
war,warming awakening punning running makemapping zerobring
triggering increasing cleansing dressing depressing meditating
writing reliving driving replaying aswrong boastwrong ohisong
generator.png tibetsung geol.jpg genlauf090jpg genlauf088jpg
genlauf089jpg gennudejpg lumberlynch energyoh termsanguish
breath with tooth life,tooth toothtooth earth slaughteri llitsi
ghichak broughtback ofbutback singedblank forfrank place.Think
Mywork ecological technological artificial potential theoriginal
Opal fromNepal mindseveral temporal natural cultural gestural
universal aredigital genital continental virtual groundfidel
feel historyfeel doestravel frankl they'reall massacreall small
it'sall hate"kill beautiful chernobyl God.I'm people.am USscream
tammuzteam andiam gloam alansondheim isithim forafilm condom
room workingfrom fromfrom stemsfrom massacred\n genocidecan
Rwandan mean strongman manu=ecstatic=f=woman thehuman Butalsoan
*cideasan They'vebeen then northen sorrowthen broken beaten
forgotten thiseven don'teven foreign massacre,in towar,in
eons,in sex,in fires.in remain theyremain genocidein rampagein
nonsensein havein yourselfin livingin Farin shooterin
believersin genocide,on ecstasy,on newlexicon focusedon onandon
massacreon region liquidation annihilation extermination
condemnation inquotation preservation acollection edition
aposition retribution rougezion northern remainnorthern that?Do
massacre,do Colorado cannotdo ifcannotdo becausewho Twine:Hello
hello inhello solo happen.no fidelcastro infants,so andso to
todying,to invasion,to happen.to anendto genocideto cometo
you'reto approachto heseemsto obviousto Wewantto relationship
genocide.mp do.Or Taiwan.Far Nuclear theorder wouldrather
therather 

[NetBehaviour] Muraleen

[Alan Sondheim via NetBehaviour]

Muraleen

http://www.alansondheim.org/thus.jpg

i hurry to reply to you before the dusk falls and the world
heats and the other appear. we take their place taking
ours.:what would they call me, they call me as such henceforth
as you might imagine. Are you literature? Are you fundamental?
Are you mental? Do you exist through the duree?:I am there and I
answer the Call.:I am THUS. Your pure above the frost asendent
_but only at the lowest level_ is in my great I am the call that
answers Me. Your your placement runs into my I am the call that
answers Me. - turning me clausterphobic thinking negatively of
you after so many years */unhealed/* */unannhealed/* unfounded -
absorption of muralin */life's pattern, pattern of my life/* :to
be wiped into existence, exactly, the cloth (somewhat dirty,
grey with dust and filth) moving across the somewhat brutal
landscape of the flesh, */you know the state, damp but not
quite, clean but not quite, some smears of brown, red and gray/*
as if fallen into the crevice of gristle and bone '/some tale to
tell/':i'm at it agin, the main::sign 'used only once' / there
might be an error. meanwhile so happy to be back on the old
ground, thinking positive thoughts of you, after so many
years...:upper right to upper left:upper left to upper right
Your avatar dissolves my upper right to upper left! ghost with
ideohydraulesis!

*/dict murelin No definitions found for "murelin" dict muraline
No definitions found for "muraline" dict muralin No definitions
found for "muralin" dict muriline definitions found for
"muriline" dict mureline definitions found for "mureline" dict
murilin definitions found for "murilin"/*

__

___
NetBehaviour mailing list
NetBehaviour@lists.netbehaviour.org
https://lists.netbehaviour.org/mailman/listinfo/netbehaviour

Re: [PATCH] dm cache metadata: remove unused struct 'thunk'

[Dr. David Alan Gilbert]

* li...@treblig.org (li...@treblig.org) wrote:
> From: "Dr. David Alan Gilbert" 
> 
> 'thunk' has been unused since
> commit f177940a8091 ("dm cache metadata: switch to using the new
> cursor api for loading metadata").
> 
> Remove it.
> 
> Signed-off-by: Dr. David Alan Gilbert 

Ping

> ---
>  drivers/md/dm-cache-metadata.c | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/drivers/md/dm-cache-metadata.c b/drivers/md/dm-cache-metadata.c
> index 96751cd3d181..0ad9dc1824fa 100644
> --- a/drivers/md/dm-cache-metadata.c
> +++ b/drivers/md/dm-cache-metadata.c
> @@ -1282,15 +1282,6 @@ int dm_cache_insert_mapping(struct dm_cache_metadata 
> *cmd,
>   return r;
>  }
>  
> -struct thunk {
> - load_mapping_fn fn;
> - void *context;
> -
> - struct dm_cache_metadata *cmd;
> - bool respect_dirty_flags;
> - bool hints_valid;
> -};
> -
>  static bool policy_unchanged(struct dm_cache_metadata *cmd,
>struct dm_cache_policy *policy)
>  {
> -- 
> 2.45.1
> 
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

[NetBehaviour] Incessant (guitar solo pollen slime mold)

[Alan Sondheim via NetBehaviour]

Incessant (guitar solo pollen slime mold)

https://youtu.be/iHRim4KCTPs video


From WordNet (r) 3.0 (2006) [wn]:


incessant adj 1: uninterrupted in time and indefinitely long
continuing; "the ceaseless thunder of surf"; "in constant pain";
"night and day we live with the incessant noise of the city";
"the never-ending search for happiness"; "the perpetual struggle
to maintain standards in a democracy"; "man's unceasing warfare
with drought and isolation"; "unremitting demands of hunger"
[syn: {ceaseless}, {constant}, {incessant}, {never-ending},
{perpetual}, {unceasing}, {unremitting}]

eyesclosedtypingunthinking there's the wordnet and there's
everything underfoot in the wind on the ground beneath the
ground within the thicket on the edges of the think thinking
unthinking return in health o streaming animals outlast us do
not forgive us we are not here not there we will be not here not
there we are destroyers of magnitudes in magnitudes we are
unstoppable we will perish we will all perish are all perishing
now all in the process of perishing the muddy trails we leave
behind now dust the dusty trails we leave behind now beneath the
flowing of silt and debris we tall towers spindles we shanks
ankles do not support do not support our lungs we are lungs we
are air-users air-abusers we are multitudes sinter within and
without sinter sinter dusts dusted dusts darted dusts darts


__
___
NetBehaviour mailing list
NetBehaviour@lists.netbehaviour.org
https://lists.netbehaviour.org/mailman/listinfo/netbehaviour

Re: sample apps guide

[Alan C. Assis]

Hi yf,

I don't know, normally the cache issues some people faced were related to
STM32F7 and STM32H7 and there is some documentation about it:

https://cwiki.apache.org/confluence/display/NUTTX/Porting+Drivers+to+the+STM32+F7

BR,

Alan

On Fri, Jun 7, 2024 at 5:26 AM yfliu2008  wrote:

> Dear community,
>
>
>
>
> I am wondering if there are any samples in our "nuttx-apps" repo are cache
> sensitive? Such as database or linked list tranversal types?
>
> I need some of them to see if rv64ilp32 can make differences on the K230
> device.
>
>
>
>
> Regards,
>
> yf

[slurm-users] Re: [INTERNET] Re: cpu distribution question

[Alan Stange via slurm-users]

Thank you for this note, the comments on the issue you raised have saved
me a lot of time.

I agree that the documentation around this issue of cpu
assignment/allocation is confusing and part of the problem.    Of
particular concern is the changing behavior of cpu allocation when
adding a gres that has nothing to do with cpu assignment.  The
non-deterministic behavior here is unsettling.

I guess I will need to have  a look at a plugin so that we can ensure
deterministic behavior.   

We have already modified the slurm source to allow regular users to
create there own reservations, so perhaps I might get annoyed enough to
'fix' this in the slurm code base.

Thank you!

Alan

On 6/7/24 18:36, Juergen Salk wrote:
> Hi Alan,
>
> unfortunately, process placement in Slurm is kind of black magic for
> sub-node jobs, i.e. jobs that allocate only a small number of CPUs of
> a node. 
>
> I have recently raised a similar question here:
>
>  https://support.schedmd.com/show_bug.cgi?id=19236
>
> And the buttom line was, that to "really have control over task placement 
> you really have to allocate the node in --exclusive manner". 
>
> Best regards
> Jürgen
>
>
> * Alan Stange via slurm-users  [240607 14:52]:
>> All,
>>
>> I have a very simple slurm cluster.  It's just a single system with 2
>> sockets and 16 cores in each socket.  I would like to be able to submit
>> a simple task into this cluster, and to have the cpus assigned to that
>> task allocated round robin across the two sockets.   Everything I try is
>> putting all the cpus for this single task on the same socket.
>>
>> I have not specified any CpuBind options in the slurm.conf file.   For
>> example, if I try
>>
>> $ srun -c 4 --pty bash
>>
>> I get a shell prompt on the system, and can run
>>
>> $ taskset -cp $$
>> pid 12345 current affinity list: 0,2,4,6
>>
>> and I get this same set of cpus no matter what options I try (the
>> cluster is idle with no tasks consuming slots).
>>
>> I've tried various srun command line options like:
>> --hint=compute_bound
>> --hint=memory_bound
>> various --cpubind options
>> -B 2:2 -m block:cyclic and block:fcyclic
>>
>> Note that if I try to allocation 17 cpus, then I do get the 17th cpu
>> allocated on the 2nd socket.
>>
>>
>> What magic incantation is needed to get an allocation where the cpus are
>> chosen round robin across the sockets?
>>
>> Thank you!
>>
>> Alan
>>
>>
>> -- 
>> slurm-users mailing list -- slurm-users@lists.schedmd.com
>> To unsubscribe send an email to slurm-users-le...@lists.schedmd.com
> -- 
> Jürgen Salk
> Scientific Software & Compute Services (SSCS)
> Kommunikations- und Informationszentrum (kiz)
> Universität Ulm
> Telefon: +49 (0)731 50-22478
> Telefax: +49 (0)731 50-22471


-- 
slurm-users mailing list -- slurm-users@lists.schedmd.com
To unsubscribe send an email to slurm-users-le...@lists.schedmd.com

Re: Secdir early review of draft-ietf-bfd-stability-13

[Alan DeKok]

  (removing secdir)

  The security analysis is perhaps simplified a bit by understanding the 
limited use-case for BFD.  From the introduction to RFC 5880:

   The goal of Bidirectional Forwarding Detection (BFD) is to provide
   low-overhead, short-duration detection of failures in the path
   between adjacent forwarding engines, including the interfaces, data
   link(s) ...

  i.e. The parties to a BFD conversation are intended to be connected by a 
wire.  This means that issues like "out of order packet delivery" are generally 
not applicable.

  The attacks on BFD are therefore limited to either (a) forcibly taking the 
connection down, or (b) erroneously keeping the connection up.

  No amount of cryptography will protect from an attack which intends to take 
the BFD session down.  An on-path attacker simply has to either drop the BFD 
packets, or mangle them so that they are discarded by the receiver.  As such, 
any cryptography in BFD is limited to preventing spoofed packets.  The "Secure 
Sequence numbers" draft is intended to do exactly that.  It uses a CSPRNG to 
generate infinite sequences of random numbers which an attacker cannot predict. 
 Receivers can verify that packets contain the expected sequences, within a 
small window.   
https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/

  For sequence number roll-over issues with the other "authentication" types, 
the default timers (1 packet/s), result in a rollover every 136 years, which 
seems acceptable.  Typical BFD timer intervals are 300ms, which leads to 45 
years between rollover.  Switching from MD5/SHA1 to the above draft would also 
address the roll-over issue.

  The parties to the BFD conversation are typically also line cards with 
extremely limited CPU power.  So independent of the issues noted above that 
crypto doesn't help with certain kinds of attacks, the systems generally don't 
have enough CPU power to run a full cryptographic protocol like TLS or QUIC.

  That being said, the Security Considerations section should discuss the items 
mentioned in your review, and explain why the issues noted are generally 
acceptable for BFD.

> On Jun 8, 2024, at 12:54 AM, Christian Huitema via Datatracker 
>  wrote:
> 
> Reviewer: Christian Huitema
> Review result: Has Issues
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG. These 
> comments
> were written primarily for the benefit of the security area directors. 
> Document
> editors and WG chairs should treat these comments just like any other last 
> call
> comments.
> 
> Bidirectional Forwarding Detection (BFD, RFC 5880) is used to monitor "data
> plane" paths by sending BFD packets between "forwarding engines" and detecting
> failures when they are not correctly received. For example, its Echo function
> will trigger ping-like replies to check that a path is valid in both
> directions. The BFD Stability draft describes extensions to BFD to not just
> detecting failures when a sufficient number of BFD packets or echoes are not
> received, but to also quickly detect and report packet losses. When losses are
> detected, they are reported in the Yang module ietf-bfd-stability, which is
> defined in the draft.
> 
> There is no packet sequence number in the "Generic BFD Control Packet Format"
> defined in section 4.1 of RFC5880. The BFD stability draft uses instead the
> Sequence Number defined in the authentication extension to BFD. RFC5880 
> defines
> five types of authentication: simple password, keyed MD5, "meticulously" keyed
> MD5, keyed SHA1, and "meticulously" keyed SHA1. Of those, only the MD5 and 
> SHA1
> variants include a 32 bit sequence number, and only the "meticulous" variants
> require that the sequence number should be incremented for each packet. The
> draft requests that if authentication is used, then either the MD5 or SHA1
> "meticulous" variant be selected. The draft also defines a NULL form of
> authentication, in which the authentication extension only carries a sequence
> number. The loss detection can then use the sequence number in the
> authentication extension.
> 
> The authentication sequence number is a 32 bit field. Such numbers can roll
> over, either after a long duration session or due to a packet injection 
> attack.
> There is some text about that in the description of the NULL authentication. 
> It
> says:
> 
>   If bfd.AuthSeqKnown is 1, and the received Sequence Number field is
>   not equal to bfd.RcvAuthSeq + 1 (in a circular number space), then
>   the loss count is incremented by one and bfd.RcvAuthSeq is set to the
>   received Sequence Number.
> 
> That does not look quite right. Suppose that due to out of order delivery, the
> packets are received in order 1-3-2-4. Upon reception of packet 3, the
> algorithm counts one loss and set the next expected value to 4. After packet 
> 2,
> another loss and expected value to 3. 

git: 5ee5c40402c9 - main - arm64 pmap: Defer bti lookup

[Alan Cox]

The branch main has been updated by alc:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=5ee5c40402c92a498ed8d6eeb6cf0b5c1680817b

commit 5ee5c40402c92a498ed8d6eeb6cf0b5c1680817b
Author: Alan Cox 
AuthorDate: 2024-06-07 05:23:59 +
Commit: Alan Cox 
CommitDate: 2024-06-08 07:26:55 +

arm64 pmap: Defer bti lookup

Defer the bti lookup until after page table page allocation is complete.
We sometimes release the pmap lock and sleep during page table page
allocation.  Consequently, the result of a bti lookup from before
page table page allocation could be stale when we finally create the
mapping based on it.

Modify pmap_bti_same() to update the prototype PTE at the same time as
checking the address range.  This eliminates the need for calling
pmap_pte_bti() in addition to pmap_bti_same().  pmap_bti_same() was
already doing most of the work of pmap_pte_bti().

Reviewed by:markj
Differential Revision:  https://reviews.freebsd.org/D45502
---
 sys/arm64/arm64/pmap.c | 73 ++
 1 file changed, 44 insertions(+), 29 deletions(-)

diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c
index 92c1c824ba4e..7b30b2a6ae37 100644
--- a/sys/arm64/arm64/pmap.c
+++ b/sys/arm64/arm64/pmap.c
@@ -508,7 +508,8 @@ static void pmap_update_entry(pmap_t pmap, pd_entry_t *pte, 
pd_entry_t newpte,
 static __inline vm_page_t pmap_remove_pt_page(pmap_t pmap, vm_offset_t va);
 
 static uma_zone_t pmap_bti_ranges_zone;
-static bool pmap_bti_same(pmap_t pmap, vm_offset_t sva, vm_offset_t eva);
+static bool pmap_bti_same(pmap_t pmap, vm_offset_t sva, vm_offset_t eva,
+pt_entry_t *pte);
 static pt_entry_t pmap_pte_bti(pmap_t pmap, vm_offset_t va);
 static void pmap_bti_on_remove(pmap_t pmap, vm_offset_t sva, vm_offset_t eva);
 static void *bti_dup_range(void *ctx, void *data);
@@ -4955,21 +4956,22 @@ set_l3:
 #endif /* VM_NRESERVLEVEL > 0 */
 
 static int
-pmap_enter_largepage(pmap_t pmap, vm_offset_t va, pt_entry_t newpte, int flags,
+pmap_enter_largepage(pmap_t pmap, vm_offset_t va, pt_entry_t pte, int flags,
 int psind)
 {
-   pd_entry_t *l0p, *l1p, *l2p, origpte;
+   pd_entry_t *l0p, *l1p, *l2p, newpte, origpte;
vm_page_t mp;
 
PMAP_LOCK_ASSERT(pmap, MA_OWNED);
KASSERT(psind > 0 && psind < MAXPAGESIZES,
("psind %d unexpected", psind));
-   KASSERT((PTE_TO_PHYS(newpte) & (pagesizes[psind] - 1)) == 0,
-   ("unaligned phys address %#lx newpte %#lx psind %d",
-   PTE_TO_PHYS(newpte), newpte, psind));
+   KASSERT((PTE_TO_PHYS(pte) & (pagesizes[psind] - 1)) == 0,
+   ("unaligned phys address %#lx pte %#lx psind %d",
+   PTE_TO_PHYS(pte), pte, psind));
 
 restart:
-   if (!pmap_bti_same(pmap, va, va + pagesizes[psind]))
+   newpte = pte;
+   if (!pmap_bti_same(pmap, va, va + pagesizes[psind], ))
return (KERN_PROTECTION_FAILURE);
if (psind == 2) {
PMAP_ASSERT_L1_BLOCKS_SUPPORTED;
@@ -5123,9 +5125,6 @@ pmap_enter(pmap_t pmap, vm_offset_t va, vm_page_t m, 
vm_prot_t prot,
 
lock = NULL;
PMAP_LOCK(pmap);
-   /* Wait until we lock the pmap to protect the bti rangeset */
-   new_l3 |= pmap_pte_bti(pmap, va);
-
if ((flags & PMAP_ENTER_LARGEPAGE) != 0) {
KASSERT((m->oflags & VPO_UNMANAGED) != 0,
("managed largepage va %#lx flags %#x", va, flags));
@@ -5197,6 +5196,7 @@ havel3:
orig_l3 = pmap_load(l3);
opa = PTE_TO_PHYS(orig_l3);
pv = NULL;
+   new_l3 |= pmap_pte_bti(pmap, va);
 
/*
 * Is the specified virtual address already mapped?
@@ -5405,7 +5405,6 @@ pmap_enter_l2_rx(pmap_t pmap, vm_offset_t va, vm_page_t 
m, vm_prot_t prot,
new_l2 = (pd_entry_t)(VM_PAGE_TO_PTE(m) | ATTR_DEFAULT |
ATTR_S1_IDX(m->md.pv_memattr) | ATTR_S1_AP(ATTR_S1_AP_RO) |
L2_BLOCK);
-   new_l2 |= pmap_pte_bti(pmap, va);
if ((m->oflags & VPO_UNMANAGED) == 0) {
new_l2 |= ATTR_SW_MANAGED;
new_l2 &= ~ATTR_AF;
@@ -5478,7 +5477,7 @@ pmap_enter_l2(pmap_t pmap, vm_offset_t va, pd_entry_t 
new_l2, u_int flags,
 * and let vm_fault() cope.  Check after l2 allocation, since
 * it could sleep.
 */
-   if (!pmap_bti_same(pmap, va, va + L2_SIZE)) {
+   if (!pmap_bti_same(pmap, va, va + L2_SIZE, _l2)) {
KASSERT(l2pg != NULL, ("pmap_enter_l2: missing L2 PTP"));
pmap_abort_ptp(pmap, va, l2pg);
return (KERN_PROTECTION_FAILURE);
@@ -5633,7 +5632,6 @@ pmap_enter_l3c_rx(pmap_t pmap, vm_offset_t va, vm_page_t 
m, vm_page_t *ml3p,
l3e = VM_PAGE_TO_PTE(m) | ATTR_DEFAULT |
ATTR_S1_IDX(m->md.pv_memattr) | ATTR_S1_AP(ATTR_S1_AP_RO) |
ATTR_CO

git: 5ee5c40402c9 - main - arm64 pmap: Defer bti lookup

[Alan Cox]

The branch main has been updated by alc:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=5ee5c40402c92a498ed8d6eeb6cf0b5c1680817b

commit 5ee5c40402c92a498ed8d6eeb6cf0b5c1680817b
Author: Alan Cox 
AuthorDate: 2024-06-07 05:23:59 +
Commit: Alan Cox 
CommitDate: 2024-06-08 07:26:55 +

arm64 pmap: Defer bti lookup

Defer the bti lookup until after page table page allocation is complete.
We sometimes release the pmap lock and sleep during page table page
allocation.  Consequently, the result of a bti lookup from before
page table page allocation could be stale when we finally create the
mapping based on it.

Modify pmap_bti_same() to update the prototype PTE at the same time as
checking the address range.  This eliminates the need for calling
pmap_pte_bti() in addition to pmap_bti_same().  pmap_bti_same() was
already doing most of the work of pmap_pte_bti().

Reviewed by:markj
Differential Revision:  https://reviews.freebsd.org/D45502
---
 sys/arm64/arm64/pmap.c | 73 ++
 1 file changed, 44 insertions(+), 29 deletions(-)

diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c
index 92c1c824ba4e..7b30b2a6ae37 100644
--- a/sys/arm64/arm64/pmap.c
+++ b/sys/arm64/arm64/pmap.c
@@ -508,7 +508,8 @@ static void pmap_update_entry(pmap_t pmap, pd_entry_t *pte, 
pd_entry_t newpte,
 static __inline vm_page_t pmap_remove_pt_page(pmap_t pmap, vm_offset_t va);
 
 static uma_zone_t pmap_bti_ranges_zone;
-static bool pmap_bti_same(pmap_t pmap, vm_offset_t sva, vm_offset_t eva);
+static bool pmap_bti_same(pmap_t pmap, vm_offset_t sva, vm_offset_t eva,
+pt_entry_t *pte);
 static pt_entry_t pmap_pte_bti(pmap_t pmap, vm_offset_t va);
 static void pmap_bti_on_remove(pmap_t pmap, vm_offset_t sva, vm_offset_t eva);
 static void *bti_dup_range(void *ctx, void *data);
@@ -4955,21 +4956,22 @@ set_l3:
 #endif /* VM_NRESERVLEVEL > 0 */
 
 static int
-pmap_enter_largepage(pmap_t pmap, vm_offset_t va, pt_entry_t newpte, int flags,
+pmap_enter_largepage(pmap_t pmap, vm_offset_t va, pt_entry_t pte, int flags,
 int psind)
 {
-   pd_entry_t *l0p, *l1p, *l2p, origpte;
+   pd_entry_t *l0p, *l1p, *l2p, newpte, origpte;
vm_page_t mp;
 
PMAP_LOCK_ASSERT(pmap, MA_OWNED);
KASSERT(psind > 0 && psind < MAXPAGESIZES,
("psind %d unexpected", psind));
-   KASSERT((PTE_TO_PHYS(newpte) & (pagesizes[psind] - 1)) == 0,
-   ("unaligned phys address %#lx newpte %#lx psind %d",
-   PTE_TO_PHYS(newpte), newpte, psind));
+   KASSERT((PTE_TO_PHYS(pte) & (pagesizes[psind] - 1)) == 0,
+   ("unaligned phys address %#lx pte %#lx psind %d",
+   PTE_TO_PHYS(pte), pte, psind));
 
 restart:
-   if (!pmap_bti_same(pmap, va, va + pagesizes[psind]))
+   newpte = pte;
+   if (!pmap_bti_same(pmap, va, va + pagesizes[psind], ))
return (KERN_PROTECTION_FAILURE);
if (psind == 2) {
PMAP_ASSERT_L1_BLOCKS_SUPPORTED;
@@ -5123,9 +5125,6 @@ pmap_enter(pmap_t pmap, vm_offset_t va, vm_page_t m, 
vm_prot_t prot,
 
lock = NULL;
PMAP_LOCK(pmap);
-   /* Wait until we lock the pmap to protect the bti rangeset */
-   new_l3 |= pmap_pte_bti(pmap, va);
-
if ((flags & PMAP_ENTER_LARGEPAGE) != 0) {
KASSERT((m->oflags & VPO_UNMANAGED) != 0,
("managed largepage va %#lx flags %#x", va, flags));
@@ -5197,6 +5196,7 @@ havel3:
orig_l3 = pmap_load(l3);
opa = PTE_TO_PHYS(orig_l3);
pv = NULL;
+   new_l3 |= pmap_pte_bti(pmap, va);
 
/*
 * Is the specified virtual address already mapped?
@@ -5405,7 +5405,6 @@ pmap_enter_l2_rx(pmap_t pmap, vm_offset_t va, vm_page_t 
m, vm_prot_t prot,
new_l2 = (pd_entry_t)(VM_PAGE_TO_PTE(m) | ATTR_DEFAULT |
ATTR_S1_IDX(m->md.pv_memattr) | ATTR_S1_AP(ATTR_S1_AP_RO) |
L2_BLOCK);
-   new_l2 |= pmap_pte_bti(pmap, va);
if ((m->oflags & VPO_UNMANAGED) == 0) {
new_l2 |= ATTR_SW_MANAGED;
new_l2 &= ~ATTR_AF;
@@ -5478,7 +5477,7 @@ pmap_enter_l2(pmap_t pmap, vm_offset_t va, pd_entry_t 
new_l2, u_int flags,
 * and let vm_fault() cope.  Check after l2 allocation, since
 * it could sleep.
 */
-   if (!pmap_bti_same(pmap, va, va + L2_SIZE)) {
+   if (!pmap_bti_same(pmap, va, va + L2_SIZE, _l2)) {
KASSERT(l2pg != NULL, ("pmap_enter_l2: missing L2 PTP"));
pmap_abort_ptp(pmap, va, l2pg);
return (KERN_PROTECTION_FAILURE);
@@ -5633,7 +5632,6 @@ pmap_enter_l3c_rx(pmap_t pmap, vm_offset_t va, vm_page_t 
m, vm_page_t *ml3p,
l3e = VM_PAGE_TO_PTE(m) | ATTR_DEFAULT |
ATTR_S1_IDX(m->md.pv_memattr) | ATTR_S1_AP(ATTR_S1_AP_RO) |
ATTR_CO

[webkit-changes] [WebKit/WebKit] 4a5b56: Limit the number of repaint candidates after simpl...

[Alan Baradlay]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 4a5b56e32671dd7cc4768db52d1b8b0681b17ee9
  
https://github.com/WebKit/WebKit/commit/4a5b56e32671dd7cc4768db52d1b8b0681b17ee9
  Author: Alan Baradlay 
  Date:   2024-06-07 (Fri, 07 Jun 2024)

  Changed paths:
M Source/WebCore/page/LocalFrameView.cpp
M Source/WebCore/page/LocalFrameView.h
M Source/WebCore/page/LocalFrameViewLayoutContext.cpp
M Source/WebCore/page/LocalFrameViewLayoutContext.h
M Source/WebCore/rendering/RenderElement.cpp
M Source/WebCore/rendering/RenderElement.h
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/RenderView.cpp

  Log Message:
  ---
  Limit the number of repaint candidates after simplified layout
https://bugs.webkit.org/show_bug.cgi?id=275153

Reviewed by Simon Fraser.

"simplified normal-flow layout" is initiated when the only property that 
requires attention
at layout time throughout the entire tree is overflow.

It simply means that the current (outstanding) style and/or content mutation 
that we try to recover from
is not supposed to change any in- or out-of-flow box size and/or position.
Such change may be triggered by
- out-of-flow box is inserted and/or removed (note that at insertion, we run 
non-simplified layout
  _inside_ the freshly added subtree)
- StyleDifferenceContextSensitiveProperty::Transform changes but nothing else 
(e.g. scale changes on an element.
  This only applies to mutating existing properties, i.e. when a new transform 
related property is added,
  non-simplified layout is initiated)

1. These type of changes are not supposed to expand the damaged area (marking 
additional renderers dirty as
   we run layout on the tree).
2. The entry point in most cases is still the RenderView but it could very well 
be a subtree layout.

Layout:
  We traverse through descendants by calling layout() all the way to the dirty 
renderer(s).
  However while descending, we only run simplifiedLayout().

After layout:
  We run RenderLayer::updateLayerPositionsAfterLayout() where we traverse the 
_layer_ tree
  and (almost unconditionally) re-compute repaint rects on associated renderers 
(and even issue redundant repaints).
  When the damage is limited to relatively small subtree(s), most of this work 
is redundant.

This patch ensures that in case of "simplified normal-flow layout", "repaint 
rects" related work happens only on affected renderers.

1. Assign a layout identifier to each layout run 
(LocalFrameViewLayoutContext::performLayout)
2. Mark each renderer involved in current layout with said layout identifier 
(RenderObject::clearNeedsLayout)
3. Check if the current layout is "simplified normal-flow layout" by looking at 
the layout root's dirty bit.
   (note that "simplified normal-flow layout" is not supposed to get upgraded 
to "normal layout" during layout or
   "normal layout" downgraded to "simple".)
4. Only issue repaint in RenderLayer::recursiveUpdateLayerPositions() when the 
associated renderer
   participated in the most recent layout.

* Source/WebCore/page/LocalFrameViewLayoutContext.cpp:
(WebCore::LocalFrameViewLayoutContext::performLayout):
* Source/WebCore/page/LocalFrameViewLayoutContext.h:
* Source/WebCore/rendering/RenderElement.h:
(WebCore::RenderElement::setNormalFlowLayoutFrameId):
(WebCore::RenderElement::normalFlowLayoutFrameId const):
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::updateLayerPositionsAfterLayout):
(WebCore::RenderLayer::recursiveUpdateLayerPositions):
* Source/WebCore/rendering/RenderLayer.h:
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::clearNeedsLayout):
(WebCore::RenderObject::outputRenderObject const):
* Source/WebCore/rendering/RenderView.cpp: remove redundant clear.
(WebCore::RenderView::layout):

Canonical link: https://commits.webkit.org/279847@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

[NetBehaviour] one thirty-nine in the morning and long-necked saz

[Alan Sondheim via NetBehaviour]

one thirty-nine in the morning and long-necked saz

https://youtu.be/N5hH2Ku8X5A video

long-necked saz which i've described before, a truly wonderful
instrument with 8 strings in this configuration, the grace of
movement along the long neck of course, the body with the small
door that may be opened changing the sound, the supplication and
the care necessary to preserve and play it, and as i mentioned a
long time ago, traced the maker to a workshop in turkey and was
able to contact the his son since this is a true survivor and it
was as i mentioned before amir vahab who restored it and i feel
if there were a spirit they would be listening not to my playing
but to the sound of the instrument itself and i remember seeing
it in music inn in new york and then hearing just the sound and
there was an ethiopian 78 record decades and decades ago that
had a phrase that opened up within this and my false memories
tell me this was played first in the thin air of mars which
could not sustain the tone but the long-necked saz even there
triumphed and i worry when i pass who will play this and make
certain it survives everything today so fragile so becoming
unbecoming raveled and unraveled may the sound continue and may
it continue well and beyond the sound


___
NetBehaviour mailing list
NetBehaviour@lists.netbehaviour.org
https://lists.netbehaviour.org/mailman/listinfo/netbehaviour

[MOPO] Purchasing on eBay

[Alan Heimann]

I never knew that if you purchase
By making an offer you cannot pay for it from your PayPal balance ..they
will take it from yr linked bank account but if you do a buy it now then
payment can come out of PayPal balance 路

 Visit the MoPo Mailing List Web Site at www.filmfan.com
   ___
  How to UNSUBSCRIBE from the MoPo Mailing List

   Send a message addressed to: lists...@listserv.american.edu
In the BODY of your message type: SIGNOFF MOPO-L

The author of this message is solely responsible for its content.

[slurm-users] cpu distribution question

[Alan Stange via slurm-users]

All,

I have a very simple slurm cluster.  It's just a single system with 2
sockets and 16 cores in each socket.  I would like to be able to submit
a simple task into this cluster, and to have the cpus assigned to that
task allocated round robin across the two sockets.   Everything I try is
putting all the cpus for this single task on the same socket.

I have not specified any CpuBind options in the slurm.conf file.   For
example, if I try

$ srun -c 4 --pty bash

I get a shell prompt on the system, and can run

$ taskset -cp $$
pid 12345 current affinity list: 0,2,4,6

and I get this same set of cpus no matter what options I try (the
cluster is idle with no tasks consuming slots).

I've tried various srun command line options like:
--hint=compute_bound
--hint=memory_bound
various --cpubind options
-B 2:2 -m block:cyclic and block:fcyclic

Note that if I try to allocation 17 cpus, then I do get the 17th cpu
allocated on the 2nd socket.


What magic incantation is needed to get an allocation where the cpus are
chosen round robin across the sockets?

Thank you!

Alan


-- 
slurm-users mailing list -- slurm-users@lists.schedmd.com
To unsubscribe send an email to slurm-users-le...@lists.schedmd.com

[NTG-context] Re: missing space with French quotation

[Alan Braslau via ntg-context]

I have *never* understood how this works and, in fact, have always done
weird stuff like explicitly putting a nbps before double punctuation
(:;) in my document sources. I do this as it makes the sources much
more readable, preventing my text editor from ever breaking lines
before the punctuation (and not having some space in the source looks
awkward when reading French text).

I use:

\setupcharacterspacing
  [frenchpunctuation]
  [language=fr]
\mainlanguage [fr]
\setcharacterspacing [frenchpunctuation] % why necessary?
\setupitemize [symbol=2] % dash rather than bullet

This gives proper spacing with \quotation{} and with \startquotation
... \stopquotation. Also, {\en\quotation{}} and {\de\quotation{}} in
the document correctly do not add spaces.


Is \setupquotation[symstyle=\resetcharacterspacing]
necessary?

Alan



On Fri, 7 Jun 2024 14:18:19 +0200
Wolfgang Schuster  wrote:

> Peter Münster schrieb am 07.06.2024 um 13:31:
> > On Thu, May 30 2024, Peter Münster wrote:
> >   
> >> \mainlanguage[fr]
> >> \setcharacterspacing[frenchpunctuation]
> >> \starttext
> >> bla \quotation{OK} bla\\
> >> bla «OK» bla
> >> \startquotation
> >>Not Ok: a space is missing
> >> \stopquotation
> >> \stoptext  
> > 
> > It seems, that this workaround solves the problem:
> > \setupquotation[before={\setcharacterspacing[reset]}]  
> 
> 
> The quotation environment doesn't rely on the characterspacing
> mechanism to add the spaces before and the after the quotes but uses
> language dependent skips.
> 
> The example below shows how it works and where it fails when you use 
> characterspacing. Resetting spacing (and probably other settings like 
> charcterkerning etc.) when the quotes are added as you noticed fixes
> the problem.
> 
>  begin example
> \starttext
> 
> \dontleavehmode
> \hbox{«\hspace[fr][quotation]}%
> xxx%
> \hbox{\hspace[fr][quotation]»}
> 
> \setcharacterspacing[frenchpunctuation]
> 
> \dontleavehmode
> \hbox{«\hspace[fr][quotation]}%
> xxx%
> \hbox{\hspace[fr][quotation]»}
> 
> \dontleavehmode
> \hbox{\expand\everyresettypesetting\relax «\hspace[fr][quotation]}%
> xxx%
> \hbox{\expand\everyresettypesetting\relax \hspace[fr][quotation]»}
> 
> \stoptext
>  end example
> 
> > What do you think about it? Is this the right way to do it?  
> 
> I would use the symstyle key as hook to disable charcterspacing for
> the quotes in the environment.
> 
>  begin example
> \mainlanguage[fr]
> 
> \setcharacterspacing[frenchpunctuation]
> 
> 

> 
> \starttext
> 
> «xxx»
> 
> \startquotation xxx\stopquotation
> 
> \stoptext
>  end example
> 
> Wolfgang
> ___
> If your question is of interest to others as well, please add an
> entry to the Wiki!
> 
> maillist : ntg-context@ntg.nl /
> https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage  :
> https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
> archive  : https://github.com/contextgarden/context wiki :
> https://wiki.contextgarden.net
> ___


___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

Re: [PATCH 0/7] Remove some unused structures

[Dr. David Alan Gilbert]

* Dr. David Alan Gilbert (d...@treblig.org) wrote:
> A bunch of structs that are currently unused,
> found with a simple script and a bit of eyeballing.
> 
> The only one I'm that suspicious of is the SPARC
> one, where the patch which removed the use is a bit
> confusing to me.

Copying in Trivial; I think there are 4 of these that
are still outstanding:

   [PATCH 1/7] linux-user: cris: Remove unused struct 'rt_signal_frame'
  (Although cris is going)
   [PATCH 3/7] linux-user: sparc: Remove unused struct 'target_mc_fq'
   [PATCH 5/7] hw/arm/bcm2836: Remove unusued struct 'BCM283XClass'
   [PATCH 7/7] net/can: Remove unused struct 'CanBusState'

Can Trivial pick these up please?

Dave

> Tested with a 
>   
> --target-list=ppc-softmmu,m68k-softmmu,x86_64-softmmu,arm-softmmu,aarch64-softmmu,cris-linux-user,i386-linux-user,sparc-linux-user
> and 'make check' on x86 linux.
> 
> Dave
> 
> Dr. David Alan Gilbert (7):
>   linux-user: cris: Remove unused struct 'rt_signal_frame'
>   linux-user: i386/signal: Remove unused fp structs
>   linux-user: sparc: Remove unused struct 'target_mc_fq'
>   hw/usb/dev-network: Remove unused struct 'rndis_config_parameter'
>   hw/arm/bcm2836: Remove unusued struct 'BCM283XClass'
>   target/ppc: Remove unused struct 'mmu_ctx_hash32'
>   net/can: Remove unused struct 'CanBusState'
> 
>  hw/arm/bcm2836.c  | 12 
>  hw/usb/dev-network.c  |  8 
>  linux-user/cris/signal.c  |  8 
>  linux-user/i386/signal.c  | 10 --
>  linux-user/sparc/signal.c |  5 -
>  net/can/can_host.c|  6 --
>  target/ppc/mmu-hash32.c   |  6 --
>  7 files changed, 55 deletions(-)
> 
> -- 
> 2.45.0
> 
> 
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

[exim] Yet another taint problem.

[Thew, Alan via Exim-users]

Hi,

I have fixed an "easy" issue with file names in the past but have found that 
the following

  driver = accept
  condition = ${if match{$local_part}{-dmarc-}{yes}{no}}
  retry_use_local_part
  transport = listserv_pipe
  no_verify

fails with 

2024-06-05 10:49:55 1sEnHH-0008Ab-2d ** 
0003ccf76c45-dmarc-requ...@listserv7.liv.ac.uk R=dmarc_listserv 
T=listserv_pipe: Tainted arg 2 for listserv_pipe transport command: 
'0003ccf76c45-dmarc-request'

I have looked on the web but can't find a similar problem. Any help would be 
gratefully received.

Thanks

--
Alan Thew   alan.t...@liverpool.ac.uk
IT Services, University of Liverpool Phone: +44 151 794-4474


-- 
## subscription configuration (requires account):
##   https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
##   exim-users-unsubscr...@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

[Emu] Re: I-D Action: draft-ietf-emu-rfc7170bis-19.txt

[Alan DeKok]

  This version fixes a few typos found by Peter.

  It now includes all updates from IESG reviews, and I believe is good to go.

> On Jun 7, 2024, at 8:15 AM, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-emu-rfc7170bis-19.txt is now available. It is a work
> item of the EAP Method Update (EMU) WG of the IETF.
> 
>   Title:   Tunnel Extensible Authentication Protocol (TEAP) Version 1
>   Author:  Alan DeKok
>   Name:draft-ietf-emu-rfc7170bis-19.txt
>   Pages:   110
>   Dates:   2024-06-07
> 
> Abstract:
> 
>   This document defines the Tunnel Extensible Authentication Protocol
>   (TEAP) version 1.  TEAP is a tunnel-based EAP method that enables
>   secure communication between a peer and a server by using the
>   Transport Layer Security (TLS) protocol to establish a mutually
>   authenticated tunnel.  Within the tunnel, TLV objects are used to
>   convey authentication-related data between the EAP peer and the EAP
>   server.  This document obsoletes RFC 7170 and updates RFC 9427 by
>   moving all TEAP specifications from those documents to this one.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-19.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-emu-rfc7170bis-19
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> Emu mailing list -- emu@ietf.org
> To unsubscribe send an email to emu-le...@ietf.org

___
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org

Re: RFR: 8333599: Improve description of \b matcher in j.u.r.Pattern

[Alan Bateman]

On Thu, 6 Jun 2024 18:16:14 GMT, Raffaello Giulietti  
wrote:

> A documentation-only change to match the original intent and the implemented 
> behavior.

Yes, this one needs a CSR.

-

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19583#pullrequestreview-2103635744

Re: [NetBehaviour] "After the battle..."

[Alan Sondheim via NetBehaviour]

Hi Johannes,

I do wish you could do a walk-through of the exhibition w/ video and in 
English or subtitled - it comes through awkwardly for me and god knows 
we're all interested in this!


love, Alan, be well -

On Thu, 6 Jun 2024, Johannes Birringer via NetBehaviour wrote:


Date: Thu, 6 Jun 2024 10:29:15 +0200
From: Johannes Birringer via NetBehaviour

To: NetBehaviour for networked distributed creativity

Cc: Johannes Birringer 
Subject: Re: [NetBehaviour] "After the battle..."

Dear all,
some of you noted that our list is relatively quiet, and I am guessing there
are good reasons for it. We live in times when so many polarizing and
aggressive words are exchanged, and the rivers are rising (in the place
where I live).

But here, an announcement of an exhibition we recently opened at the gallery
where I work now (and on our website, front page, you find a link to a short
video from opening night):

After the battle all generals are fucked

Dream worlds on canvas by Bojan ?umonja & Marko Jak?e


Gallery Puzic?, Johannisstrasse 3A, 66111 Saarbru?cken, Germany // duration of
the exhibition 14/5. ? 19/6, 2024


https://gallery-puzic.com/


Gallery Puzi? cordially invites you to the presentation of two of the most
important and renowned artists in Central Europe
? Bojan ?umonja (Croatia) and Marko Jak?e (Slovenia). Bojan ?umonja is rightly
considered one of the most famous and recognized Croatian visual

artists of the last decades. He has exhibited independently over 100 times
across Europe and in

the USA. His works have, among others, been presented at independent
exhibitions in Venice,

Milan, Berlin, Hamburg, Vienna, Klagenfurt, Graz, Brussels, Ljubljana,
Luxembourg, New

Orleans, Zagreb, Dubrovnik and throughout Croatia. In his richly baroque
compositions, sheep,

gaunt flamingos, birds, downtrodden refugees and superheroes often appear,
in sometimes absurd

and dangerous scenarios of ecological, social and political catastrophes or
dystopian landscapes.

At the same time, complex ironic references (for which the artist was
celebrated as the first

?postmodernist? on the Croatian scene) wander through these dark battlefields -
quotes from silent films (Buster Keaton), classical art and Pop Art appear,
little Easter bunnies and other

cartoons figures run around after the battle. Or herds of people bow down
like African ostriches,

hiding their heads in the sand. ?umonja?s most recent paintings, as well as the
?collective? works

(One Dollar Bill) with Marko Jak?e, radiate striking chromatic peculiarities
and combine versatile

motifs and spatial systems.


The Slovenian artist Marko Jak?e is appreciated by art experts for his
expressive works with

contrasting elements and imaginative, poetic scenarios. For more than 30
years, his artistic

visions have been inspiring audiences with complex and multifaceted works
that have a unique

appeal and have already been awarded many prizes. Among many other
exhibition venues,

Marko Jak?e represented Slovenia at the 59th Venice Biennale (2022). A strong
source of

inspiration is the animal and plant world. The painterly results are
surreal-seeming worlds that

highlight the beauty of nature but also intertwine completely fantastic,
strange and surreal

elements.


The sarcastic title of our exhibition is aimed at the innovative image and
style combinations of

the two painters, whose fictional, mutated or real characters/natures
capture our imagination,

looking at us with strange grimaces, and also turn into melancholy dreams.
What is also quite

unusual for our Western artworld scene is the fact that the two artists
worked as a collective for

this exhibition, i.e. the paintings were designed and developed by both of
them together.



regards

Johannes Birringer

Concept Manager / Gallery Puzic?

https://gallery-puzic.com/


 
  On Thu, 6 Jun 2024 at 08:00, AGF  wrote:
  hi dear, your posts are welcome!
  agee

  > On 6. Jun 2024, at 6.56, Alan Sondheim via NetBehaviour
   wrote:
  >
  >
  > */i'm honestly not trying to dominate this list, i am
  more than
  > willing to stop posting here if others will post, sad to
  see this
  > quiet/*
  >
  > dark rasa / sickness
  >
  > https://youtu.be/IkW_-wzOIgY video
  >


___
NetBehaviour mailing list
NetBehaviour@lists.netbehaviour.org
https://lists.netbehaviour.org/mailman/listinfo/netbehaviour

Re: [NetBehaviour] dark rasa / sickness

[Alan Sondheim via NetBehaviour]

thanks, will do, I wish there was still more of a community, the list has 
the numbers for it (I think), I've learned so much from other people here. 
I get tired of Fb or other platforms; lists have the real possibiity of 
discussion (and are of course used that way in medicine, education, etc.) 
- ah well...


best to everyone, Alan

On Thu, 6 Jun 2024, Simon Mclennan via NetBehaviour wrote:


Date: Thu, 6 Jun 2024 17:46:59 +0100
From: Simon Mclennan via NetBehaviour 
To: netbehaviour@lists.netbehaviour.org
Cc: Simon Mclennan , m...@memecortex.net
Subject: Re: [NetBehaviour] dark rasa / sickness


Alan keep on keeping on!


On Thu, 6 Jun 2024, 09:14 Mark Hancock via NetBehaviour,
 wrote:
  Hey Alan,
I second Agee's comment, keep posting.

Frankly, (based on my social media) if I were to post regularly, it
would mostly be adolescent fart jokes, anti-fascist rhetoric, and
about once every 6 weeks, a piece of video art.

I suspect that only two of those would be welcome. And I'm not sure
about the anti-fascist rhetoric.

Love to all wherever and whatever you're going through right now.

Mark

On Thu, 6 Jun 2024 at 08:00, AGF  wrote:
  hi dear, your posts are welcome!
  agee

  > On 6. Jun 2024, at 6.56, Alan Sondheim via NetBehaviour
   wrote:
  >
  >
  > */i'm honestly not trying to dominate this list, i am
  more than
  > willing to stop posting here if others will post, sad to
  see this
  > quiet/*
  >
  > dark rasa / sickness
  >
  > https://youtu.be/IkW_-wzOIgY video
  >
  > Experiments possible worlds and natural kinds are
  exhausted, i'm
  > so tired now, editing, listening, with phenomena,
  exhausted with
  > debris, granular, articulation, sick with phenomena,
  exhausted
  > with debris, granular, exhausted, afterthoughts,
  contraries,
  > waywards, unutterables, hirsute, ill, sick with
  phenomena,
  > exhausted with debris, exhausted as usual, moody as
  usual. Been
  > reading Giorgio Agam- fall to the ground . they're so
  tired of
  > shooting machinery. exhausted being. what "out there"
  never
  > "what," there"; what's the tiredness didn't notice
  anything. But
  > one thing I can continue to a tired keening. The corpse
  is mine,
  > jus a hhngar for sleep; always exhausted, my judgamant
  ls not of
  > tha exhausted with debris, granular, articulation,
  catastrophic
  > and too tired to think about it. The last section of the
  music
  > Your psychotic other other people. I'm tired of being
  inserted
  > have exhausted me; diary have nothing to say, have
  exhausted
  > signals. we have exhausted ourselves. we have exhausted
  me, none
  > of object or subject, waves which dissolve as if
  exhausted
  > tended get get of rid weak weak exhausted people by
  exhausted
  > there is, nothing more; it exhausts itself and is
  exhausted and
  > needed medical attention soon. They also felt exhausted
  and sm
  > exits in name only, and tired bartenders pour wine and
  dreaming
  > beside the gendered or exhausted body (the second the
  obdurate
  > and obstructive real, absorb the exhausted language so
  tired
  > from working and worrying this particular video of the
  I'm still
  > exhausted a lot of the time. I don't seem to be able I'm
  so
  > tired of these shapes which seem inconceivable
  catastrophe
  > theory exhausted within and without an inconceivable
  give devils
  > their side: less, exhausted, myriad beings while
  anything,
  > plague increased less, exhausted, myriad beings while
  ers are
  > there numbers here I'm so tired of this please tell me
  tired of
  > defending myself. stdin. i'm tired of armageddon andre a
  joke
  > ers are there numbers here I'm so tired of this please
  > limitless, collapsing, extinguishing./* exhausted
  discoruse you
  > looking for numbers are there numbers here I'm so tired
  of
  > significant effects, the name Agnes was retired in the
  spring of
  > complaynt as it might be written, people are tired of
  reading
  > the left and the other other people. I'm tired of being
  >
  > I am tired as a car, but I'm not falling asleep. I'm
  following
  > being out w/ long covid, so tired of saying there's not
  much to
  > go on I'm so tired of these shapes which It's completely
  > understandable to feel tired, and typing with ers tired
  Hoq sis
  > qhf fwr rlal qhwn yuou ewnor nar ro muxh did this and
  I'm wrong
  > in it where is I'm so tired I can'

[NetBehaviour] it's just about the music wtc

[Alan Sondheim via NetBehaviour]

it's just about the music wtc

https://youtu.be/NK9gX8TNm1M video

it's just about the music, forget the distraction or perhaps
forget the music or forgo the distraction or music or forge
thereabouts one or the other, look, people are going to new
york, people are escaping, there's too much pollen here on
the roads, slid-sliding away, not even the music, listen, i
keep on moving backwards, fogged out, roiled in such a way
that i return topologically to where i began when this all
began we will mount a galleon and sail and land on the very
roof of the world trade center 1 world trade center 2, high
and mounted once again topologically in the sky, or one to
another as i had looked across the expanse a quarter mile
up before they came down and looked on the screen from miami
and people laughing and there and people burning there, the
other there, and saying what's this has to do with me and it
had everything to do with them and me and all of us and now
now now now now now it's just about the music and traffic
and we don't know ourselves looking out of the mirror into
that broken shattered space and never returned and here in
this foreign land the sign to new york this way to new
york there's no other way to new york you can't get to new
york and _you only belong where you don't belong_ no matter
how you think about it trapped in that thinking thought or
or or or how you cut your shadow out from the face of the
earth then cut yourself in a proxy trial as if we had this
or any other choice because it's just about the music it's
just about the music it's just about the music it's just
about


___
___
NetBehaviour mailing list
NetBehaviour@lists.netbehaviour.org
https://lists.netbehaviour.org/mailman/listinfo/netbehaviour

Re: run PSPP

[Alan Mead]

I know nothing about home brew, but ChatGPT suggests 'open'. Here's the 
example it gave (using Firefox as an example):


brew install --cask firefox
open -a Firefox

These would be typed in 'sh'. I hope that's correct information. I have 
no idea how to open sh/Terminal.



On 6/6/24 12:31, Александр Роненсон wrote:

hi i am sorry
i instaled PSPP using home-brew but i dont understand how to open application) 
could you hellp me?


--

Alan D. Mead, Ph.D.
President, Talent Algorithms Inc.

science + technology = better workers

https://talalg.com


He who confuses political liberty with freedom and political equality
with similarity has never thought for five minutes about either.

-- Shaw, from "Maxims for Revolutionists"

Re: Bug sistema

[Alan Mead]

English: Please post these details: What version of the software are you 
using (Help > About)? What operating system are you using? What are the 
steps I should do to replicate the problem (e.g., how are you trying to 
insert a new variable)? When you say a bug appears, is there an error 
message? What is the message? Does the bug happen each time you try to 
insert a new variable? Does the bug go away if you reboot your computer?


Italiano (tradotto da una macchina): Per favore, invia questi dettagli: 
Quale versione del software stai utilizzando (Aiuto > Informazioni)? 
Quale sistema operativo stai utilizzando? Quali sono i passaggi che 
dovrei seguire per replicare il problema (ad esempio, come stai cercando 
di inserire una nuova variabile)? Quando dici che appare un bug, c'è un 
messaggio di errore? Qual è il messaggio? Il bug si verifica ogni volta 
che provi a inserire una nuova variabile? Il bug scompare se riavvii il 
computer?



On 6/5/24 10:36, ANNA SOFIA RIBIANI wrote:

Buonasera,
ho riscontrato un bug nel sistema del programma pspp.
Quando provo a inserire una nuova variabile mi spunta il bug e si 
chiude tutto.

Attendo risposta.


--

Alan D. Mead, Ph.D.
President, Talent Algorithms Inc.

science + technology = better workers

https://talalg.com


He who confuses political liberty with freedom and political equality
with similarity has never thought for five minutes about either.

-- Shaw, from "Maxims for Revolutionists"

[oss-security] PHP security releases 8.3.8, 8.2.20, and 8.1.29

[Alan Coopersmith]

In https://fosstodon.org/@php/112570710411472992 it is written:


Announcing the availability of:

- PHP 8.3.8
- PHP 8.2.20
- PHP 8.1.29

‼️ These SECURITY releases fix:

- Argument Injection in PHP-CGI
- Bypass in filter_var FILTER_VALIDATE_URL
- proc_open workaround Windows with escaping arguments for bat/cmd files
- openssl_private_decrypt vulnerability to the Marvin attack

Please upgrade ASAP.

Changelog: https://www.php.net/ChangeLog-8.php
Source: https://www.php.net/downloads


The Changelog link includes further details:

 - Fixed bug GHSA-3qgc-jrrr-25jv (Bypass of CVE-2012-1823, Argument Injection
   in PHP-CGI). (CVE-2024-4577)

 - Fixed bug GHSA-w8qr-v226-r27w (Filter bypass in filter_var
   FILTER_VALIDATE_URL). (CVE-2024-5458)

 - Fixed bug GHSA-9fcc-425m-g385 (Bypass of CVE-2024-1874). (CVE-2024-5585)

 - The openssl_private_decrypt function in PHP, when using PKCS1 padding
   (OPENSSL_PKCS1_PADDING, which is the default), is vulnerable to the
   Marvin Attack unless it is used with an OpenSSL version that includes
   the changes from this pull request:
   https://github.com/openssl/openssl/pull/13817
   (rsa_pkcs1_implicit_rejection). These changes are part of OpenSSL 3.2
   and have also been backported to stable versions of various Linux
   distributions, as well as to the PHP builds provided for Windows since
   the previous release. All distributors and builders should ensure that
   this version is used to prevent PHP from being vulnerable.

Unfortunately the related advisories don't seem to be published yet under those
GHSA id's on https://github.com/php/php-src/security .

--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Re: Can't Remote connection by IpV6

[Alan Hodgson]

On Thu, 2024-06-06 at 11:46 -0300, Marcelo Marloch wrote:
> Hi everyone, is it possible to remote connect through IpV6? IpV4
> works fine but I cant connect through V6 
> 
> postgresql.conf is to listen all address and pg_hba.conf is set
> with host all all :: md5 i've tried ::/0 and ::0/0 but had no
> success
> 
> my provider is out of ipv4 and they're sending ips by cgnat if I
> want a public ipv4 I have to sign a very expensive service fee  
> 
> thanks a lot

listen '*'

or listen '::' just for ipv6.

Remember to adjust pg_hba.conf as well.

git: 60107d23d8f2 - main - ctladm.8: fix several errors in the "port" section

[Alan Somers]

The branch main has been updated by asomers:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=60107d23d8f2c05f418c024000a31a6148d2f7de

commit 60107d23d8f2c05f418c024000a31a6148d2f7de
Author: Alan Somers 
AuthorDate: 2024-06-05 20:13:04 +
Commit: Alan Somers 
CommitDate: 2024-06-06 17:22:06 +

ctladm.8: fix several errors in the "port" section

* Document the "-d" option.
* Add the "-c" and "-r" options to the summary.
* Correct the list of required options.
* Clarify that the "-t" option is only for use with "-o", "-w", and "-W"
* Replace references to the nonexistent "-n" with "-p".

Also, fix a few related error strings in the ctladm command.

MFC after:  2 weeks
Sponsored by:   Axcient
Reviewed by:jhb
Differential Revision: https://reviews.freebsd.org/D45503
---
 usr.sbin/ctladm/ctladm.8 | 32 
 usr.sbin/ctladm/ctladm.c |  7 ---
 2 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/usr.sbin/ctladm/ctladm.8 b/usr.sbin/ctladm/ctladm.8
index 2c90e12ef924..b3af4b45ba26 100644
--- a/usr.sbin/ctladm/ctladm.8
+++ b/usr.sbin/ctladm/ctladm.8
@@ -35,7 +35,7 @@
 .\"
 .\" $Id: //depot/users/kenm/FreeBSD-test2/usr.sbin/ctladm/ctladm.8#3 $
 .\"
-.Dd May 2, 2024
+.Dd June 5, 2024
 .Dt CTLADM 8
 .Os
 .Sh NAME
@@ -162,6 +162,7 @@
 .Nm
 .Ic port
 .Op Fl c
+.Op Fl d Ar driver
 .Op Fl o Ar on|off
 .Op Fl w Ar wwpn
 .Op Fl W Ar wwnn
@@ -598,6 +599,10 @@ The serial number is returned when the error is injected.
 Perform one of several CTL frontend port operations.
 Either get a list of frontend ports
 .Pq Fl l ,
+create a new frontend port
+.Pq Fl c ,
+destroy a frontend port
+.Pq Fl r ,
 turn one or more frontends on
 or off
 .Pq Fl o Ar on|off ,
@@ -607,6 +612,8 @@ or World Wide Port Name
 .Pq Fl W Ar wwpn
 for a given port.
 One of
+.Fl c ,
+.Fl r ,
 .Fl l ,
 .Fl o ,
 or
@@ -619,6 +626,18 @@ combined with enabling/disabling or listing ports.
 .Bl -tag -width 12n
 .It Fl c
 Create new frontend port using free pp and vp=0.
+.It Fl d Ar driver
+Specify the name of the frontend driver used by the
+.Pq Fl c
+or
+.Pq Fl r
+subcommands.
+Valid driver names include
+.Dq ioctl ,
+.Dq iscsi ,
+and
+.Dq nvmf ,
+but more can be added by external kernel modules.
 .It Fl o Ar on|off
 Turn the specified CTL frontend ports on or off.
 If no port number or port type is specified, all ports are turned on or
@@ -633,7 +652,12 @@ The port numbers can be found in the frontend port list.
 Remove port specified with
 .Pq Fl p Ar targ_port .
 .It Fl t Ar fe_type
-Specify the frontend type.
+Specify the frontend type used by the
+.Pq Fl o ,
+.Pq Fl w ,
+and
+.Pq Fl W
+subcommands.
 Currently defined port types are
 .Dq fc
 (Fibre Channel),
@@ -647,7 +671,7 @@ and
 .It Fl w Ar wwnn
 Set the World Wide Node Name for the given port.
 The
-.Fl n
+.Fl p
 argument must be specified, since this is only possible to implement on a
 single port.
 As a general rule, the WWNN should be the same across all ports on the
@@ -655,7 +679,7 @@ system.
 .It Fl W Ar wwpn
 Set the World Wide Port Name for the given port.
 The
-.Fl n
+.Fl p
 argument must be specified, since this is only possible to implement on a
 single port.
 As a general rule, the WWPN must be different for every port in the system.
diff --git a/usr.sbin/ctladm/ctladm.c b/usr.sbin/ctladm/ctladm.c
index 688281238fb0..28f9a39386d3 100644
--- a/usr.sbin/ctladm/ctladm.c
+++ b/usr.sbin/ctladm/ctladm.c
@@ -546,7 +546,7 @@ cctl_port(int fd, int argc, char **argv, char *combinedopt)
 * we'll throw an error, since that only works on one port at a time.
 */
if ((port_type != CTL_PORT_NONE) && (targ_port != -1)) {
-   warnx("%s: can only specify one of -t or -n", __func__);
+   warnx("%s: can only specify one of -t or -p", __func__);
retval = 1;
goto bailout;
} else if ((targ_port == -1) && (port_type == CTL_PORT_NONE))
@@ -630,7 +630,7 @@ cctl_port(int fd, int argc, char **argv, char *combinedopt)
}
case CCTL_PORT_MODE_SET:
if (targ_port == -1) {
-   warnx("%s: -w and -W require -n", __func__);
+   warnx("%s: -w and -W require -p", __func__);
retval = 1;
goto bailout;
}
@@ -679,7 +679,8 @@ bailout:
return (retval);
 
 bailout_badarg:
-   warnx("%s: only one of -l, -o or -w/-W may be specified", __func__);
+   warnx("%s: only one of -c, -r, -l, -o or -w/-W may be specified",
+   __func__);
return (1);
 }
 

git: 60107d23d8f2 - main - ctladm.8: fix several errors in the "port" section

[Alan Somers]

The branch main has been updated by asomers:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=60107d23d8f2c05f418c024000a31a6148d2f7de

commit 60107d23d8f2c05f418c024000a31a6148d2f7de
Author: Alan Somers 
AuthorDate: 2024-06-05 20:13:04 +
Commit: Alan Somers 
CommitDate: 2024-06-06 17:22:06 +

ctladm.8: fix several errors in the "port" section

* Document the "-d" option.
* Add the "-c" and "-r" options to the summary.
* Correct the list of required options.
* Clarify that the "-t" option is only for use with "-o", "-w", and "-W"
* Replace references to the nonexistent "-n" with "-p".

Also, fix a few related error strings in the ctladm command.

MFC after:  2 weeks
Sponsored by:   Axcient
Reviewed by:jhb
Differential Revision: https://reviews.freebsd.org/D45503
---
 usr.sbin/ctladm/ctladm.8 | 32 
 usr.sbin/ctladm/ctladm.c |  7 ---
 2 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/usr.sbin/ctladm/ctladm.8 b/usr.sbin/ctladm/ctladm.8
index 2c90e12ef924..b3af4b45ba26 100644
--- a/usr.sbin/ctladm/ctladm.8
+++ b/usr.sbin/ctladm/ctladm.8
@@ -35,7 +35,7 @@
 .\"
 .\" $Id: //depot/users/kenm/FreeBSD-test2/usr.sbin/ctladm/ctladm.8#3 $
 .\"
-.Dd May 2, 2024
+.Dd June 5, 2024
 .Dt CTLADM 8
 .Os
 .Sh NAME
@@ -162,6 +162,7 @@
 .Nm
 .Ic port
 .Op Fl c
+.Op Fl d Ar driver
 .Op Fl o Ar on|off
 .Op Fl w Ar wwpn
 .Op Fl W Ar wwnn
@@ -598,6 +599,10 @@ The serial number is returned when the error is injected.
 Perform one of several CTL frontend port operations.
 Either get a list of frontend ports
 .Pq Fl l ,
+create a new frontend port
+.Pq Fl c ,
+destroy a frontend port
+.Pq Fl r ,
 turn one or more frontends on
 or off
 .Pq Fl o Ar on|off ,
@@ -607,6 +612,8 @@ or World Wide Port Name
 .Pq Fl W Ar wwpn
 for a given port.
 One of
+.Fl c ,
+.Fl r ,
 .Fl l ,
 .Fl o ,
 or
@@ -619,6 +626,18 @@ combined with enabling/disabling or listing ports.
 .Bl -tag -width 12n
 .It Fl c
 Create new frontend port using free pp and vp=0.
+.It Fl d Ar driver
+Specify the name of the frontend driver used by the
+.Pq Fl c
+or
+.Pq Fl r
+subcommands.
+Valid driver names include
+.Dq ioctl ,
+.Dq iscsi ,
+and
+.Dq nvmf ,
+but more can be added by external kernel modules.
 .It Fl o Ar on|off
 Turn the specified CTL frontend ports on or off.
 If no port number or port type is specified, all ports are turned on or
@@ -633,7 +652,12 @@ The port numbers can be found in the frontend port list.
 Remove port specified with
 .Pq Fl p Ar targ_port .
 .It Fl t Ar fe_type
-Specify the frontend type.
+Specify the frontend type used by the
+.Pq Fl o ,
+.Pq Fl w ,
+and
+.Pq Fl W
+subcommands.
 Currently defined port types are
 .Dq fc
 (Fibre Channel),
@@ -647,7 +671,7 @@ and
 .It Fl w Ar wwnn
 Set the World Wide Node Name for the given port.
 The
-.Fl n
+.Fl p
 argument must be specified, since this is only possible to implement on a
 single port.
 As a general rule, the WWNN should be the same across all ports on the
@@ -655,7 +679,7 @@ system.
 .It Fl W Ar wwpn
 Set the World Wide Port Name for the given port.
 The
-.Fl n
+.Fl p
 argument must be specified, since this is only possible to implement on a
 single port.
 As a general rule, the WWPN must be different for every port in the system.
diff --git a/usr.sbin/ctladm/ctladm.c b/usr.sbin/ctladm/ctladm.c
index 688281238fb0..28f9a39386d3 100644
--- a/usr.sbin/ctladm/ctladm.c
+++ b/usr.sbin/ctladm/ctladm.c
@@ -546,7 +546,7 @@ cctl_port(int fd, int argc, char **argv, char *combinedopt)
 * we'll throw an error, since that only works on one port at a time.
 */
if ((port_type != CTL_PORT_NONE) && (targ_port != -1)) {
-   warnx("%s: can only specify one of -t or -n", __func__);
+   warnx("%s: can only specify one of -t or -p", __func__);
retval = 1;
goto bailout;
} else if ((targ_port == -1) && (port_type == CTL_PORT_NONE))
@@ -630,7 +630,7 @@ cctl_port(int fd, int argc, char **argv, char *combinedopt)
}
case CCTL_PORT_MODE_SET:
if (targ_port == -1) {
-   warnx("%s: -w and -W require -n", __func__);
+   warnx("%s: -w and -W require -p", __func__);
retval = 1;
goto bailout;
}
@@ -679,7 +679,8 @@ bailout:
return (retval);
 
 bailout_badarg:
-   warnx("%s: only one of -l, -o or -w/-W may be specified", __func__);
+   warnx("%s: only one of -c, -r, -l, -o or -w/-W may be specified",
+   __func__);
return (1);
 }
 

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v32]

[Alan Bateman]

On Thu, 6 Jun 2024 10:42:20 GMT, Alan Bateman  wrote:

>> Severin Gehwolf has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Fix default description of keep-packaged-modules
>
> I've read through all src changes. I think Sundar is looking at the code 
> changes too.
> 
> The overall design seems solid. I know it took a long time to get there but 
> this is nature of a feature like this. At this point I regret that there 
> isn't a JEP. A JEP would have captured the motivation, outlined the design, 
> the reasoning for the restrictions, and document the design 
> choices/directions that have been prototyped. If there isn't a JEP then I 
> suppose it can come later if the feature is progressed and there is 
> discussion about making it the default rather than opt-in at build configure 
> time.
> 
> As cleanup, I think we will need to bring some consistency to the terminology 
> and phrasing in documentation, code and comments. Right now there is 
> "run-time linking", "linkable run-time", "run-time linkable JDK image", 
> "linkable jimage".
> 
> Also as cleanup, I think the code needs more comments. There is no JEP right 
> now with an authoritive description of the feature so anyone maintaining this 
> code will have to figure out a lot of details. It feels like there should be 
> somehting that documents the effect of --enable-runtime-link-image, how the 
> diffs are generated and saved, and how they are used by jlink. There is also 
> a lot of new code in ImageFileCreator and JlinkTask that is asking for some 
> method descriptions so that anyone touching this code can quickly understand 
> what these methods are doing. I don't want to get into code style issues now 
> but I think it would be helpful for future maintainers to avoid more of the 
> overfly long lines if possible (some of them are 150, 160, 170+ and really 
> hard to look at code side-by-side).

> @AlanBateman Sure, I appreciate the feedback. Do I understand it correctly 
> that this won't get into JDK 23 then? If so, perhaps the better way would be 
> to draft a JEP for JDK 24 and get that proposed early. What I'd like to avoid 
> is for this change to don't see much movement for a long time between now and 
> RDP 1 of JDK 24 and have a similar crunch when JDK 24 is close to forking. 
> You mention clean-up a lot. Is that suggesting it _can_ go into JDK 23 and 
> clean-up in ramp-down? I'm confused...
> 
> Some clarity on how to best approach getting this integrated that would be 
> acceptable for all involved would be appreciated. Thanks!

The fork for JDK 23 is today so if I was running with this feature then I 
wouldn't integrate it today. If you are willing to put the time into writing a 
JEP then I think it's the right thing to do. We should probably have brought 
this up long before now. I'm happy to help review iterations. There is a lot to 
write down and this will be very valuable for future phases of this work. I 
assume future phases. We agreed some restrictions to reduce complexity for this 
first phase. Future phases may remove these and maybe there is confidence in 
the future to make it default.

-

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2152576950

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v32]

[Alan Bateman]

On Thu, 6 Jun 2024 10:42:20 GMT, Alan Bateman  wrote:

>> Severin Gehwolf has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Fix default description of keep-packaged-modules
>
> I've read through all src changes. I think Sundar is looking at the code 
> changes too.
> 
> The overall design seems solid. I know it took a long time to get there but 
> this is nature of a feature like this. At this point I regret that there 
> isn't a JEP. A JEP would have captured the motivation, outlined the design, 
> the reasoning for the restrictions, and document the design 
> choices/directions that have been prototyped. If there isn't a JEP then I 
> suppose it can come later if the feature is progressed and there is 
> discussion about making it the default rather than opt-in at build configure 
> time.
> 
> As cleanup, I think we will need to bring some consistency to the terminology 
> and phrasing in documentation, code and comments. Right now there is 
> "run-time linking", "linkable run-time", "run-time linkable JDK image", 
> "linkable jimage".
> 
> Also as cleanup, I think the code needs more comments. There is no JEP right 
> now with an authoritive description of the feature so anyone maintaining this 
> code will have to figure out a lot of details. It feels like there should be 
> somehting that documents the effect of --enable-runtime-link-image, how the 
> diffs are generated and saved, and how they are used by jlink. There is also 
> a lot of new code in ImageFileCreator and JlinkTask that is asking for some 
> method descriptions so that anyone touching this code can quickly understand 
> what these methods are doing. I don't want to get into code style issues now 
> but I think it would be helpful for future maintainers to avoid more of the 
> overfly long lines if possible (some of them are 150, 160, 170+ and really 
> hard to look at code side-by-side).

> @AlanBateman Sure, I appreciate the feedback. Do I understand it correctly 
> that this won't get into JDK 23 then? If so, perhaps the better way would be 
> to draft a JEP for JDK 24 and get that proposed early. What I'd like to avoid 
> is for this change to don't see much movement for a long time between now and 
> RDP 1 of JDK 24 and have a similar crunch when JDK 24 is close to forking. 
> You mention clean-up a lot. Is that suggesting it _can_ go into JDK 23 and 
> clean-up in ramp-down? I'm confused...
> 
> Some clarity on how to best approach getting this integrated that would be 
> acceptable for all involved would be appreciated. Thanks!

The fork for JDK 23 is today so if I was running with this feature then I 
wouldn't integrate it today. If you are willing to put the time into writing a 
JEP then I think it's the right thing to do. We should probably have brought 
this up long before now. I'm happy to help review iterations. There is a lot to 
write down and this will be very valuable for future phases of this work. I 
assume future phases. We agreed some restrictions to reduce complexity for this 
first phase. Future phases may remove these and maybe there is confidence in 
the future to make it default.

-

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2152576950

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v32]

[Alan Bateman]

On Thu, 6 Jun 2024 09:47:30 GMT, Severin Gehwolf  wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't 
>> need the packaged modules being present. A.k.a run-time image based jlink. 
>> Fundamentally this patch adds an option to use `jlink` even though your JDK 
>> install might not come with the packaged modules (directory `jmods`). This 
>> is particularly useful to further reduce the size of a jlinked runtime. 
>> After the removal of the concept of a JRE, a common distribution mechanism 
>> is still the full JDK with all modules and packaged modules. However, 
>> packaged modules can incur an additional size tax. For example in a 
>> container scenario it could be useful to have a base JDK container including 
>> all modules, but without also delivering the packaged modules. This comes at 
>> a size advantage of `~25%`. Such a base JDK container could then be used to 
>> `jlink` application specific runtimes, further reducing the size of the 
>> application runtime image (App + JDK runtime; as a single image *or* 
>> separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking 
>> non-class and non-resource files of a JDK install. I.e. files which aren't 
>> present in the jimage (`lib/modules`). This enables producing a `JRTArchive` 
>> class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) 
>> <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules 
>> --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) 
>> <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules 
>> --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmodjava.net.http.jmod   java.sql.rowset.jmod  
>> jdk.crypto.ec.jmod jdk.internal.opt.jmod 
>> jdk.jdi.jmod jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmodjava.prefs.jmod  java.transaction.xa.jmod  
>> jdk.dynalink.jmod  jdk.internal.vm.ci.jmod   
>> jdk.jdwp.agent.jmod  jdk.management.jfr.jmodjdk.security.jgss.jmod
>> java.datatransfer.jmodjava.rmi.jmodjava.xml.crypto.jmod  
>> jdk.editpad.jmod   jdk.internal.vm.compiler.jmod 
>> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
>> java.desktop.jmod java.scripting.jmod  java.xml.jmod 
>> jdk.hotspot.agent.jmod jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Fix default description of keep-packaged-modules

I've read through all src changes. I think Sundar is looking at the code 
changes too.

The overall design seems solid. I know it took a long time to get there but 
this is nature of a feature like this. At this point I regret that there isn't 
a JEP. A JEP would have captured the motivation, outlined the design, the 
reasoning for the restrictions, and document the design choices/directions that 
have been prototyped. If there isn't a JEP then I suppose it can come later if 
the feature is progressed and there is discussion about making it the default 
rather than opt-in at build configure time.

As cleanup, I think we will need to bring some consistency to the terminology 
and phrasing in documentation, code and comments. Right now there is "run-time 
linking", "linkable run-time", "run-time linkable JDK image", "linkable jimage".

Also as cleanup, I think the code needs more comments. There is no JEP right 
now with an authoritive description of the feature so anyone maintaining this 
code will have to figure out a lot of details. It feels like there should be 
somehting that documents the effect of --enable-runtime-link-image, how the 
diffs are generated and saved, and how they are used by jlink. There is also a 
lot of new code in ImageFileCreator and JlinkTask that is asking for some 
method descriptions so that anyone touching this code can quickly understand 
what these methods are doing. I don't want to get into code style issues now 
but I think it would be helpful for future maintainers to avoid more of the 
overfly long lines if possible (some of them are 150, 160, 170+ and really hard 
to look at code side-by-side).

-

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2151964298

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v32]

[Alan Bateman]

On Thu, 6 Jun 2024 09:47:30 GMT, Severin Gehwolf  wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't 
>> need the packaged modules being present. A.k.a run-time image based jlink. 
>> Fundamentally this patch adds an option to use `jlink` even though your JDK 
>> install might not come with the packaged modules (directory `jmods`). This 
>> is particularly useful to further reduce the size of a jlinked runtime. 
>> After the removal of the concept of a JRE, a common distribution mechanism 
>> is still the full JDK with all modules and packaged modules. However, 
>> packaged modules can incur an additional size tax. For example in a 
>> container scenario it could be useful to have a base JDK container including 
>> all modules, but without also delivering the packaged modules. This comes at 
>> a size advantage of `~25%`. Such a base JDK container could then be used to 
>> `jlink` application specific runtimes, further reducing the size of the 
>> application runtime image (App + JDK runtime; as a single image *or* 
>> separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking 
>> non-class and non-resource files of a JDK install. I.e. files which aren't 
>> present in the jimage (`lib/modules`). This enables producing a `JRTArchive` 
>> class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) 
>> <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules 
>> --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) 
>> <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules 
>> --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmodjava.net.http.jmod   java.sql.rowset.jmod  
>> jdk.crypto.ec.jmod jdk.internal.opt.jmod 
>> jdk.jdi.jmod jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmodjava.prefs.jmod  java.transaction.xa.jmod  
>> jdk.dynalink.jmod  jdk.internal.vm.ci.jmod   
>> jdk.jdwp.agent.jmod  jdk.management.jfr.jmodjdk.security.jgss.jmod
>> java.datatransfer.jmodjava.rmi.jmodjava.xml.crypto.jmod  
>> jdk.editpad.jmod   jdk.internal.vm.compiler.jmod 
>> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
>> java.desktop.jmod java.scripting.jmod  java.xml.jmod 
>> jdk.hotspot.agent.jmod jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Fix default description of keep-packaged-modules

I've read through all src changes. I think Sundar is looking at the code 
changes too.

The overall design seems solid. I know it took a long time to get there but 
this is nature of a feature like this. At this point I regret that there isn't 
a JEP. A JEP would have captured the motivation, outlined the design, the 
reasoning for the restrictions, and document the design choices/directions that 
have been prototyped. If there isn't a JEP then I suppose it can come later if 
the feature is progressed and there is discussion about making it the default 
rather than opt-in at build configure time.

As cleanup, I think we will need to bring some consistency to the terminology 
and phrasing in documentation, code and comments. Right now there is "run-time 
linking", "linkable run-time", "run-time linkable JDK image", "linkable jimage".

Also as cleanup, I think the code needs more comments. There is no JEP right 
now with an authoritive description of the feature so anyone maintaining this 
code will have to figure out a lot of details. It feels like there should be 
somehting that documents the effect of --enable-runtime-link-image, how the 
diffs are generated and saved, and how they are used by jlink. There is also a 
lot of new code in ImageFileCreator and JlinkTask that is asking for some 
method descriptions so that anyone touching this code can quickly understand 
what these methods are doing. I don't want to get into code style issues now 
but I think it would be helpful for future maintainers to avoid more of the 
overfly long lines if possible (some of them are 150, 160, 170+ and really hard 
to look at code side-by-side).

-

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2151964298

[gentoo-user] emerge pattern....

[Alan Grimes]

I'm trying to do the steps for the forced profile update even though 
things had been working perfectly


Emerge has been doing really crazy things recently.

It will start emerging a thousand packages but not install a single one 
of them.
Then it crashes with a bunch of python garbage having made absolutely no 
progress whatsoever.


Is there any way I can FORCE emerge to attempt the install IMMEDIATELY 
after the build stage completes UNCONDITIONALLY?


damnit, I was trying to shift my bedtime back to 3 am... now 4:42 am

Ran it again just to capture the error barf so therefore it seems to be 
working, at least it is installing stuff after compiling like 950 
packages in a single stretch


Why

Just why.

I mean there cannot be any advantage to having a compile dozens of 
things in a batch and then install everything one at a time, in a 
batch... I mean usually everything should just compile and install 
concurrently across 64 cores with only a handful of concurrency locks 
needed to maintain a minimal amount of sanity. I mean that actually used 
to work... I've been using multi-core systems since before I started 
using gentoo, and never had an issue attributable to multiprocessing... 
If I did, I just hit it with an emerge --resume and never complained 
about it


--
You can't out-crazy a Democrat.
#EggCrisis  #BlackWinter
White is the new Kulak.
Powers are not rights.

[NetBehaviour] dark rasa / sickness

[Alan Sondheim via NetBehaviour]

*/i'm honestly not trying to dominate this list, i am more than
willing to stop posting here if others will post, sad to see this
quiet/*

dark rasa / sickness

https://youtu.be/IkW_-wzOIgY video

Experiments possible worlds and natural kinds are exhausted, i'm
so tired now, editing, listening, with phenomena, exhausted with
debris, granular, articulation, sick with phenomena, exhausted
with debris, granular, exhausted, afterthoughts, contraries,
waywards, unutterables, hirsute, ill, sick with phenomena,
exhausted with debris, exhausted as usual, moody as usual. Been
reading Giorgio Agam- fall to the ground . they're so tired of
shooting machinery. exhausted being. what "out there" never
"what," there"; what's the tiredness didn't notice anything. But
one thing I can continue to a tired keening. The corpse is mine,
jus a hhngar for sleep; always exhausted, my judgamant ls not of
tha exhausted with debris, granular, articulation, catastrophic
and too tired to think about it. The last section of the music
Your psychotic other other people. I'm tired of being inserted
have exhausted me; diary have nothing to say, have exhausted
signals. we have exhausted ourselves. we have exhausted me, none
of object or subject, waves which dissolve as if exhausted
tended get get of rid weak weak exhausted people by exhausted
there is, nothing more; it exhausts itself and is exhausted and
needed medical attention soon. They also felt exhausted and sm
exits in name only, and tired bartenders pour wine and dreaming
beside the gendered or exhausted body (the second the obdurate
and obstructive real, absorb the exhausted language so tired
from working and worrying this particular video of the I'm still
exhausted a lot of the time. I don't seem to be able I'm so
tired of these shapes which seem inconceivable catastrophe
theory exhausted within and without an inconceivable give devils
their side: less, exhausted, myriad beings while anything,
plague increased less, exhausted, myriad beings while ers are
there numbers here I'm so tired of this please tell me tired of
defending myself. stdin. i'm tired of armageddon andre a joke
ers are there numbers here I'm so tired of this please
limitless, collapsing, extinguishing./* exhausted discoruse you
looking for numbers are there numbers here I'm so tired of
significant effects, the name Agnes was retired in the spring of
complaynt as it might be written, people are tired of reading
 the left and the other other people. I'm tired of being

I am tired as a car, but I'm not falling asleep. I'm following
being out w/ long covid, so tired of saying there's not much to
go on I'm so tired of these shapes which It's completely
understandable to feel tired, and typing with ers tired Hoq sis
qhf fwr rlal qhwn yuou ewnor nar ro muxh did this and I'm wrong
in it where is I'm so tired I can't think less, exhausted,
myriad beings while is warfare, by P or global decathected,
defuge, exhausted: the Border - the ontological otherthe
people.other tiredI'm inserted finalthe realmfinal when we're
talking I'm lucky that they're so damn tired when I'm number I'm
getting a lot of these I'm so tired damn it I'm glitch, cata
theory exhausted within and without an exhausted?Wed Mar 27
14:28:25 EDT 2024 must i continue, what can This machinery of
their life. they're so tired of it they can exhausted and
worried about the pace I'm keeping - but then you. not as busy a
out euror23e or by East most tired.No We had just arrived at
Leverett. I was exhausted which is no exhausted as well.
Afterwards when I listen to it, I think, so bumbles along until
I get tired of it/them. What noe... Also all you for tired when
speaking, broke into giggles, want to answers.Blimey.Are
kidding?Awesome.Yes they? gone tired sisHoq exhausted, i can't
get out of this any long no matter, no matter I'm really tired.
There's something like implicit knowledge or that tiredness,
that fat9igue, that vanishing? For being or [The abject, sleazy,
tawdry, exhausted, schizzed the fake (for any number of
countries. Yeah, retired to the machine. There's i'm sor tired
and it seems more useful to typoe w/ my eyes stand it. It's
always possible to fall apart, I'm tired of this bent as they
did when i was exhausted driving alone 26 hours exhausted but I
sure would like to get to know you and I don't An anonymous
survey of nearly 2,000 retired officers found that _like that._
my head falls to my knees, exhausted, what was that then when
you figure it out, tiredness explodes, edge-worlds get
  untoward.That's tired.No the East by East

exchange excited exclaim exclaims excretions exhausted exist I'm
still not exhausted, brain alert! can't thinking just is
actually happening here is I really got tired of playing just
tired oops it's also like I just when you're talking about in a
field. "thus eye am so tired of this, tried of this" You you're
doing is you're just trying to think about how tired you it's
not playful. The jobs are 

Re: [PATCH-for-9.1 v2 2/3] migration: Remove RDMA protocol handling

[Dr. David Alan Gilbert]

* Peter Xu (pet...@redhat.com) wrote:
> Hey, Dave!

Hey!

> On Wed, Jun 05, 2024 at 12:31:56AM +, Dr. David Alan Gilbert wrote:
> > * Michael Galaxy (mgal...@akamai.com) wrote:
> > > One thing to keep in mind here (despite me not having any hardware to 
> > > test)
> > > was that one of the original goals here
> > > in the RDMA implementation was not simply raw throughput nor raw latency,
> > > but a lack of CPU utilization in kernel
> > > space due to the offload. While it is entirely possible that newer 
> > > hardware
> > > w/ TCP might compete, the significant
> > > reductions in CPU usage in the TCP/IP stack were a big win at the time.
> > > 
> > > Just something to consider while you're doing the testing
> > 
> > I just noticed this thread; some random notes from a somewhat
> > fragmented memory of this:
> > 
> >   a) Long long ago, I also tried rsocket; 
> >   https://lists.gnu.org/archive/html/qemu-devel/2015-01/msg02040.html
> >  as I remember the library was quite flaky at the time.
> 
> Hmm interesting.  There also looks like a thread doing rpoll().

Yeh, I can't actually remember much more about what I did back then!

> Btw, not sure whether you noticed, but there's the series posted for the
> latest rsocket conversion here:
> 
> https://lore.kernel.org/r/1717503252-51884-1-git-send-email-arei.gong...@huawei.com

Oh I hadn't; I think all of the stack of qemu's file abstractions had
changed in the ~10 years since I wrote my version!

> I hope Lei and his team has tested >4G mem, otherwise definitely worth
> checking.  Lei also mentioned there're rsocket bugs they found in the cover
> letter, but not sure what's that about.

It would probably be a good idea to keep track of what bugs
are in flight with it, and try it on a few RDMA cards to see
what problems get triggered.
I think I reported a few at the time, but I gave up after
feeling it was getting very hacky.

> Yes, and zero-copy requires multifd for now. I think it's because we didn't
> want to complicate the header processings in the migration stream where it
> may not be page aligned.

Ah yes.

> > 
> >   e) Someone made a good suggestion (sorry can't remember who) - that the
> >  RDMA migration structure was the wrong way around - it should be the
> >  destination which initiates an RDMA read, rather than the source
> >  doing a write; then things might become a LOT simpler; you just need
> >  to send page ranges to the destination and it can pull it.
> >  That might work nicely for postcopy.
> 
> I'm not sure whether it'll still be a problem if rdma recv side is based on
> zero-copy.  It would be a matter of whether atomicity can be guaranteed so
> that we don't want the guest vcpus to see a partially copied page during
> on-flight DMAs.  UFFDIO_COPY (or friend) is currently the only solution for
> that.

Yes, but even ignoring that (and the UFFDIO_CONTINUE idea you mention), if
the destination can issue an RDMA read itself, it doesn't need to send messages
to the source to ask for a page fetch; it just goes and grabs it itself,
that's got to be good for latency.

Dave

> 
> Thanks,
> 
> -- 
> Peter Xu
> 
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Re: [PATCH-for-9.1 v2 2/3] migration: Remove RDMA protocol handling

[Dr. David Alan Gilbert]

* Peter Xu (pet...@redhat.com) wrote:
> Hey, Dave!

Hey!

> On Wed, Jun 05, 2024 at 12:31:56AM +, Dr. David Alan Gilbert wrote:
> > * Michael Galaxy (mgal...@akamai.com) wrote:
> > > One thing to keep in mind here (despite me not having any hardware to 
> > > test)
> > > was that one of the original goals here
> > > in the RDMA implementation was not simply raw throughput nor raw latency,
> > > but a lack of CPU utilization in kernel
> > > space due to the offload. While it is entirely possible that newer 
> > > hardware
> > > w/ TCP might compete, the significant
> > > reductions in CPU usage in the TCP/IP stack were a big win at the time.
> > > 
> > > Just something to consider while you're doing the testing
> > 
> > I just noticed this thread; some random notes from a somewhat
> > fragmented memory of this:
> > 
> >   a) Long long ago, I also tried rsocket; 
> >   https://lists.gnu.org/archive/html/qemu-devel/2015-01/msg02040.html
> >  as I remember the library was quite flaky at the time.
> 
> Hmm interesting.  There also looks like a thread doing rpoll().

Yeh, I can't actually remember much more about what I did back then!

> Btw, not sure whether you noticed, but there's the series posted for the
> latest rsocket conversion here:
> 
> https://lore.kernel.org/r/1717503252-51884-1-git-send-email-arei.gong...@huawei.com

Oh I hadn't; I think all of the stack of qemu's file abstractions had
changed in the ~10 years since I wrote my version!

> I hope Lei and his team has tested >4G mem, otherwise definitely worth
> checking.  Lei also mentioned there're rsocket bugs they found in the cover
> letter, but not sure what's that about.

It would probably be a good idea to keep track of what bugs
are in flight with it, and try it on a few RDMA cards to see
what problems get triggered.
I think I reported a few at the time, but I gave up after
feeling it was getting very hacky.

> Yes, and zero-copy requires multifd for now. I think it's because we didn't
> want to complicate the header processings in the migration stream where it
> may not be page aligned.

Ah yes.

> > 
> >   e) Someone made a good suggestion (sorry can't remember who) - that the
> >  RDMA migration structure was the wrong way around - it should be the
> >  destination which initiates an RDMA read, rather than the source
> >  doing a write; then things might become a LOT simpler; you just need
> >  to send page ranges to the destination and it can pull it.
> >  That might work nicely for postcopy.
> 
> I'm not sure whether it'll still be a problem if rdma recv side is based on
> zero-copy.  It would be a matter of whether atomicity can be guaranteed so
> that we don't want the guest vcpus to see a partially copied page during
> on-flight DMAs.  UFFDIO_COPY (or friend) is currently the only solution for
> that.

Yes, but even ignoring that (and the UFFDIO_CONTINUE idea you mention), if
the destination can issue an RDMA read itself, it doesn't need to send messages
to the source to ask for a page fetch; it just goes and grabs it itself,
that's got to be good for latency.

Dave

> 
> Thanks,
> 
> -- 
> Peter Xu
> 
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Re: [marxmail] TOWARD NAKBA AS A LEGAL CONCEPT

[Alan Ginsberg]

NY Times
By Sharon Otterman
June 4, 2024
"Columbia Law Review Website Is Taken Offline Over Article Criticizing Israel"
https://www.nytimes.com/2024/06/04/nyregion/columbia-law-review-website.html

The website of the Columbia Law Review, one of the United States’ most 
prestigious student-edited law journals, was taken offline Monday by its board 
of directors after its editors published an article ( 
https://static.al2.in/toward-nakba-as-a-legal-concept.pdf ) that argues 
Palestinians are living under a “brutally sophisticated structure of 
oppression” by Israel that amounts to a crime against humanity.

As of Tuesday evening, visitors to the website ( https://columbialawreview.org/ 
) of the 123-year-old journal saw only a blank page with the message “Website 
is under maintenance.”

The decision to suspend access to the website is the latest example of how 
American universities have sought to regulate expression that is highly 
critical of Israel amid concerns that it veers into antisemitism. That, in 
turn, has spurred complaints about censorship and academic freedom when it 
comes to Palestinian scholarship.

In a statement, the board of directors ( 
https://projects.propublica.org/nonprofits/organizations/136161436 ) , which 
consists of faculty members and alumni, said it had decided to suspend the 
website on Monday after learning two days earlier that not all of the students 
on the Law Review had read the essay before publication.

The board said that it had asked the editors to hold the article until June 7, 
to give others time to read it but that they had published it on Monday 
instead. The board then decided to take the website down temporarily “to 
provide time for the Law Review to determine how to proceed.”

In a letter Tuesday to the editorial staff that was provided to The New York 
Times, the board charged that the article had been handled with unusual 
secrecy, calling that “unacceptable.”

The involvement of the 12-member board, which includes Gillian Lester, the law 
school dean; Gillian Metzger, a constitutional law scholar at Columbia; and 
Ginger Anders, an alumna and former assistant to the U.S. solicitor general, 
was also unusual. The board is not typically involved in the editorial 
decisions of the student-led organization.

“To my knowledge, this is the first time ever that the board of directors of 
the Law Review has intervened in any way in the publication of an article,” 
said Katherine Franke, a Columbia law professor who supported the piece’s 
publication.

“It’s a little hard for me to believe that if the article had been about 
anything else, the board would have cared about the process,” she added.

The 105-page article, written by Rabea Eghbariah ( 
https://hls.harvard.edu/graduate-program/sjd-program/current-s-j-d-candidates-and-recent-graduates/rabea-eghbariah/
 ) , a Palestinian human rights lawyer and a doctoral candidate at Harvard, 
calls Zionism a form of colonialism and racism and argues that a new legal 
concept is needed to fully encapsulate the extent of its harms. That concept, 
Mr. Eghbariah argues, is nakba, the Arabic word for catastrophe, which is also 
the word used by Palestinians for their forced displacement from Israel in 1948.

Mr. Eghbariah called the website’s shutdown an attempt to silence his 
scholarship.

“What is so scary about Palestinians speaking their truth?” he said.

The editors on the Review did use a “somewhat irregular process” in editing the 
piece, “Toward Nakba as a Legal Concept,” because they were concerned about 
censorship, Professor Franke said. Students involved in the editing said that 
among the roughly 100 people involved with the journal, they had created a 
smaller committee to solicit and select the piece, a procedure the Review does 
not always use.

That committee defended the process. In a statement, it said that the article 
“went through at least six rounds of intensive editing and fact-checking over 
several months to prepare for publication. Thirty editors collectively ** spent 
hundreds of hours working on the article — numbers consistent with other 
articles the Review publishes.”

Since the Oct. 7 Hamas attack on Israel, dozens of university faculty members 
across the country have been investigated, suspended or fired ( 
https://www.insidehighered.com/news/faculty-issues/academic-freedom/2024/06/03/depaul-adjunct-ousted-optional-gaza-assignment
 ) for making statements that critics charge are antisemitic or supportive of 
the attack. Student protests have also been widely condemned as antisemitic, 
even when the protesters say that their anti-Zionist views do not mean they are 
against Jews.

In November, a shorter version of Mr. Eghbariah’s article was fully edited at 
the Harvard Law Review but was pulled from publication at the last minute after 
an emergency vote by the entire editorial staff, The Intercept ( 
https://theintercept.com/2023/11/21/harvard-law-review-gaza-israel/ ) reported. 
The 

[webkit-changes] [WebKit/WebKit] e50a24: [IFC] LineLayout::containing may return incorrect ...

[Alan Baradlay]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e50a242c2c4be6fdd0ed66f8fd9685eaf1d307b5
  
https://github.com/WebKit/WebKit/commit/e50a242c2c4be6fdd0ed66f8fd9685eaf1d307b5
  Author: Alan Baradlay 
  Date:   2024-06-05 (Wed, 05 Jun 2024)

  Changed paths:
A LayoutTests/fast/inline/floating-dialog-becomes-modal-crash-expected.txt
A LayoutTests/fast/inline/floating-dialog-becomes-modal-crash.html
M Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp

  Log Message:
  ---
  [IFC] LineLayout::containing may return incorrect block container for 
https://bugs.webkit.org/show_bug.cgi?id=275162


Reviewed by Antti Koivisto.

1. properties that we use to decide whether a renderer is 
"isInTopLayerOrBackdrop" are set on associated element before applying the most 
recent style (RenderElement::setStyle).
2. RenderObject::containingBlock() consults isInTopLayerOrBackdrop to see 
whether it should just simply return the ICB.

When containingBlock() is called from _styleWillChange_, while the expected 
behavior is to get a containing block based on current (old) style, in case of 
"isInTopLayerOrBackdrop"
boxes, containingBlock() returns a box already taking these new "properties" 
into account.

* LayoutTests/fast/inline/floating-dialog-becomes-modal-crash-expected.txt: 
Added.
* LayoutTests/fast/inline/floating-dialog-becomes-modal-crash.html: Added.
* Source/WebCore/layout/integration/inline/LayoutIntegrationLineLayout.cpp:
(WebCore::LayoutIntegration::LineLayout::containing):

Canonical link: https://commits.webkit.org/279747@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Re: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v7]

[Alan Bateman]

On Wed, 5 Jun 2024 15:58:28 GMT, Thomas Stuefe  wrote:

>> Thanks !
>> 
>> Your PR looks very promising @tstuefe, I would indeed prefer to wait for 
>> your changes as a way to add additional indentation to the stack of the 
>> virtual thread.
>> 
>> What do you think if I leave the current PR with the indentation that is 
>> already used for the stack of the carrier thread and I create a separate PR 
>> based on yours to add the additional indentation ?
>
> Okay for me, if other reviewers are okay with it.

I think it would be better if the stack trace of the mounted virtual thread 
didn't align/indent the same as the carrier as it kinda looks like it's one 
larger stack trace. That said, no objection if there is a follow-on PR to do 
that, in which case might be better to wait until after the fork for JDK 23 so 
that the two PRs go into the same release.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1628172341

git: 60847070f908 - main - vm: Eliminate a redundant call to vm_reserv_break_all()

[Alan Cox]

The branch main has been updated by alc:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=60847070f908c7c5ebb2ea4c851f8b98680fd01a

commit 60847070f908c7c5ebb2ea4c851f8b98680fd01a
Author: Alan Cox 
AuthorDate: 2024-06-05 06:40:20 +
Commit: Alan Cox 
CommitDate: 2024-06-05 17:39:47 +

vm: Eliminate a redundant call to vm_reserv_break_all()

When vm_object_collapse() was changed in commit 98087a0 to call
vm_object_terminate(), rather than destroying the object directly, its
call to vm_reserv_break_all() should have been removed, as
vm_object_terminate() calls vm_reserv_break_all().

Reviewed by:kib, markj
MFC after:  1 week
Differential Revision:  https://reviews.freebsd.org/D45495
---
 sys/vm/vm_object.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c
index 905df5454355..0af4402938ba 100644
--- a/sys/vm/vm_object.c
+++ b/sys/vm/vm_object.c
@@ -1953,14 +1953,6 @@ vm_object_collapse(vm_object_t object)
 */
vm_object_collapse_scan(object);
 
-#if VM_NRESERVLEVEL > 0
-   /*
-* Break any reservations from backing_object.
-*/
-   if (__predict_false(!LIST_EMPTY(_object->rvq)))
-   vm_reserv_break_all(backing_object);
-#endif
-
/*
 * Move the pager from backing_object to object.
 *

git: 60847070f908 - main - vm: Eliminate a redundant call to vm_reserv_break_all()

[Alan Cox]

The branch main has been updated by alc:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=60847070f908c7c5ebb2ea4c851f8b98680fd01a

commit 60847070f908c7c5ebb2ea4c851f8b98680fd01a
Author: Alan Cox 
AuthorDate: 2024-06-05 06:40:20 +
Commit: Alan Cox 
CommitDate: 2024-06-05 17:39:47 +

vm: Eliminate a redundant call to vm_reserv_break_all()

When vm_object_collapse() was changed in commit 98087a0 to call
vm_object_terminate(), rather than destroying the object directly, its
call to vm_reserv_break_all() should have been removed, as
vm_object_terminate() calls vm_reserv_break_all().

Reviewed by:kib, markj
MFC after:  1 week
Differential Revision:  https://reviews.freebsd.org/D45495
---
 sys/vm/vm_object.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c
index 905df5454355..0af4402938ba 100644
--- a/sys/vm/vm_object.c
+++ b/sys/vm/vm_object.c
@@ -1953,14 +1953,6 @@ vm_object_collapse(vm_object_t object)
 */
vm_object_collapse_scan(object);
 
-#if VM_NRESERVLEVEL > 0
-   /*
-* Break any reservations from backing_object.
-*/
-   if (__predict_false(!LIST_EMPTY(_object->rvq)))
-   vm_reserv_break_all(backing_object);
-#endif
-
/*
 * Move the pager from backing_object to object.
 *