Re: E-comm live project

[Dean Mahori]

Add me
+263786881635

Sent from Outlook for Android

From: django-users@googlegroups.com  on behalf 
of amruth bitla 
Sent: Monday, May 6, 2024 6:23:52 PM
To: Django users 
Subject: Re: E-comm live project

Hi  1001_prabhjot Singh,

I am interested, check out my GitHuB Page for Django 
Project, Please Email me.

On Monday, May 6, 2024 at 12:13:13 PM UTC-4 avdesh sharma wrote:
I am interested, +91-9650031844

On Mon, Mar 18, 2024 at 10:56 PM 1001_prabhjot Singh  
wrote:
so i am working on a full stack e-comm website and this project is really very 
big for me because it's a live project am using django for backend interested 
one's can send there number for WhatsApp group

--
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1101d563-726a-458e-ad9f-4b91bebf3132n%40googlegroups.com.


--
Warm Regards,
Avdesh Kumar Sharma
9650031844

--
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a84f1fdf-36de-4a79-b628-b2a50c576f3an%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/PAXP193MB2202C8F3EC53FC22B974B0D0FF1C2%40PAXP193MB2202.EURP193.PROD.OUTLOOK.COM.

[no subject]

[Dean Mahori]

Dear Programmers,
My name is Dean Mahori and I'm a student at Chinhoyi University . I'm
working on a university project to build a website using the Django
framework.
I'm currently in the process of developing a website to better connect with
our community and raise awareness about our cause.  While I'm excited to
embark on this project, I'm also new to website development and could
really use some assistance.
I'm particularly interested in using Django, a Python web framework, to
build the website.  I've been doing some research on it and believe it
would be a good fit for our needs.  However, as a beginner, I would greatly
appreciate any guidance or support from experienced Django programmers. I'm
also open to different approaches and suggestions from experienced
programmers.

Here are some specific areas where I could use help:

Project Setup and Best Practices: Ensuring a solid foundation for the
website's development.
Understanding Django Features: Learning how to effectively utilize
Django functionalities for our website.
Building Core functionalities: Developing essential features like user
registration, content management, and potentially donation options.

I understand that volunteering your time is valuable, and I'm incredibly
grateful for any assistance you can offer.  Even if it's just pointing me
in the right direction with resources or tutorials, it would be immensely
helpful.
I'm happy to discuss the project further and answer any questions you may
have.  Please feel free to contact me at deanmah...@gmail.com or
+263786881635
You can also comment with your whatsapp number so that i can create a group
for all of us.

Thank you for your time and consideration.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAOxCe%3DSQMWYKQzf4ODUVqEXqmZB%2BN1R%3DWvbZLNzxAzPa6F7k7A%40mail.gmail.com.

Re: E-comm live project

[Dean Mahori]

add me +263786881635


On Tue, Apr 30, 2024 at 3:23 PM Kintu Peter  wrote:

> Watsap +256789746493
>
>
> On Monday, March 18, 2024 at 8:26:50 PM UTC+3 1001_prabhjot Singh wrote:
>
>> so i am working on a full stack e-comm website and this project is really
>> very big for me because it's a live project am using django for backend
>> interested one's can send there number for WhatsApp group
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/133bfa88-4044-4bdc-9602-9c3a5ec276b7n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAOxCe%3DS22%3DXqpQOP9gPAqTR4%2B1xHhMNoCacMMOsMPNa7Kvuhbw%40mail.gmail.com.

[Cscwg-public] CSCWG April 18, 2024 Final meeting minutes

[Dean Coclin via Cscwg-public]

 

2024-04-18 Final Minutes

 

Attendees:

Andrea Holland (VikingCloud), Ben Dewberry (Keyfactor), Brian Winters
(IdenTrust), Bruce Morton (Entrust), Christophe Bonjean (GlobalSign), Corey
Bonnell (DigiCert), Dean Coclin (DigiCert), Dimitris Zacharopoulos (HARICA),
Eva Vansteenberge (GlobalSign), Inaba Atsushi (GlobalSign), Inigo Barreira
(Sectigo), Janet Hines (VikingCloud), Marco Schambach (IdenTrust), Martijn
Katerbarg (Sectigo), Nome Huang (TrustAsia), Scott Rea (eMudhra), Thomas
Zermeno (SSL.com), Tim Crawford (CPA Canada/WebTrust), Wangmo Tenzing
(Wangmo Tenzing)

 

Minute-taker: Corey Bonnell

 

Bruce read the note well.

 

Bruce said he will call for approval of the F2F minutes at the next meeting.

 

Meeting minutes for the March 21st meeting were approved.

Meeting minutes for the April 4th meeting were approved.

 

* Obsolete EVCS guidelines

 

Dimitris said the ballot needs to be converted to PDF and circulated on the
mailing list.

Bruce said he will take care of that and Corey will publish on the website.

 

* Remove EVG references

 

Dimitris asked for a review of this draft ballot. He said that a mapping
document is

available to assist in the review. Martijn and Corey offered to review the
PR

(https://url.avanan.click/v2/___https://github.com/cabforum/code-signing/pul
l/38___.YXAzOmRpZ2ljZXJ0OmE6bzo2Yjk1MjA2NDAyYWY4YmM5MzU3OGI3ODRkNWY2ZGQ3NDo2
OmNiMGU6ZDEzMDg3NzRjMzc5ZDE4YjE5MTZjNDY2ODNhODgxNjIxYTY0OTY4MGMxNDc0MzJmOGRh
ZTMxNWYwOWM0NjkzOTp0OkY
<https://url.avanan.click/v2/___https:/github.com/cabforum/code-signing/pull
/38___.YXAzOmRpZ2ljZXJ0OmE6bzo2Yjk1MjA2NDAyYWY4YmM5MzU3OGI3ODRkNWY2ZGQ3NDo2O
mNiMGU6ZDEzMDg3NzRjMzc5ZDE4YjE5MTZjNDY2ODNhODgxNjIxYTY0OTY4MGMxNDc0MzJmOGRhZ
TMxNWYwOWM0NjkzOTp0OkY> ).

 

* Change to timestamp requirements

 

Martijn said Christophe provided several comments on the PR. Christophe
raised a

concern that re-issuance of a timestamping ICA would incur the requirement
to move

the CA private key to offline HSM. Bruce also raised a concern that
long-lived

timestamping CAs could be stored in online HSMs despite this ballot. Martijn

said that we could create an effective date to require CAs to move to
offline HSMs,

but that may be complex.

 

Dimitris said that moving a key does not eliminate the risk, as it was
previously

stored in an online HSM. Additionally, keys could have been generated before
the

effective date in an online state prior to being certified in a certificate.

Martijn said that if a key has been generated online, then it couldn't be
said that

it was "maintained" in an offline state. Martijn said he can clarify this in
the ballot.

 

Martijn said to resolve the concern about legacy online CAs being used in
perpetuity,

that we could propose a sunset date for issuing end-entity timestamping
responder

certificates to force a rotation to offline CA keys. Corey agreed with that
approach.

 

* Other business

 

Martijn said a ballot for modifying logging requirements in the TLS BRs.
He'd like

to align the CS BRs with this language. He will write a ballot to do this
and will

call for endorsers.

 

Martijn also mentioned that we could remove the EVCS JOI fields and replace
with

the orgId, as is done in the SMBRs, but said it might be too early for that
change.

Bruce said we should reconsider all subject fields in light of the
deprecation of

EV CS. Dimitris agreed and said that we need to incorporate Microsoft's
plans

on the validation level of code signing certificates.

 

Next meeting is May 2nd. Meeting adjourned.



smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public

[Cscwg-public] Final minutes of F2F CSCWG Feb 28, 2024

[Dean Coclin via Cscwg-public]

 

Code Signing Certificate Working Group Draft Minutes Feb 28, 2024 F2F
Meeting India

 

Discussion leader: Bruce Morton (Entrust)

Minutes: Andrea Holland (VikingCloud)

 

Attendees: Paul van Brouwershaven (Entrust), Dustin Hollenback (Microsoft),
Tim Callan (Sectigo), Scott Rea (eMudhra), Dimitris Zacharopoulos (HARICA),
Arno Fiedler (ETSI), Arvid Vermote (GlobalSign), Ashish Dhiman (GlobalSign),
Tadahiko Ito (SECOM), Corey Bonnell (DigiCert), Inigo Barreira (Sectigo),
Mrugesh Chandarana (IdenTrust), Marco Schambach (IdenTrust), Nitesh Bakliwal
(Microsoft), Kiran AM (eMudhra), Keshava N (eMudhra), Abhishek Bhat
(eMudhra), Naveen Kumar (eMudhra), Yashwanth (eMudhra), Dean Coclin
(DigiCert), Thomas Zermeno (SSL.com), Mohit Kumar (GlobalSign), Martijn
Katerbarg (Sectigo), Nargis Mannan (Viking Cloud), Marco Schambach
(IdenTrust), Tim Hollebeek (DigiCert), Atsushi Inaba (GlobalSign), Trevoli
Ponds-White (Amazon Trust Services), Aaron Poulsen (Amazon Trust Services),
Rich Smith (DigiCert), Roman Fischer (SwissSign), Eva Van Steenberge
(GlobalSign), Rollin Yu (TrustAsia), Michael Slaughter (Amazon Trust
Services), Nome Huang (TrustAsia), Kateryna Aleksieieva (Certum), Andrea
Holland (VikingCloud), Bruce Morton (Entrust), Tim Crawford (CPA
Canada/WebTrust), Ian McMillan (Microsoft), Stefan Kirch (Telekom Security),
Tsung-Min Kuo (Chunghwa Telecom), Rebecca Kelley (Apple), Li-Chun Chen
(Chunghwa Telecom)Interested Party: Ben Wilson (Mozilla), Invited Guests:
Ramachandran P (Office of CCA, MEITY, Govt of India), Mike Kushner
(Keyfactor), Seven Rajala (Keyfactor), 

 

Detailed minutes:

 

1.  Antitrust Compliance Statement read

2.  Review Agenda

3.  Statement from Nitish. 

*   Survey went out from Microsoft. If you have not received it please
reach out. 

*   Update to EV CS OID changes.

*   Deadline of August 2024 for feedback and reasons/scenarios for
supporting.

*   Timeline of February 2025 of planned removal of support of EV Code
Signing.

*   Policy update of removal of EV CS OID was published early and will
be reverted until the planned removal date.

*   Clarification that OCSP is required only for TLS not for Code
Signing or S/MIME.

4.  Approval of February 8th minutes
5.  Certificate Transparency for Code Signing

*   Discussion by Ian, Trev, Tim H., Bruce, Dimitris, Martijn, Paul, and
Dean.

*   Discussion about the problem statement for the need of public
transparency for Code Signing certificates and the revocation aspect.

*   Discussion on the infrastructure of the tools necessary to monitor
the CT logs as well as subscriber benefits, but these should be a secondary
phase.

*   Discussion around use case of CT for CS and the differences between
CT for TLS vs for CS. 

*   Code Signing certificates are signing code that can last forever
which impacts the length of time needed for the CT log.

*   Single use CS certificates would cause a high number of records on
the CT logs.

*   Specific questions were discussed: How long should a record be in a
Trusted CT Log? What happens when a log gets retired? How long should a log
be active? How many logs would CAs be required to log to? These will be
continued based on implementation.

*   Action item: To define/refine the problem statement. 

6.  Reduction of Code Signing validity to 15 months

*   Discussion by Ian, Bruce, Dean, Martijn, Tim C., Dimitris, and Trev

*   Reason for request is the longer a validity period causes a
revocation to have a larger impact radius which causes unintended collateral
damage.

*   Original time of 39 months was based on the common actions at the
time, should this be revisited. How many certificates are being issued at 39
months? Are 12 month certs more common, or has this changed due to the
protection of the private key requirement? 

*   Discussion that the worry is the amount of software that is signed
under a particular key. In the event that a key gets compromised, you have
to revoke a whole bunch of software.

*   Action item: Get the data, review, and move forward from there.

7.  Ballot for EVG import

*   Discussion by Bruce, Tim H., Ian, Tim C., Dimitris, Mrugesh, Trev,
Enrico, and Paul

*   The idea is that non-EV code signing is going away and EV will be
the new standard. 

*   Microsoft confirms that hardware dev center is the only remaining
location which policy says EV cert is needed for onboarding only. Smart
screen doesn't distinguish between the two. 

*   Microsoft doesn't differentiate between OV and EV OIDs they are
treated the same.

*   Microsoft wants to simplify to one type of CS certificate with the
only difference in validation type (individual validation vs organization
validation). 

*   CS BRs points to specific references in EV Guidelines. The EVG
import should be completed first. Then next step is to simply CS BRs to
match with one CS type. The goal

[Cscwg-public] CSCWG Agenda May 2, 2024

[Dean Coclin via Cscwg-public]

 

MINUTE TAKER: NEED A VOLUNTEER, START RECORDING

 

1.  Roll Call
2.  Antitrust reminder
3.  Approve prior meeting minutes - F2F  (Andrea), April 18th (Corey)
4.  Proposed ballots: Remove EV Guideline References
5.  Proposed ballot for Time-stamp Requirements update; CSC-24
6.  Discuss F2F Agenda
7.  Other business
8.  Next meeting - May 16th   
9.  Adjourn

 

 

Dean Coclin 

CSCWG Chair

 

 

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public

Re: RFR: 8331087: Move immutable nmethod data from CodeCache [v2]

[Dean Long]

On Sun, 28 Apr 2024 23:37:22 GMT, Vladimir Kozlov  wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes 
>> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, 
>> speculations`. It amounts for about 30% (optimized VM) of space in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable 
>> nmethod's data. Call `vm_exit_out_of_memory()` if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid 
>> nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Address comments. Moved jvmci_data back to mutable data section.

Marked as reviewed by dlong (Reviewer).

-

PR Review: https://git.openjdk.org/jdk/pull/18984#pullrequestreview-2027786061

Re: RFR: 8331087: Move immutable nmethod data from CodeCache

[Dean Long]

On Sun, 28 Apr 2024 07:02:40 GMT, Dean Long  wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes 
>> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, 
>> speculations`. It amounts for about 30% (optimized VM) of space in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable 
>> nmethod's data. Call `vm_exit_out_of_memory()` if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid 
>> nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> It only makes sense if the immutable data heap is not also used for other 
> critical resources.  If malloc or metaspace were used as the immutable data 
> heap, normally failures in those heaps are fatal, because other critical 
> resources (monitors, classes, etc) are allocated from there, so any failure 
> means the JVM is about to die.  There's no reason to find a fall-back method 
> to allocate a new nmethod in that case.

> Just to be clear @dean-long , you're saying failure to allocate immutable 
> data in the C heap should result in a fatal error? Makes sense to me as the 
> VM must indeed be very close to crashing anyway in that case. It also, 
> obviates the need for propagating `out_of_memory_error` to JVMCI code.

I hadn't thought it through that far, actually.  I was only pointing out that 
the proposed fall-back:

> increase nmethod size and put immutable data there (as before).

isn't worth the trouble.  But making the C heap failure fatal immediately is 
reasonable, especially if it simplifies JVMCI error reporting.

-

PR Comment: https://git.openjdk.org/jdk/pull/18984#issuecomment-2082083104

Re: RFR: 8331087: Move immutable nmethod data from CodeCache

[Dean Long]

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov  wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes 
> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, 
> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space 
> in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable 
> nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid 
> nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

It only makes sense if the immutable data heap is not also used for other 
critical resources.  If malloc or metaspace were used as the immutable data 
heap, normally failures in those heaps are fatal, because other critical 
resources (monitors, classes, etc) are allocated from there, so any failure 
means the JVM is about to die.  There's no reason to find a fall-back method to 
allocate a new nmethod in that case.

-

PR Comment: https://git.openjdk.org/jdk/pull/18984#issuecomment-2081364009

Re: RFR: 8331087: Move immutable nmethod data from CodeCache

[Dean Long]

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov  wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes 
> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, 
> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space 
> in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable 
> nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid 
> nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java line 528:

> 526:   private int getScopesDataOffset()   { return (int) 
> scopesDataOffsetField  .getValue(addr); }
> 527:   private int getScopesPCsOffset(){ return (int) 
> scopesPCsOffsetField   .getValue(addr); }
> 528:   private int getDependenciesOffset() { return (int) 0; }

Suggestion:


No longer used.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581671710

Re: RFR: 8331087: Move immutable nmethod data from CodeCache

[Dean Long]

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov  wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes 
> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, 
> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space 
> in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable 
> nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid 
> nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

src/hotspot/share/code/nmethod.cpp line 1484:

> 1482:   // Calculate positive offset as distance between the start of 
> stubs section
> 1483:   // (which is also the end of instructions section) and the start 
> of the handler.
> 1484:   CHECKED_CAST(_unwind_handler_offset, int16_t, (_stub_offset - 
> code_offset() - offsets->value(CodeOffsets::UnwindHandler)));

Suggestion:

  int unwind_handler_offset = code_offset() + 
offsets->value(CodeOffsets::UnwindHandler);
  CHECKED_CAST(_unwind_handler_offset, int16_t, _stub_offset - 
unwind_handler_offset);

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581644356

Re: RFR: 8331087: Move immutable nmethod data from CodeCache

[Dean Long]

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov  wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes 
> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, 
> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space 
> in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable 
> nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid 
> nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

src/hotspot/share/code/nmethod.cpp line 1332:

> 1330: #if INCLUDE_JVMCI
> 1331: _speculations_offset = _scopes_data_offset;
> 1332: _jvmci_data_offset   = _speculations_offset;

Why not use 0 for all these?

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581642931

Re: RFR: 8331087: Move immutable nmethod data from CodeCache

[Dean Long]

On Fri, 26 Apr 2024 21:36:50 GMT, Vladimir Kozlov  wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes 
>> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, 
>> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space 
>> in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable 
>> nmethod's data. Bail out compilation if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid 
>> nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> src/hotspot/share/code/nmethod.cpp line 117:
> 
>> 115:   result = static_cast(thing); \
>> 116:   assert(static_cast(result) == thing, "failed: %d != %d", 
>> static_cast(result), thing);
>> 117: 
> 
> I replaced `checked_cast<>()` with this macro because of next issues:
>  - The existing assert points to `utilities/checkedCast.hpp` file where this 
> method is located and not where failed cast. It does not help when it is used 
> several times in one method (for example, in `nmethod()` constructors).
>  - The existing assert does not print values

I thought @kimbarrett had a draft PR to address the error reporting issue, but 
I can't seem to find it.  To solve the general problem, I think we need a 
version of vmassert() that takes `char* file, int lineno` as arguments, and a 
macro wrapper for checked_cast() that passes `__FILE__` and `__LINEN__` from 
the caller.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581628786

[ccp4bb] Postdoctoral Research Associate – Biochemistry/Biophysics

[Myles, Dean A A]

The Diffraction Group in the Neutron Scattering Division (NSD) at Oak Ridge 
National Laboratory (ORNL) has an immediate opening for a postdoctoral 
Biochemist or Biophysicist to join a multi-disciplinary research team in 
development and application of paramagnetic labeling and proton polarization 
techniques for structure analysis. This project involves multi-task efforts in 
molecular biology, NMR, dynamic nuclear polarization (DNP) and macromolecular 
crystallography, and collaboration with computational scientists developing ML 
and AI tools for molecular simulation and analysis. As an ORNL postdoctoral 
fellow you will have access to state-of-the-art facilities for isotopic 
labeling, biophysical characterization and X-ray diffraction, as well as access 
to world class facilities for neutron diffraction and scattering, and molecular 
simulations. The position represents an excellent opportunity for you to 
develop your career and interact with leading scientists from around the world.

A link to the position advertisement can be found here:

https://jobs.ornl.gov/job/Oak-Ridge-Postdoctoral-Research-Associate-Structural-Biology%2C-Biochemistry-and-Biophysics-TN-37830/1155718000/




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

[tarlz] testsuite failure on Alpine (edge)

[J Dean]

0.25 against lzlib 1.14 and/or 1.15-pre1. dynamic and static builds all fail at 
the same point: 

g++ -march=native -O2 -fstack-protector-strong -fstack-clash-protection 
-ftrivial-auto-var-init=zero -fcf-protection=full -mshstk -Wformat 
-Werror=format-security -fomit-frame-pointer -flto=auto -ffat-lto-objects -pipe 
-D_GLIBCXX_ASSERTIONS=1 -D_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS=1 
-D_LIBCPP_ENABLE_HARDENED_MODE=1 -static-pie 
-Wl,-z,relro,-z,now,-z,pack-relative-relocs -o tarlz arg_parser.o lzip_index.o 
archive_reader.o common.o common_decode.o common_mutex.o compress.o create.o 
create_lz.o decode.o decode_lz.o delete.o delete_lz.o exclude.o extended.o 
main.o -llz -lpthread
testing tarlz-0.25...
testing --list and --extract...
testing --concatenate...
testing --create...touch: invalid date '2022-01-05T12:22:13'
failure in testing framework
make: *** [Makefile:95: check] Error 1
>>> ERROR: tarlz: check failed

could this be a busybox touch quirk? only by patching the --create --mtime test 
section out does the build complete with all other tests passing. 

--- /dev/null
+++ b/testsuite/check.sh
@@ -731,35 +731,6 @@
 [ ! -e baz ] || test_failed $LINENO
 rm -f out.tar foo bar baz || framework_failure
 
-# test --create --mtime
-dates='@-9223372036854775808 @-9223372036854775807
-   -2147481748-12-31T23:59:59 -1970-01-01T00:00:00
-   -01-01T00:00:00 -01-01T00:00:01 -01-02T00:00:00
-   1697-10-17T11:03:27 1697-10-17T11:03:28 1697-10-17T11:03:29
-   1833-11-24T17:31:43 1833-11-24T17:31:44 1833-11-24T17:31:45
-   1901-12-13T20:45:51 1901-12-13T20:45:52 1901-12-13T20:45:53
-   1901-12-14T20:45:51
-   1969-12-31T23:59:58 1969-12-31T23:59:59
-   1970-01-01T00:00:00 1970-01-01T00:00:01 @0
-   2038-01-18T03:14:07 2038-01-19T03:14:07 2038-01-19T03:14:08
-   2106-02-07T06:28:15 2106-02-07T06:28:16
-   2242-03-16T12:56:31 2242-03-16T12:56:32 @8589934591 @8589934592
-   -12-31T23:59:58 -12-31T23:59:59
-   2147483647-12-31T23:59:59 @9223372036854775807'
-touch -d 2022-01-05T12:22:13 bar || framework_failure
-for i in ${dates} @-8Ei '2017-10-01 09:00:00' '2017-10-1 9:0:0' \
- '2017-10-01 09:00' '2017-10-01 09' 2017-10-01 ./bar ; do
-  touch foo || framework_failure
-  "${TARLZ}" -cf out.tar --mtime="$i" foo || test_failed $LINENO "$i"
-  is_uncompressed out.tar || test_failed $LINENO "$i"
-  "${TARLZ}" -q -df out.tar && test_failed $LINENO "$i"
-  "${TARLZ}" -xf out.tar || test_failed $LINENO "$i"
-  if [ "${d_works}" = yes ] ; then
-"${TARLZ}" -df out.tar --ignore-overflow || test_failed $LINENO "$i"
-  fi
-done
-rm -f out.tar foo bar || framework_failure
-
 mkdir dir || framework_failure
 for i in ${dates} ; do
   # Skip a time stamp $i if it's out of range for this platform,

would like to package this for Alpine (lzip/lzlib/plzip are already in the 
official repos). is there a workaround, perhaps an alternative test? or can the 
test be patched out as above and the resultant binary be used in production, 
despite the check failure? 

Re: RPi 4b Wifi Device

[Thomas D. Dean]

On 4/23/24 08:54, Justin Parrott wrote:

this is what i was talking about, i don't like booting an sbc from stick

even if you can hit disk

can net run on sbc?



I can boot NetBSD 10 on an RPi 4b from an SD card . It seems to run 
fine. Seems lots faster than RPi OS booted from the same type SD card.


I can
  1. access the network
  2. ssh into the RPi
  3. build applications
on a RPi 4B running NetBSD 10 booted from an SD card.

What I can not do is get the RPi 4b to boot NetBSD from a USB-3 flash drive.

I can get the RPi 4b to boot RPi OS from the USB-3 flask drive.

Tom Dean

Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP

[Saxe, Dean]

Thanks Pieter!
-dhs

--
Dean H. Saxe, CIDPRO<https://idpro.org/cidpro/> (he/him)
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS)
E: deans...@amazon.com<mailto:deans...@amazon.com> | M: 
206-659-7293

From: Pieter Kasselman 
Date: Tuesday, April 23, 2024 at 7:02 AM
To: "Saxe, Dean" , "rifaat.s.ietf" 
, oauth 
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Hi Dean, thanks for taking the time to review and provide feedback Dean, much 
appreciated.

I have opened issues to address each of the items highlighted.


  1.  Add verbiage to diagrams: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/124
  2.  Make examples consistent for Section 3.1.3: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/125
  3.  Clarify origin of QR Code: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/126
  4.  Editorial updates: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/127
  5.  FIDO Reference update: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/128
  6.  Update Guidance on using FIDO: 
https://github.com/oauth-wg/oauth-cross-device-security/issues/129

Cheers

Pieter


From: OAuth  On Behalf Of Saxe, Dean
Sent: Monday, April 22, 2024 6:54 PM
To: rifaat.s.ietf ; oauth 
Subject: Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP


You don't often get email from 
deansaxe=40amazon@dmarc.ietf.org<mailto:deansaxe=40amazon@dmarc.ietf.org>.
 Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

Rifaat,

I have a few minor nits in the doc, nothing of significant concern for WGLC.


  1.  When describing the visuals documenting the flows, there is a step that 
includes “The user authenticates to the authorization server”.  In each case 
this should include verbiage to indicate that this is only necessary if the 
user is unauthenticated, e.g. “If unauthenticated, the user authenticates to 
the authorization server…”.  Specific sections include 3.1.1, 3.1.2, 4.1.1, 
4.1.2
  2.  Section 3.1.3 the final sentence notes the authorization data may be 
delivered as a text message or via a mobile app.  This is inconsistent with the 
methods mentioned in the first paragraph, which includes email and text 
messages.  I suggest being clear that these are example mechanisms and not a 
full list of mechanisms by which codes can be delivered.
  3.  Section 3.3.1 the first sentence should note that the QR code is 
associated with the particular service (Netflix, AppleTV, Disney+).  Readers 
could assume that the QR codes originate from the TV manufacturer’s service 
alone as written.
  4.  Section 4.3.9 reads, “… using an e-mail campaign etc.”  Should this be 
rewritten, “using an e-mail campaign, for example.”?
  5.  Section 6.2.3 discusses FIDO CTAP 2.2.  This document is still in review 
draft 01<https://fidoalliance.org/specifications/download/>.  We should note 
that the document is not final as of today.
  6.  Section 6.2.3.5 could be softened a bit.  The first sentence should 
include, “… and a suitable FIDO credential is not available on the consumption 
device.”  In most patterns, this mechanism is used to bootstrap a new 
credential on the device, rather than using this mechanism for authN every time.

Authors, if you have any questions please let me know.

Thanks,
-dhs

--
Dean H. Saxe, CIDPRO<https://idpro.org/cidpro/> (he/him)
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS)
E: deans...@amazon.com<mailto:deans...@amazon.com> | M: 
206-659-7293

From: OAuth mailto:oauth-boun...@ietf.org>> on behalf 
of Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com>>
Date: Monday, April 22, 2024 at 7:57 AM
To: oauth mailto:oauth@ietf.org>>
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


We have not received any feedback on this document so far.

This is a reminder to review and provide feedback on this document.
If you reviewed the document, and you do not have any comments or concerns, it 
would be great if you can send an email to the list indicating that.

Regards,
 Rifaat



On Mon, Apr 15, 2024 at 9:32 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
All,

This is a WG Last Call for the Cross-Device Flows BCP document.
https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-06.html

Please, review this document and reply on the mailing list if you have any 
comments or concerns, by April 29th.

Regards,
  Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: RPi 4b Wifi Device

[Thomas D. Dean]

On 4/20/24 15:29, Michael Cheponis wrote:
> I run an RPi 4B/8G with external USB SSD drive; I do this because my 
uSD cards were getting worn out after about a year of use; I've had no 
such problems with my Samsung 870 EVO nor Samsung SSD T7.

>
> I use the built-in GigE adaptor on the RPi 4B, because it's 
convenient as I have wired ethernet most places.   So I can't help with 
WiFi.

>
> I have been running an RPi 3 from a Lexar 64B Thumb Drive since June 
2019 - no problem there, either.


I use SanDisk Extreme Pro 128GiB flash drives in the RPi 4b USB 3 port, 
sometimes with a 6" USB 3 cable.


I can always boot RPi OS on these drives. I have never been able to boot 
NetBSD 10.


I downloaded the arm64.img, and RPi4_UEFI_Firmware_v1.35.zip. On a Linux 
desktop:

  dd if=arm64.img of=/dev/sda bs=1M
and, then I replace the corresponding files from 
RPi4_UEFI_Firmware_v1.35.zip.

  mount /de3v/sda1 /mnt
  cd /mnt
  unzip ~/NetBSD/RPi4_UEFI_Firmware_v1.35.zip

When I attempt to boot, I see the color flash, then a cursor at the top 
left of the screen, then the screen goes blank.


he flash drive shows lots of accesses during this process and then shows 
access flashes in groups of 3 or 4. I think this indicates an unreadable 
file, I think.


When I do the the same actions with an SD card, NetBSD boots.

What do you do?

Tom Dean

Re: [OAUTH-WG] WGLC for Cross-Device Flows BCP

[Saxe, Dean]

Rifaat,

I have a few minor nits in the doc, nothing of significant concern for WGLC.


  1.  When describing the visuals documenting the flows, there is a step that 
includes “The user authenticates to the authorization server”.  In each case 
this should include verbiage to indicate that this is only necessary if the 
user is unauthenticated, e.g. “If unauthenticated, the user authenticates to 
the authorization server…”.  Specific sections include 3.1.1, 3.1.2, 4.1.1, 
4.1.2
  2.  Section 3.1.3 the final sentence notes the authorization data may be 
delivered as a text message or via a mobile app.  This is inconsistent with the 
methods mentioned in the first paragraph, which includes email and text 
messages.  I suggest being clear that these are example mechanisms and not a 
full list of mechanisms by which codes can be delivered.
  3.  Section 3.3.1 the first sentence should note that the QR code is 
associated with the particular service (Netflix, AppleTV, Disney+).  Readers 
could assume that the QR codes originate from the TV manufacturer’s service 
alone as written.
  4.  Section 4.3.9 reads, “… using an e-mail campaign etc.”  Should this be 
rewritten, “using an e-mail campaign, for example.”?
  5.  Section 6.2.3 discusses FIDO CTAP 2.2.  This document is still in review 
draft 01<https://fidoalliance.org/specifications/download/>.  We should note 
that the document is not final as of today.
  6.  Section 6.2.3.5 could be softened a bit.  The first sentence should 
include, “… and a suitable FIDO credential is not available on the consumption 
device.”  In most patterns, this mechanism is used to bootstrap a new 
credential on the device, rather than using this mechanism for authN every time.

Authors, if you have any questions please let me know.

Thanks,
-dhs

--
Dean H. Saxe, CIDPRO<https://idpro.org/cidpro/> (he/him)
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS)
E: deans...@amazon.com<mailto:deans...@amazon.com> | M: 
206-659-7293

From: OAuth  on behalf of Rifaat Shekh-Yusef 

Date: Monday, April 22, 2024 at 7:57 AM
To: oauth 
Subject: RE: [EXTERNAL] [OAUTH-WG] WGLC for Cross-Device Flows BCP


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


We have not received any feedback on this document so far.

This is a reminder to review and provide feedback on this document.
If you reviewed the document, and you do not have any comments or concerns, it 
would be great if you can send an email to the list indicating that.

Regards,
 Rifaat



On Mon, Apr 15, 2024 at 9:32 AM Rifaat Shekh-Yusef 
mailto:rifaat.s.i...@gmail.com>> wrote:
All,

This is a WG Last Call for the Cross-Device Flows BCP document.
https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-06.html

Please, review this document and reply on the mailing list if you have any 
comments or concerns, by April 29th.

Regards,
  Rifaat & Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS

[Dean Rasheed]

On Mon, 22 Apr 2024 at 06:04, Michael Paquier  wrote:
>
> On Fri, Apr 19, 2024 at 12:47:43PM +0300, Aleksander Alekseev wrote:
> > Thanks. I see a few pieces of code that use special FOO_NUMBER enum
> > values instead of a macro. Should we refactor these pieces
> > accordingly? PFA another patch.
>
> I don't see why not for the places you are changing here, we can be
> more consistent.

[Shrug] I do prefer using a macro. Adding a counter element to the end
of the enum feels like a hack, because the counter isn't the same kind
of thing as all the other enum elements, so it feels out of place in
the enum. On the other hand, I think it's a fairly common pattern that
most people will recognise, and for other enums that are more likely
to grow over time, it might be less error-prone than a macro, which
people might overlook and fail to update.

>  Now, such changes are material for v18.

Agreed. This has been added to the next commitfest, so let's see what
others think.

Regards,
Dean

NetBSD RPi 4b Install/Boot Failure

[Thomas D. Dean]

I am using a SanDisk Extreme Pro 128GiB flash drive connected to the RPi 
4b USB-3 port.


I can use this with the RPi OS.

I tried downloading Generic 64-bit from 
http://nycdn.netbsd.org/pub/arm/, marked as for the Raspberry Pi. I 
unzipped the file to get the .img.




> ls -l NetBSD-10-aarch64--generic.img
-rw-rw-r-- 1 tomdean tomdean 1582301184 Apr 20 20:46 
NetBSD-10-aarch64--generic.img


> sudo dd if=NetBSD-10-aarch64--generic.img of=/dev/sda bs=1M conv=sync
1509+0 records in
1509+0 records out
1582301184 bytes (1.6 GB, 1.5 GiB) copied, 6.21875 s, 254 MB/s

> sudo mount /dev/sda1 /mnt
> ls /mnt
EFI   cmdline.txt  fixup.dat fixup_cd.dat  start4.elf
LICENCE.broadcom  config.txt   fixup4.datnetbsd.imgstart4cd.elf
bootcode.bin  dtb  fixup4cd.dat  start.elf start_cd.elf

> cat /mnt/cmdline.txt
root=NAME=netbsd-root console=fb

> cat /mnt/config.txt
#
upstream_kernel=1
#
arm_64bit=1
os_prefix=dtb/broadcom/
cmdline=../../cmdline.txt
kernel=/netbsd.img
kernel_address=0x20
enable_uart=1
force_turbo=0

I connected a HDMI display and the SanDisk Extreme Pro flash drive (USB 
3) to the RPi 4b and applied power.


The led on the flash drive blinked for 3~4 seconds and stopped. The 
screen flashed and went blank. Nothing afterwards...


I booted the RPi 4b from a SD card, NetBSD 10 and connected the flash 
drive to a USB-3 port.


fsck says the drive is OK.

I mounted /dev/dk2 on /mnt There are some missing files on dk2 as 
compared to /boot.


pi-4b-1# ls -l /mnt
total 23142
drwxr-xr-x  1 root  wheel  1024 Mar 28 16:53 EFI
-rwxr-xr-x  1 root  wheel  1594 Mar 28 16:53 LICENCE.broadcom
-rwxr-xr-x  1 root  wheel 52476 Mar 28 16:53 bootcode.bin
-rwxr-xr-x  1 root  wheel33 Mar 28 16:53 cmdline.txt
-rwxr-xr-x  1 root  wheel   155 Mar 28 16:53 config.txt
drwxr-xr-x  1 root  wheel  1024 Mar 28 16:53 dtb
-rwxr-xr-x  1 root  wheel  7269 Mar 28 16:53 fixup.dat
-rwxr-xr-x  1 root  wheel  5412 Mar 28 16:53 fixup4.dat
-rwxr-xr-x  1 root  wheel  3180 Mar 28 16:53 fixup4cd.dat
-rwxr-xr-x  1 root  wheel  3180 Mar 28 16:53 fixup_cd.dat
-rwxr-xr-x  1 root  wheel  16761568 Mar 28 16:53 netbsd.img
-rwxr-xr-x  1 root  wheel   2979264 Mar 28 16:53 start.elf
-rwxr-xr-x  1 root  wheel   2254944 Mar 28 16:53 start4.elf
-rwxr-xr-x  1 root  wheel808060 Mar 28 16:53 start4cd.elf
-rwxr-xr-x  1 root  wheel808060 Mar 28 16:53 start_cd.elf
rpi-4b-1# ls -l /boot
total 25293
drwxr-xr-x  1 root  wheel  1024 Apr  1 22:28 EFI
-rwxr-xr-x  1 root  wheel  1594 Apr  1 22:28 LICENCE.broadcom
-rwxr-xr-x  1 root  wheel   2031616 Jun  5  2023 RPI_EFI.fd
-rwxr-xr-x  1 root  wheel  5051 Jun  5  2023 Readme.md
-rwxr-xr-x  1 root  wheel 54388 Jun  5  2023 bcm2711-rpi-4-b.dtb
-rwxr-xr-x  1 root  wheel 54477 Jun  5  2023 bcm2711-rpi-400.dtb
-rwxr-xr-x  1 root  wheel 54997 Jun  5  2023 bcm2711-rpi-cm4.dtb
-rwxr-xr-x  1 root  wheel 52476 Apr  1 22:28 bootcode.bin
-rwxr-xr-x  1 root  wheel33 Apr  1 22:28 cmdline.txt
-rwxr-xr-x  1 root  wheel   243 Jun  5  2023 config.txt
drwxr-xr-x  1 root  wheel  1024 Apr  1 22:28 dtb
drwxr-xr-x  1 root  wheel  1024 Apr 19 04:13 firmware
-rwxr-xr-x  1 root  wheel  7269 Apr  1 22:28 fixup.dat
-rwxr-xr-x  1 root  wheel  5397 Jun  5  2023 fixup4.dat
-rwxr-xr-x  1 root  wheel  3180 Apr  1 22:28 fixup4cd.dat
-rwxr-xr-x  1 root  wheel  3180 Apr  1 22:28 fixup_cd.dat
-rwxr-xr-x  1 root  wheel  16761568 Apr  1 22:28 netbsd.img
drwxr-xr-x  1 root  wheel  1024 Apr 19 04:13 overlays
-rwxr-xr-x  1 root  wheel   2979264 Apr  1 22:28 start.elf
-rwxr-xr-x  1 root  wheel   2253088 Jun  5  2023 start4.elf
-rwxr-xr-x  1 root  wheel808060 Apr  1 22:28 start4cd.elf
-rwxr-xr-x  1 root  wheel808060 Apr  1 22:28 start_cd.elf

Any ideas?

Tom Dean

Re: need your advice before new Raspberry Pi purchase

[Thomas D. Dean]

On 4/20/24 17:24, Michael wrote:

The 3GB limit is on by default for some old linux kernels that don't
have the DMA workaround. It takes about 10 seconds to get into the UEFI
setup menu and turn it off.


What is the UEFI setup menu? How do I get in to it?

I used dd to write arm64.img to the USB 3 flash drive.

Is the NetBSD installer available in the arm64.img? Is it possible to 
use the installer on the RPi 4b (booted from the SD card) to install 
NetBSD 10 on the USB 3 flash drive?


Tom Dean

Re: RPi 4b Wifi Device

[Thomas D. Dean]

On 4/20/24 15:29, Michael Cheponis wrote:
I run an RPi 4B/8G with external USB SSD drive; I do this because my uSD 
cards were getting worn out after about a year of use; I've had no such 
problems with my Samsung 870 EVO nor Samsung SSD T7.


I use the built-in GigE adaptor on the RPi 4B, because it's convenient 
as I have wired ethernet most places.   So I can't help with WiFi.


I have been running an RPi 3 from a Lexar 64B Thumb Drive since June 
2019 - no problem there, either.


I use SanDisk Extreme Pro 128GiB flash drives in the RPi 4b USB 3 port, 
sometimes with a 6" USB 3 cable.


I can always boot RPi OS on these drives. I have never been able to boot 
NetBSD 10.


I downloaded the arm64.img, and RPi4_UEFI_Firmware_v1.35.zip. On a Linux 
desktop:

  dd if=arm64.img of=/dev/sda bs=1M
and, then I replace the corresponding files from 
RPi4_UEFI_Firmware_v1.35.zip.

  mount /de3v/sda1 /mnt
  cd /mnt
  unzip ~/NetBSD/RPi4_UEFI_Firmware_v1.35.zip

When I attempt to boot, I see the color flash, then a cursor at the top 
left of the screen, then the screen goes blank.


The flash drive shows lots of accesses during this process and then 
shows access flashes in groups of 3 or 4. I think this indicates an 
unreadable file, I think.


When I do the the same actions with an SD card, NetBSD boots.

What do you do?

Tom Dean

Re: RPi 4b Wifi Device

[Thomas D. Dean]

On 4/20/24 13:16, Michael van Elst wrote:

tomd...@wavecable.com ("Thomas D. Dean") writes:


# wpa_cli status
Selected interface 'bwfm0'
21:58:44.815: bssid=60:38:e0:db:a9:7a
freq=0
ssid=tddhome
id=0
mode=station
pairwise_cipher=TKIP
group_cipher=TKIP
key_mgmt=WPA-PSK
wpa_state=GROUP_HANDSHAKE
ip_address=169.254.135.120
address=e4:5f:01:da:eb:46



I don't understand where the inet 169.254.135.120 comes from. The router
pool is 192.168.1.xxx.


169.254.x.x is a "link local" address. dhcpcd falls back to such an
address, if it doesn't get an answer from a dhcp server. Apparently
wpa_supplicant cannot connect to the network.


wpa_state=GROUP_HANDSHAKE


says that it still tries to associate. When it's done this would
change to COMPLETED.



I have two RPi 4b's. One with NetBSD 10 on an SD card and the other with 
RPi OS on a USB flash drive. (I can not get NetBSD to boot from a flash 
drive)


As far as I can tell the network configurations are the same for WIFI on 
both. I see comments on the web about NetBSD 10 problems with the bwfm 
device.


I need WIFI. So, I go back to RPi OS.

Thanks for all the replies.

Tom Dean

Re: RPi 4b Wifi Device

[Thomas D. Dean]

I have Authentication timeout.

# wpa_cli
> scan_results
23:27:43.451: bssid / frequency / signal level / flags / 
ssid60:38:e0:db:a9:7a	2462	227	[WPA-PSK-TKIP][ESS]	tddhome

...
 23:27:47.736: CTRL-EVENT-SCAN-RESULTS
  23:27:47.736: Trying to associate with 60:38:e0:db:a9:7a 
(SSID='tddhome' freq=2462 MHz)

  23:27:52.874: Associated with 60:38:e0:db:a9:7a
  23:28:02.888: Authentication with 60:38:e0:db:a9:7a timed out.
  23:28:02.889: CTRL-EVENT-DISCONNECTED bssid=60:38:e0:db:a9:7a 
reason=3 locally_generated=1
  23:28:02.889: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="tddhome" 
auth_failures=1 duration=10 reason=CONN_FAILED


The linksys router uses WPA2/WPA mixed Personal. PSK is correct in 
etc/wpa_supplicant.conf:


# cat /etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
network={
ssid="tddhome"
key_mgmt=WPA-PSK
    psk="..."
}

Tom Dean

Re: RPi 4b Wifi Device

[Thomas D. Dean]

On 4/19/24 18:35, Michael van Elst wrote:

tomd...@wavecable.com ("Thomas D. Dean") writes:


How do I setup wpa_supplicant?


That depends on what you want to do.

Here are some examples:
https://wiki.netbsd.org/tutorials/how_to_use_wpa_supplicant/


I saw that.
dhcp is working over the wired connection.

I thought I had everything configured for wifi. It just does not work.

I have a cable modem <-> wifi/wired router. I have several machines 
connected. Linux and windoze, now. One RPi with NetBSD 10. Used to have 
some FreeBSD machines, but, they have been replaced.


# etc/rc.d/wpa_supplicant reload
Selected interface 'bwfm0'
21:58:35.931: OK

# wpa_cli status
Selected interface 'bwfm0'
21:58:44.815: bssid=60:38:e0:db:a9:7a
freq=0
ssid=tddhome
id=0
mode=station
pairwise_cipher=TKIP
group_cipher=TKIP
key_mgmt=WPA-PSK
wpa_state=GROUP_HANDSHAKE
ip_address=169.254.135.120
address=e4:5f:01:da:eb:46

# ifconfig bwfm0
bwfm0: flags=0x8843 mtu 1500
ssid "" nwkey 65536:"","","",""
powersave off
address: e4:5f:01:da:eb:46
media: IEEE802.11 autoselect (DS1 mode 11g)
status: no network
inet6 fe80::d7c0:41b9:46a5:a5ff%bwfm0/64 flags 0x8 scopeid 0x3
inet 169.254.135.120/16 broadcast 169.254.255.255 flags 0x4



I don't understand where the inet 169.254.135.120 comes from. The router 
pool is 192.168.1.xxx.


Tom Dean

Re: RPi 4b Wifi Device

[Thomas D. Dean]

On 4/19/24 09:40, Michael van Elst wrote:

Reason is that the platform is canonically named "raspberrypi,4-model-b"
but UEFI chose "Raspberry Pi 4 Model B" instead.


> pwd
/home/tomdean/NetBSD
> ls -l
total 2154
-rw-rw-r-- 1 tomdean tomdean  272510976 Apr 18 09:40 
NetBSD-10.0-evbarm-aarch64.iso

drwxrwxr-x 4 tomdean tomdean   4096 Apr 18 21:12 RPi4-1.35
drwxrwxr-x 7 tomdean tomdean   4096 Apr 10 23:27 RPi4-1.37
-rw-rw-r-- 1 tomdean tomdean 433670 Apr 18 16:52 RPi4-1.37.zip
-rw-rw-r-- 1 tomdean tomdean3144359 Apr 18 21:01 
RPi4_UEFI_Firmware_v1.35.zip

-rw-rw-r-- 1 tomdean tomdean 1582301184 Apr  3 15:02 arm64.img
-rw-rw-r-- 1 tomdean tomdean  399419622 Apr 18 09:50 arm64.img.gz

> grep -Rail "raspberrypi\\,4\-model-b" *
RPi4-1.35/bcm2711-rpi-4-b.dtb
arm64.img

> grep -Rail "Raspberry\ Pi\ 4\  Model\  B" *
< nothing found>

I could not get NetBSD 10 to boot with the 1.37 files. With the 1.35 
files, it booted and seems to work, other than WIFI.


I created a link to "Raspberry Pi 4  Model  B" and the error went away.

How do I setup wpa_supplicant?

Tom Dean

Re: RPi 4b Wifi Device

[Thomas D. Dean]

On 4/18/24 22:00, Michael van Elst wrote:

tomd...@wavecable.com ("Thomas D. Dean") writes:


What is the wifi device in the RPi 4b? Driver?


It's a chip similar to the one in the older RPIs:

bwfm0: chip 0x4345 rev 6
bwfm0: Firmware file default:brcmfmac43455-sdio.bin
bwfm0: Firmware file model-spec: brcmfmac43455-sdio.raspberrypi,4-model-b.bin
bwfm0: Found Firmware file: brcmfmac43455-sdio.raspberrypi,4-model-b.bin
bwfm0: NVRAM file default:brcmfmac43455-sdio.txt
bwfm0: NVRAM file model-spec: brcmfmac43455-sdio.raspberrypi,4-model-b.txt
bwfm0: Found NVRAM file: brcmfmac43455-sdio.raspberrypi,4-model-b.txt
bwfm0: CLM file default:brcmfmac43455-sdio.clm_blob
bwfm0: CLM file model-spec: brcmfmac43455-sdio.raspberrypi,4-model-b.clm_blob
bwfm0: Found CLM file: brcmfmac43455-sdio.raspberrypi,4-model-b.clm_blob
bwfm0: CHIPACTIVE

bwfm0: flags=0x8843 mtu 1500
 ssid  nwkey *
 powersave off
 bssid ##:##:##:##:##:## chan 100
 address: ##:##:##:##:##:##
 media: IEEE802.11 autoselect (VHT mode 11ac)
 status: active
 inet6 fe80:::::%bwfm0/64 flags 0 scopeid 0x3



I saw bwfm0: in /var/log/messages, from memory, similar to the ones listed.
One error. autoconfiguration error: NVRAM file not available.
The CHIPACTIVE line is missng.

ifconfig does not show bwfm0, only genet0 and lo0.

I managed to get a wired connection (across the room at chin height...)
Networking is up. ntp set the date correctly. DNS works. I can ssh into 
the system.


It has been 5 or 6 years since I ran BSD. I used Berkeley BSD and FreeBSD.

How do I get wifi started? I can start wpa_supplicant and I have a 
network block in /etc/wpa_supplicant.


network={
  ssid=""
  psk=""
}

service wpa_supplicant onestatus shows it is running

Tom Dean

Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS

[Dean Rasheed]

On Thu, 18 Apr 2024 at 13:00, Aleksander Alekseev
 wrote:
>
> Fair point. PFA the alternative version of the patch.
>

Thanks. Committed.

Regards,
Dean

pgsql: Use macro NUM_MERGE_MATCH_KINDS instead of '3' in MERGE code.

[Dean Rasheed]

Use macro NUM_MERGE_MATCH_KINDS instead of '3' in MERGE code.

Code quality improvement for 0294df2f1f84.

Aleksander Alekseev, reviewed by Richard Guo.

Discussion: 
https://postgr.es/m/CAJ7c6TMsiaV5urU_Pq6zJ2tXPDwk69-NKVh4AMN5XrRiM7N%2BGA%40mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/2e068db56e31dfb510fe7416e52b7affe26f278f

Modified Files
--
src/backend/optimizer/prep/prepjointree.c | 2 +-
src/backend/parser/parse_merge.c  | 2 +-
src/include/nodes/execnodes.h | 2 +-
src/include/nodes/primnodes.h | 2 ++
4 files changed, 5 insertions(+), 3 deletions(-)

RPi 4b Wifi Device

[Thomas D. Dean]

What is the wifi device in the RPi 4b? Driver?

Tom Dean

Re: Install Failure RPi 4

[Thomas D. Dean]

On 4/18/24 13:56, Thomas D. Dean wrote:


I followed:
https://mail-index.netbsd.org/port-arm/2023/07/19/msg008301.html
and it boots.

download
https://github.com/pftf/RPi4/releases/download/v1.35/RPi4_UEFI_Firmware_v1.35.zip

> mount mmcblk0p1 /mnt
> cd /mnt
> unzip ~/RPi4_UEFI_Firmware_v1.35.zip

and reboot

Tom Dean
Silverdale, WA

Install Failure RPi 4

[Thomas D. Dean]

I have an RPi 4b using a USB flash drive and RPi OS.

I attempted to install NetBSD 10 on an SD card.

On the RPi, I downloaded arm64.img.gz and extracted arm64.img.

> ls -l arm64.img
rw-rw-r-- 1 tomdean tomdean 1582301184 Apr  3 15:02 arm64.img

I used dd to copy the image to an SD card.

> dd if=armv7.img of=/dev/mmcblk0 bs=1m conv=sync

After this, the SD card looked OK for the RPi.

I shut down the RPi, removed the USB flash drive. I connected a mouse, 
keyboard, and display, and powered up with the SD card inserted.


The red LED is on continuously. The green LED flashed for ~1 sec, was 
off for ~1 sec, flashed for ~2 sec, was off for ~2 sec, flashed for ~3 
sec, then was off (5 minutes). The display flashed then was blank, again 
(5 min).


Tom DeanI have an RPi 4b using a USB flash drive and RPi OS.

I attempted to install NetBSD 10 on an SD card.

On the RPi, I downloaded arm64.img.gz and extracted arm64.img.

> ls -l arm64.img
rw-rw-r-- 1 tomdean tomdean 1582301184 Apr  3 15:02 arm64.img

I used dd to copy the image to an SD card.

> dd if=armv7.img of=/dev/mmcblk0 bs=1m conv=sync

After this, the SD card looked OK for the RPi.

I shut down the RPi, removed the USB flash drive. I connected a mouse, 
keyboard, and display, and powered up with the SD card inserted.

The red LED is on continuously. The green LED flashed for ~1 sec, was off for 
~1 sec, flashed for ~2 sec, was off for ~2 sec, flashed for ~3 sec, then was 
off (5 minutes). The display flashed then was blank, again (5 min).

I powered down, removed the SD card, reconnected the USB flash drive and 
powered up. I reinserted the SD card.

> sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 29.72 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 98B95E86-7515-4738-B538-FC5107ADFEC9

Device  Start  End  Sectors  Size Type
/dev/mmcblk0p1  32768   196607   163840   80M EFI System
/dev/mmcblk0p2 196608 62332927 62136320 29.6G NetBSD FFS

> sudo mount /dev/mmcblk0p1 /mnt
> ls -l /mnt
total 23142
drwxr-xr-x 3 root root 1024 Apr  1 23:28 EFI
-rwxr-xr-x 1 root root 1594 Apr  1 23:28 LICENCE.broadcom
-rwxr-xr-x 1 root root52476 Apr  1 23:28 bootcode.bin
-rwxr-xr-x 1 root root   33 Apr  1 23:28 cmdline.txt
-rwxr-xr-x 1 root root  155 Apr  1 23:28 config.txt
drwxr-xr-x 8 root root 1024 Apr  1 23:28 dtb
-rwxr-xr-x 1 root root 7269 Apr  1 23:28 fixup.dat
-rwxr-xr-x 1 root root 5412 Apr  1 23:28 fixup4.dat
-rwxr-xr-x 1 root root 3180 Apr  1 23:28 fixup4cd.dat
-rwxr-xr-x 1 root root 3180 Apr  1 23:28 fixup_cd.dat
-rwxr-xr-x 1 root root 16761568 Apr  1 23:28 netbsd.img
-rwxr-xr-x 1 root root  2979264 Apr  1 23:28 start.elf
-rwxr-xr-x 1 root root  2254944 Apr  1 23:28 start4.elf
-rwxr-xr-x 1 root root   808060 Apr  1 23:28 start4cd.elf
-rwxr-xr-x 1 root root   808060 Apr  1 23:28 start_cd.elf

> cat /mnt/config.txt
#
upstream_kernel=1
#
arm_64bit=1
os_prefix=dtb/broadcom/
cmdline=../../cmdline.txt
kernel=/netbsd.img
kernel_address=0x20
enable_uart=1
force_turbo=0

[Cscwg-public] Final CSCWG Minutes April 4, 2024

[Dean Coclin via Cscwg-public]

 

Minutes for CSCWG Call 4 Apr 2024

 

Agenda:

 

1.  Roll Call
2.  Antitrust reminder
3.  Approve prior meeting minutes - F2F  (awaiting draft from Andrea),
March 21st (Brianca)
4.  Ballot status: Marking the EV CS guidelines obsolete (CSC-23). Do we
need an IPR review?
5.  Proposed ballots: Remove EV Guideline References
6.  Proposed ballot for Time-stamp Requirements update; CSC-24
7.  Continued discussion on Application for Associate Member status from
Keyfactor 
8.  Interested Party application from Wangmo Tenzing (as an individual)
9.  Other business
10. Next meeting - April 18th
11. Adjourn

 

 

Attendees:

Brian Winters (Identrust), Bruce Morton (Entrust), Corey Bonnell (DigiCert),
Dean Coclin (DigiCert), Ian McMillan (Microsoft), Inaba Atsushi
(GlobalSign), Inigo Barreira (Sectigo), Marco Schambach - (IdenTrust), Mohit
Kumar (GlobalSign), Nome Huang - (TrustAsia), Rollin Yu - (TrustAsia), Scott
Rea (eMudhra), Tim Crawford - (CPA Canada/WebTrust), Trevoli Ponds-White -
(Amazon),

 

Minutes:

Dean read the note well.

 

Meeting minutes for F2F-New Delhi (Andrea Holland) yet to be posted.

Meeting minutes for March 21, 2024 Meeting (Brianca Martin) yet to be
posted.

 

Ballot CSC-23 Marking the EV Code Signing Guidelines SUPERCEDED

(Dean) This ballot passed, but the question has arisen whether there is need
for an IPR review since all we are doing is marking these obsolete?

(Bruce) there is nothing to present to lawyers, so what is there to review?

Consensus on call is that IPR Review is not necessary in this case as agreed
in WG call.

 

Removing EVG references in CSBRs

No recent update or status from Dimitris for removing references to EVGs.
Since Dimitris is not on current call, this will be deferred to next
meeting.

 

Ballot CSC-24 Timestamping Private Key Protection

Ballot was posted for discussion on 2 Apr 2024. Bruce raised concern that
potential re-word was required because of NOT catering to Online CAs already
in use. Mohit asked for clarification as to whether this only applied to
future NEW CAs or whether it anticipated existing CAs to also be covered by
the guideline. 

It is expected that some amendments will be applied to address the above,
and a restart to the discussion period will apply.

 

Individual Joiner Request

Wangmo Tenzing from Lawrence Livermore National Lab originally sent IPR
Agreement representing the Lab but clarified that this was rather meant to
be an individual Interested Party and not as the Lab's representative. IPRA
was withdrawn, and request resubmitted as an individual Interested Party.

No objections from WG to accept Wangmo as individual Interested Party. 

 

Associate Member Application

Follow on from previous meeting (and F2F meeting) where discussion was held
regarding Key Factor's application to become an Associated Member. 

No objections from WG to accept Key Factor as Associate Members.

 

Other Business: EV vs OV for Code Signing

Request Microsoft to clarify their treatment of OV vs EV CS certs and where
there is differentiation. (Ian) The only place of differentiation is
on-boarding for the Hardware Developer Centre Partner Program, which makes a
requirement for EV.  There are no other current differentiation anywhere.

Question from Bruce on how this is validated? (Ian) We are not looking at
the OID in the cert, we are more looking at the issuing CA, since its only
on application to the program. Microsoft is currently reviewing with the
Hardware Developer Centre folks to work out how this will be dealt with in
future.

Clarification requested from Bruce on whether its the case that EV no longer
helps with Reputation? (Ian) It is not the signer's reputation that is
paramount rather than the credentials they are using.

Clarification from Bruce as to whether Microsoft values SubjectInfo in EV
certs? (Ian) There is not a focus to put any value on EV-specific fields.

Clarification from Mohit as to whether that implies a move to OV in future?
(Ian) Microsoft is evaluating the bar between OV and EV and looking to
strike a balance between EV rigor and the effort for organizations around
the world to get it. We are trying to make it as simple as possible for the
ecosystem. So we are evaluating if an EV uplift is worth the value.

Suggestion from Bruce: take current BRs, and remove all EV related content
and see if it makes sense or whether the extra EV stuff is actually still
needed?

(Ian) The biggest challenge is how to provide clear communications to
developers about which certificate is required.

(Bruce) Perhaps the better approach is to decide where to go with this, and
then just work towards that.

Some discussion ensued about current validation of Organizations across all
the CABF working groups, and Bruce pointed out we already have 3 ways today,
and surely there was little value introducing a 4th specific to CS. To have
further discussion at the next F2F.

 

Meeting adjourned. Next

[Cscwg-public] Final minutes of CSCWG March 21, 2024

[Dean Coclin via Cscwg-public]

 

Minutes for CSCWG Call 21 Mar 2024

 

Agenda:

 

1.  Roll Call
2.  Antitrust reminder
3.  Minutes
4.  Ballots
5.  Membership
6.  Other business
7.  Next meeting - April 4th
8.  Adjourn

 

Attendees:

Dean Coclin (DigiCert), Martijn Katerbarg (Sectigo), Brianca Martin
(Amazon), Tim Crawford (CPA Canada/WebTrust), Thomas Zermeno (SSL.com),
Mohit Kumar (GlobalSign), Scott Rea (eMudhra, Mohit Kumar (GlobalSign),
Dimitris Zacharopoulos (HARICA), Atsushi INABA (GlobalSign), Inigo Barreira
(Sectigo)

 

Minutes:

Dean Coclin read the Antitrust policy.

 

Meeting minutes - No minutes to approve. Andrea Holland working on minutes
from F2F-New Delhi.

 

Ballots

*   CSC-23, Marking the EV Code Signing Guidelines Obsolete, in the
voting period, ends next week. Needs vote from Microsoft (only CA in the
group).
*   Removing EV guidelines references (in discussion) - imported the
latest changes from the CS BR's, ballot is ready, looking for 2 endorsers.
EV will not be removed, will likely enhance the validation methods of the
existing OV level.
*   Noted that a file on the wiki hasn't been changed in years. Not
included in the guidelines, needs chair approval to remove it.
*   Timestamping Private Key Protection - Incorporated feedback, ready
to start discussion period.

 

Membership

*   Identrust - Current associate member, requesting transition to full
membership in the CSWG. Server Cert Working Group (SCWG) approved them to be
a full member. Each working group needs to approve their status, membership
level can be different across groups. Ian (Microsoft) confirmed they have
the appropriate root in Windows and the appropriate audit (link provided in
the application). Request approved without objection. Dean to send
confirmation to Marco.
*   Keyfactor - Request to upgrade to become an associate member in the
CSWG. Noted for information that the request was approved by the SCWG.
Status has traditionally been used for groups like FederalPKI, Webtrust,
Etsy and companies that are in the process of applying for a root
certificate in a browser. This would be the 1st time for the CSWG that a
particular company would be given associate member status. It was noted that
they run a CA platform that several CA/B forum members use, may not
specifically be related to code signing. Discussion on Keyfactor was held at
the forum level during the F2F meeting. Concern was raised about setting a
bad precedent. Dean to discuss with Tim. Approval postponed to the next
meeting.

 

Other Business: None

 

Meeting adjourned. Next meeting April 4th.

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public

Broken Link

[Thomas D. Dean]

On https://wiki.netbsd.org/ports/evbarm/
Select NetBSD/evbarm 10.0 INSTALL notes
Produces Error 404.

Tom Dean

Re: RFR: 8329433: Reduce nmethod header size [v8]

[Dean Long]

On Thu, 18 Apr 2024 00:41:03 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Address comment

Marked as reviewed by dlong (Reviewer).

-

PR Review: https://git.openjdk.org/jdk/pull/18768#pullrequestreview-2007632424

Re: RFR: 8330388: Remove invokedynamic cache index encoding

[Dean Long]

On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva  
wrote:

> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), 
> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and 
> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic 
> operands needed to be rewritten to encoded values to better distinguish indy 
> entries from other cp cache entries. The above changes now distinguish 
> between entries with `to_cp_index()` using the bytecode, which is now 
> propagated by the callers.
> 
> The encoding flips the bits of the index so the encoded index is always 
> negative, leading to access errors if there is no matching decode call. These 
> calls are removed with some methods adjusted to distinguish between indices 
> with the bytecode. Verified with tier 1-5 tests.

@dougxc should check JVMCI changes.

-

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18819#pullrequestreview-2007498087

Re: RFR: 8330388: Remove invokedynamic cache index encoding

[Dean Long]

On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva  
wrote:

> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), 
> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and 
> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic 
> operands needed to be rewritten to encoded values to better distinguish indy 
> entries from other cp cache entries. The above changes now distinguish 
> between entries with `to_cp_index()` using the bytecode, which is now 
> propagated by the callers.
> 
> The encoding flips the bits of the index so the encoded index is always 
> negative, leading to access errors if there is no matching decode call. These 
> calls are removed with some methods adjusted to distinguish between indices 
> with the bytecode. Verified with tier 1-5 tests.

Did you consider minimizing changes by leaving 
decode_invokedynamic_index/encode_invokedynamic_index calls in place, but 
having the implementations not change the value?

-

PR Comment: https://git.openjdk.org/jdk/pull/18819#issuecomment-2062609288

Re: RFR: 8330388: Remove invokedynamic cache index encoding

[Dean Long]

On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva  
wrote:

> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), 
> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and 
> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic 
> operands needed to be rewritten to encoded values to better distinguish indy 
> entries from other cp cache entries. The above changes now distinguish 
> between entries with `to_cp_index()` using the bytecode, which is now 
> propagated by the callers.
> 
> The encoding flips the bits of the index so the encoded index is always 
> negative, leading to access errors if there is no matching decode call. These 
> calls are removed with some methods adjusted to distinguish between indices 
> with the bytecode. Verified with tier 1-5 tests.

src/hotspot/share/ci/ciEnv.cpp line 1513:

> 1511: // process the BSM
> 1512: int pool_index = indy_info->constant_pool_index();
> 1513: BootstrapInfo bootstrap_specifier(cp, pool_index, indy_index);

Why not just change the incoming parameter name to `index`?

src/hotspot/share/classfile/resolutionErrors.hpp line 60:

> 58: 
> 59:   // This function is used to encode an invokedynamic index to 
> differentiate it from a
> 60:   // constant pool index.  It assumes it is being called with a index 
> that is less than 0

Is this comment still correct?

src/hotspot/share/interpreter/bootstrapInfo.cpp line 77:

> 75: return true;
> 76:   } else if (indy_entry->resolution_failed()) {
> 77: int encoded_index = 
> ResolutionErrorTable::encode_indy_index(_indy_index);

That's an improvement, from two levels of encoding to only one!

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18819#discussion_r1569625123
PR Review Comment: https://git.openjdk.org/jdk/pull/18819#discussion_r1569626519
PR Review Comment: https://git.openjdk.org/jdk/pull/18819#discussion_r1569627219

Re: RFR: 8329433: Reduce nmethod header size [v3]

[Dean Long]

On Tue, 16 Apr 2024 16:09:21 GMT, Vladimir Kozlov  wrote:

>> src/hotspot/share/code/nmethod.cpp line 1441:
>> 
>>> 1439: int deps_size = align_up((int)dependencies->size_in_bytes(), 
>>> oopSize);
>>> 1440: int sum_size  = oops_size + metadata_size + deps_size;
>>> 1441: assert((sum_size >> 16) == 0, "data size is bigger than 64Kb: 
>>> %d", sum_size);
>> 
>> I suggest using checked_cast for the assignment below, rather than 
>> special-purpose checks here.
>
> Okay. But I will put above code under `#ifdef ASSERT` then.

The ASSERT block above looks unnecessary, now that field assignments below are 
using checked_cast.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1569496753

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]

[Dean Long]

On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng  wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic 
>> candidate to its caller simplifies the intrinsic implementation in JIT 
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   address comment.

I think you'll want to ask port maintainers for aarch64/arm/ppc/riscv/s390 to 
review and test those changes.
There may be some opportunities for minor improvements, but those could be done 
later.  For example, we are computing `zlen` for the squareToLen stub even 
though the value is unused.  And both x86 and aarch64 seem to have unneeded 
save/restore code, even though I think all these registers are killed when 
called by a C2 runtime stub.

-

PR Comment: https://git.openjdk.org/jdk/pull/18226#issuecomment-2062138149

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]

[Dean Long]

On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng  wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic 
>> candidate to its caller simplifies the intrinsic implementation in JIT 
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   address comment.

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 6662:

> 6660:   push(tmp5);
> 6661: 
> 6662:   push(xlen);

There may be an opportunity here (separate RFE?) to get rid of the save/restore 
for these.  I don't think it's necessary if this is called as part of a C2 stub.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569452818

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]

[Dean Long]

On Wed, 17 Apr 2024 19:45:02 GMT, Dean Long  wrote:

>> Yudi Zheng has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   address comment.
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4702:
> 
>> 4700: const Register tmp5  = r15;
>> 4701: const Register tmp6  = r16;
>> 4702: const Register tmp7  = r17;
> 
> No need for r17 or sorting tmps.  Make tmp0 r3, or r6, r7, etc.

Also, I don't see why the code below saves and restores r4/r5.  Maybe 
@theRealAph knows?  Aren't all these registers killed across a runtime call?

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569427241

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]

[Dean Long]

On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng  wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic 
>> candidate to its caller simplifies the intrinsic implementation in JIT 
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   address comment.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4693:

> 4691: const Register xlen  = r1;
> 4692: const Register z = r2;
> 4693: const Register zlen  = r3;

LibraryCallKit::inline_squareToLen() is still computing zlen and passing it as 
the 4th arg, even though the value is unused.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4702:

> 4700: const Register tmp5  = r15;
> 4701: const Register tmp6  = r16;
> 4702: const Register tmp7  = r17;

No need for r17 or sorting tmps.  Make tmp0 r3, or r6, r7, etc.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569419199
PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569420732

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v5]

[Dean Long]

On Wed, 17 Apr 2024 12:35:54 GMT, Yudi Zheng  wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic 
>> candidate to its caller simplifies the intrinsic implementation in JIT 
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   address comment.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4670:

> 4668: const Register tmp5  = r15;
> 4669: const Register tmp6  = r16;
> 4670: const Register tmp7  = r17;

Why not minimize changes and continue to use r5 for tmp0?  I see no need for 
r17 or to reassign all the other tmp registers.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1569401544

[Cscwg-public] CSCWG Agenda April 18, 2024

[Dean Coclin via Cscwg-public]

MINUTE TAKER: NEED A VOLUNTEER, START RECORDING

 Bruce will run the meeting as I have a conflict this week

 

1.  Roll Call
2.  Antitrust reminder
3.  Approve prior meeting minutes - F2F  (Andrea), March 21st (Brianca),
April 4th (Scott)
4.  Proposed ballots: Remove EV Guideline References
5.  Proposed ballot for Time-stamp Requirements update; CSC-24
6.  Other business
7.  Next meeting - May 2nd  
8.  Adjourn

 

 

Dean Coclin 

CSCWG Chair

 

 

 

 

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public

Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS

[Dean Rasheed]

On Tue, 16 Apr 2024 at 11:35, Richard Guo  wrote:
>
> On Tue, Apr 16, 2024 at 5:48 PM Aleksander Alekseev 
>  wrote:
>>
>> Oversight of 0294df2f1f84 [1].
>>
>> [1]: 
>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=0294df2f1f84
>
> +1.  I think this change improves the code quality.  I searched for
> other arrays indexed by merge match kind, but found none.  So this patch
> seems thorough.
>

Yes this makes sense, though I note that some other similar code uses
a #define rather than inserting an enum element at the end (e.g.,
NUM_ROWFILTER_PUBACTIONS).

I guess the argument against inserting an enum element at the end is
that a switch statement on the enum value might generate a compiler
warning if it didn't have a default clause.

Looking at how NUM_ROWFILTER_PUBACTIONS is defined as the last element
plus one, it might seem to be barely any better than just defining it
to be 3, since any new enum element would probably be added at the
end, requiring it to be updated in any case. But if the number of
elements were much larger, it would be much more obviously correct,
making it a good general pattern to follow. So in the interests of
code consistency, I think we should do the same here.

Regards,
Dean

Re: RFR: 8329433: Reduce nmethod header size [v3]

[Dean Long]

On Tue, 16 Apr 2024 03:12:48 GMT, Vladimir Kozlov  wrote:

>> src/hotspot/share/code/nmethod.hpp line 282:
>> 
>>> 280:   _has_flushed_dependencies:1, // Used for maintenance of 
>>> dependencies (under CodeCache_lock)
>>> 281:   _is_unlinked:1,  // mark during class unloading
>>> 282:   _load_reported:1;// used by jvmti to track if an 
>>> event has been posted for this nmethod
>> 
>> It seems like the type could be changed from uint8_t to bool.
>
> Is there difference in generated code when you use bool instead of uint8_t?
> I used uint8_t to easy change to uint16_t in a future if needed.

I don't think uint8_t vs uint16_t matters, only if it is signed, unsigned, or 
bool.  So if we have more than 8 individual :1 fields, it will expand to a 2nd 
byte.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566814258

Re: RFR: 8329433: Reduce nmethod header size [v3]

[Dean Long]

On Tue, 16 Apr 2024 03:06:13 GMT, Vladimir Kozlov  wrote:

>> src/hotspot/share/code/nmethod.hpp line 205:
>> 
>>> 203:   // offsets to find the receiver for non-static native wrapper 
>>> frames.
>>> 204:   ByteSize _native_receiver_sp_offset;
>>> 205:   ByteSize _native_basic_lock_sp_offset;
>> 
>> Don't we need an assert in the accessor functions to make sure nmethod is 
>> native or not?
>
> I thought about that but in both places where these accessors are called 
> (`frame::get_native_monitor()` and `frame::get_native_receiver()`) there are 
> such asserts already:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/frame.cpp#L1085

OK, but I'd rather see it in the accessors too.  Some users are checking for 
method()->is_native() and others are checking for is_osr_method(), so we need 
to make sure those are always mutually exclusive: method()->is_native() != 
is_osr_method().

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566806754

Re: RFR: 8329433: Reduce nmethod header size [v3]

[Dean Long]

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/memory/heap.hpp line 58:

> 56:   void set_length(size_t length) {
> 57: LP64_ONLY( assert(((length >> 32) == 0), "sanity"); )
> 58: _header._length = (uint32_t)length;

Suggestion:

_header._length = checked_castlength;

src/hotspot/share/memory/heap.hpp line 63:

> 61:   // Accessors
> 62:   void* allocated_space() const  { return (void*)(this + 
> 1); }
> 63:   size_t length() const  { return 
> (size_t)_header._length; }

This cast looks unnecessary.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566784458
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566784587

Re: RFR: 8329433: Reduce nmethod header size [v3]

[Dean Long]

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/nmethod.cpp line 1441:

> 1439: int deps_size = align_up((int)dependencies->size_in_bytes(), 
> oopSize);
> 1440: int sum_size  = oops_size + metadata_size + deps_size;
> 1441: assert((sum_size >> 16) == 0, "data size is bigger than 64Kb: %d", 
> sum_size);

I suggest using checked_cast for the assignment below, rather than 
special-purpose checks here.

src/hotspot/share/code/nmethod.cpp line 1445:

> 1443: _metadata_offset  = (uint16_t)oops_size;
> 1444: _dependencies_offset  = _metadata_offset  + 
> (uint16_t)metadata_size;
> 1445: _scopes_pcs_offset= _dependencies_offset  + (uint16_t)deps_size;

Use checked_cast instead of raw casts.

src/hotspot/share/code/nmethod.cpp line 1459:

> 1457: assert((data_offset() + data_end_offset) <= nmethod_size, "wrong 
> nmethod's size: %d < %d", nmethod_size, (data_offset() + data_end_offset));
> 1458: 
> 1459: _entry_offset  = 
> (uint16_t)offsets->value(CodeOffsets::Entry);

Use checked_cast.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566771026
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566772567
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566773477

Re: RFR: 8329433: Reduce nmethod header size [v3]

[Dean Long]

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/nmethod.cpp line 1235:

> 1233: int skipped_insts_size   = 
> code_buffer->total_skipped_instructions_size();
> 1234: #ifdef ASSERT
> 1235: assert(((skipped_insts_size >> 16) == 0), "size is bigger than 
> 64Kb: %d", skipped_insts_size);

Suggestion:


I think it's simpler just to use checked_cast below.

src/hotspot/share/code/nmethod.cpp line 1240:

> 1238: int consts_offset = 
> code_buffer->total_offset_of(code_buffer->consts());
> 1239: assert(consts_offset == 0, "const_offset: %d", consts_offset);
> 1240: #endif

Suggestion:

src/hotspot/share/code/nmethod.cpp line 1241:

> 1239: assert(consts_offset == 0, "const_offset: %d", consts_offset);
> 1240: #endif
> 1241: _skipped_instructions_size = (uint16_t)skipped_insts_size;

Suggestion:

_skipped_instructions_size = 
checked_cast(code_buffer->total_skipped_instructions_size());

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566764300
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566765068
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566759786

Re: RFR: 8329433: Reduce nmethod header size [v3]

[Dean Long]

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/nmethod.hpp line 205:

> 203:   // offsets to find the receiver for non-static native wrapper 
> frames.
> 204:   ByteSize _native_receiver_sp_offset;
> 205:   ByteSize _native_basic_lock_sp_offset;

Don't we need an assert in the accessor functions to make sure nmethod is 
native or not?

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566634384

Re: RFR: 8329433: Reduce nmethod header size [v3]

[Dean Long]

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/nmethod.hpp line 282:

> 280:   _has_flushed_dependencies:1, // Used for maintenance of 
> dependencies (under CodeCache_lock)
> 281:   _is_unlinked:1,  // mark during class unloading
> 282:   _load_reported:1;// used by jvmti to track if an 
> event has been posted for this nmethod

It seems like the type could be changed from uint8_t to bool.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566631312

Re: RFR: 8329433: Reduce nmethod header size [v3]

[Dean Long]

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/codeBlob.cpp line 120:

> 118: 
> 119:   _header_size((uint16_t)header_size),
> 120:   _frame_complete_offset((int16_t)CodeOffsets::frame_never_safe),

See above.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566604310

Re: RFR: 8329433: Reduce nmethod header size [v3]

[Dean Long]

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov  wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` 
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 
>> 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some 
>> fields were changed from `int` to `int16_t` with added corresponding asserts 
>> to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/codeBlob.cpp line 88:

> 86:   S390_ONLY(_ctable_offset(0) COMMA)
> 87:   _header_size((uint16_t)header_size),
> 88:   _frame_complete_offset((int16_t)frame_complete_offset),

Rather than a raw cast, it would be better to use checked_cast here, or better 
yet, change the incoming parameter types to match the field type.  That way, if 
the caller is passing a constant, the compiler can check it at compile time.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566601934

[Kernel-packages] [Bug 2060919] Re: Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64).

[Dean Attewell]

Same issue on 6.5.0-1017-azure

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-hwe-6.5 in Ubuntu.
https://bugs.launchpad.net/bugs/2060919

Title:
  Remote filesystems mounted as CIFS not working after update to Kernel
  "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi
  #17-Ubuntu" (aarch64).

Status in linux package in Ubuntu:
  Confirmed
Status in linux-hwe-6.5 package in Ubuntu:
  Confirmed
Status in linux-raspi package in Ubuntu:
  Confirmed

Bug description:
  Remote filesystems mounted as CIFS are not working after update to
  Kernel "6.5.0-27-generic #28-Ubuntu" for x86_64 (and also after
  updating to Kernel "6.5.0-1014-raspi #17-Ubuntu" in aarch64).

  The remote filesystem is correctly mounted and seems to work but
  trying to write data to the filesystem ends in a kernel error
  exception. After that error the CIFS filesystem just became unusable.

  Previous Kernel version works correctly.

  =
  Example for Kernel "6.5.0-27-generic #28-Ubuntu" (x86_64)
  =
  # lsb_release -rd
  No LSB modules are available.
  Description:  Ubuntu 23.10
  Release:  23.10

  # uname -a
  Linux fpgmsi 6.5.0-27-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar  7 
18:21:00 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

  # cat /proc/version_signature
  Ubuntu 6.5.0-27.28-generic 6.5.13

  
  How to reproduce the problem
  
  For instance, I'm using KeePassXC 
(https://launchpad.net/ubuntu/+source/keepassxc) to update a database located 
at CIFS filesystem. Any change done to that database causes this Kernel error 
exception:

  abr 11 09:34:59 fpgmsi kernel: BUG: unable to handle page fault for address: 
fffe
  abr 11 09:34:59 fpgmsi kernel: #PF: supervisor read access in kernel mode
  abr 11 09:34:59 fpgmsi kernel: #PF: error_code(0x) - not-present page
  abr 11 09:34:59 fpgmsi kernel: PGD f45a3f067 P4D f45a3f067 PUD f45a41067 PMD 
0 
  abr 11 09:34:59 fpgmsi kernel: Oops:  [#1] PREEMPT SMP NOPTI
  abr 11 09:34:59 fpgmsi kernel: CPU: 0 PID: 28103 Comm: Thread (pooled) 
Tainted: P   OE  6.5.0-27-generic #28-Ubuntu
  abr 11 09:34:59 fpgmsi kernel: Hardware name: Micro-Star International Co., 
Ltd. MAG Z690 Codex X5 (MS-B930)/PRO Z690-A WIFI (MS-7D25), BIOS D.50 04/26/2022
  abr 11 09:34:59 fpgmsi kernel: RIP: 0010:cifs_flush_folio+0x41/0xf0 [cifs]
  abr 11 09:34:59 fpgmsi kernel: Code: 49 89 cd 31 c9 41 54 49 89 f4 48 c1 ee 
0c 53 48 83 ec 08 48 8b 7f 30 44 89 45 d4 e8 79 b3 23 f1 48 89 c3 31 c0 48 85 
db 74 77 <48> 8b 13 b8 00 10 00 00 f7 c2 00 00 01 00 74 10 0f b6 4b 51 48 d3
  abr 11 09:34:59 fpgmsi kernel: RSP: 0018:aab6865ffbf8 EFLAGS: 00010282
  abr 11 09:34:59 fpgmsi kernel: RAX:  RBX: fffe 
RCX: 
  abr 11 09:34:59 fpgmsi kernel: RDX:  RSI:  
RDI: 
  abr 11 09:34:59 fpgmsi kernel: RBP: aab6865ffc28 R08: 0001 
R09: 
  abr 11 09:34:59 fpgmsi kernel: R10: 00023854 R11:  
R12: 
  abr 11 09:34:59 fpgmsi kernel: R13: aab6865ffc78 R14: 906675d8aed0 
R15: aab6865ffc70
  abr 11 09:34:59 fpgmsi kernel: FS:  7bd4d594b6c0() 
GS:90753f80() knlGS:
  abr 11 09:34:59 fpgmsi kernel: CS:  0010 DS:  ES:  CR0: 
80050033
  abr 11 09:34:59 fpgmsi kernel: CR2: fffe CR3: 00017022a000 
CR4: 00750ef0
  abr 11 09:34:59 fpgmsi kernel: PKRU: 5554
  abr 11 09:34:59 fpgmsi kernel: Call Trace:
  abr 11 09:34:59 fpgmsi kernel:  
  abr 11 09:34:59 fpgmsi kernel:  ? show_regs+0x6d/0x80
  abr 11 09:34:59 fpgmsi kernel:  ? __die+0x24/0x80
  abr 11 09:34:59 fpgmsi kernel:  ? page_fault_oops+0x99/0x1b0
  abr 11 09:34:59 fpgmsi kernel:  ? kernelmode_fixup_or_oops+0xb2/0x140
  abr 11 09:34:59 fpgmsi kernel:  ? __bad_area_nosemaphore+0x1a5/0x2c0
  abr 11 09:34:59 fpgmsi kernel:  ? bad_area_nosemaphore+0x16/0x30
  abr 11 09:34:59 fpgmsi kernel:  ? do_kern_addr_fault+0x7b/0xa0
  abr 11 09:34:59 fpgmsi kernel:  ? exc_page_fault+0x1a4/0x1b0
  abr 11 09:34:59 fpgmsi kernel:  ? asm_exc_page_fault+0x27/0x30
  abr 11 09:34:59 fpgmsi kernel:  ? cifs_flush_folio+0x41/0xf0 [cifs]
  abr 11 09:34:59 fpgmsi kernel:  ? cifs_flush_folio+0x37/0xf0 [cifs]
  abr 11 09:34:59 fpgmsi kernel:  cifs_remap_file_range+0x172/0x660 [cifs]
  abr 11 09:34:59 fpgmsi kernel:  do_clone_file_range+0x101/0x2d0
  abr 11 09:34:59 fpgmsi kernel:  vfs_clone_file_range+0x3f/0x150
  abr 11 09:34:59 fpgmsi kernel:  ioctl_file_clone+0x52/0xc0
  abr 11 09:34:59 fpgmsi kernel:  do_vfs_ioctl+0x68f/0x910
  abr 11 09:34:59 fpgmsi kernel:  ? __fget_light+0xa5/0x120
  abr 11 09:34:59 fpgmsi kernel:  __x64_sys_ioctl+0x7d/0xf0
  abr 11 09:34:59 fpgmsi kernel:  

[Bug 2060919] Re: Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64).

[Dean Attewell]

Same issue on 6.5.0-1017-azure

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2060919

Title:
  Remote filesystems mounted as CIFS not working after update to Kernel
  "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi
  #17-Ubuntu" (aarch64).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060919/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Stus-List Re: Winch Sealant suggestions

[Dean McNeill via CnC-List]

Thanks for the great advice folks… Butyl tape (and nothing else) it is!
Dean

BarraWind
1980 C 34
Halifax NS

> On Apr 10, 2024, at 8:13 PM, Jeffrey A. Laman  wrote:
> 
> Butyl is by far the best option. Removal of winch in future will be far 
> easier. Butyl is an excellent sealant. There is no reason to overdo the 
> sealing here anyway. Leaks drip down to bilge without adversely affecting 
> anything.
> 
> Jeff Laman 
> 1981 C Harmony 
> Ludington, Mich
> 
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> From: Dean McNeill via CnC-List 
> Sent: Wednesday, April 10, 2024 5:42:22 PM
> To: Stus-List 
> Cc: Dean McNeill 
> Subject: Stus-List Winch Sealant suggestions
>  
> I mentioned a while back I was planning on replacing my old Barient primary 
> winches…. well I’ve got a pair of new Harken 46 ST’s ready to go. I’ve 
> removed the old winches, sealed the old holes, have starboard backing plates 
> (probably overkill) and I'm ready to go. 
> 
> Wondering what you folks suggest for sealing under new winches, between winch 
> base and fibreglass of cockpit? Old winches didn’t seem to have anything 
> other than a bit of Butyl Tape around and in the bolt holes.
> 
> Should I just do the same (appears to be solid fibreglass with no wood core 
> at all under the winches). I’ve thought of putting some 5200 under bases, but 
> I never like using that under something I may need to remove someday! Should 
> I use 4200? Or something else?
> 
> What says the C brain trust?
> 
> Thanks, Dean
> 
> BarraWind
> 1980 C 34
> Halifax NS
> Please show your appreciation for this list and the Photo Album site and help 
> me pay the associated bills.  Make a contribution at:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.paypal.me%2Fstumurray=05%7C02%7C%7C77d374048f38413585fc08dc59a72b03%7C84df9e7fe9f640afb435%7C1%7C0%7C638483821728002166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=QIGFZKY7gwts9Si0ie99atJGKvglYrLAXRbcVX8NaeI%3D=0
>  <https://www.paypal.me/stumurray>
> Thanks for your help.
> Stu

Please show your appreciation for this list and the Photo Album site and help 
me pay the associated bills.  Make a contribution at:
https://www.paypal.me/stumurray
Thanks for your help.
Stu

Stus-List Winch Sealant suggestions

[Dean McNeill via CnC-List]

I mentioned a while back I was planning on replacing my old Barient primary 
winches…. well I’ve got a pair of new Harken 46 ST’s ready to go. I’ve removed 
the old winches, sealed the old holes, have starboard backing plates (probably 
overkill) and I'm ready to go. 

Wondering what you folks suggest for sealing under new winches, between winch 
base and fibreglass of cockpit? Old winches didn’t seem to have anything other 
than a bit of Butyl Tape around and in the bolt holes.

Should I just do the same (appears to be solid fibreglass with no wood core at 
all under the winches). I’ve thought of putting some 5200 under bases, but I 
never like using that under something I may need to remove someday! Should I 
use 4200? Or something else?

What says the C brain trust?

Thanks, Dean

BarraWind
1980 C 34
Halifax NS
Please show your appreciation for this list and the Photo Album site and help 
me pay the associated bills.  Make a contribution at:
https://www.paypal.me/stumurray
Thanks for your help.
Stu

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v7]

[Dean Long]

On Mon, 8 Apr 2024 19:11:19 GMT, Scott Gibbons  wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See 
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around 
>> this change.
>> 
>> Overall, making this an intrinsic improves overall performance of 
>> `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and 
>> after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Add movq to locate_operand

Thanks, I see that my ideas have pretty much already been discussed in 
https://github.com/openjdk/jdk/pull/16760.  I might have missed it, but has the 
possibility of always setting the aligned interior region with 8 byte stores 
been discussed?  A literal reading of the javadoc seems to disallow it, but it 
seems like it should be allowed based on memory coherence.  Only the unaligned 
head and tail would need special treatment.

-

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2043732829

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v6]

[Dean Long]

On Sat, 6 Apr 2024 00:13:26 GMT, Scott Gibbons  wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See 
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around 
>> this change.
>> 
>> Overall, making this an intrinsic improves overall performance of 
>> `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and 
>> after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Oops

I went ahead and tried a pure-Java implementation, and it is faster for small 
sizes (up to 8) and only about 1.5x slower for larger sizes, so that might make 
for an interesting fallback if there is no customized assembler implementation 
available or if the size is known to me small.

Ideally, I think we would want C2 to be more aware of setMemory stores, so that 
it can remove redundant stores, like it does with InitializeNode.

-

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2041271472

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v4]

[Dean Long]

On Wed, 3 Apr 2024 15:15:24 GMT, Scott Gibbons  wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See 
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around 
>> this change.
>> 
>> Overall, making this an intrinsic improves overall performance of 
>> `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and 
>> after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix Windows

As an experiment, couldn't you have the C2 intrinsic redirect to a Java helper 
that calls putByte() in a loop?

-

PR Comment: https://git.openjdk.org/jdk/pull/18555#issuecomment-2038994043

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v4]

[Dean Long]

On Wed, 3 Apr 2024 15:15:24 GMT, Scott Gibbons  wrote:

>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64.  See 
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around 
>> this change.
>> 
>> Overall, making this an intrinsic improves overall performance of 
>> `Unsafe::setMemory` by up to 4x for all buffer sizes.
>> 
>> Tested with tier-1 (and full CI).  I've added a table of the before and 
>> after numbers for the JMH I ran (`MemorySegmentZeroUnsafe`).
>> 
>> [setMemoryBM.txt](https://github.com/openjdk/jdk/files/14808974/setMemoryBM.txt)
>
> Scott Gibbons has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix Windows

I think the right approach is to turn it into a loop in the IR, which I think 
is what Doug was implying.  That way C2 can do all its usual optimizations, 
like unrolling, vectorization, and redundant store elimination (if it is an 
on-heap primitive array that was just allocated, then there is no need to zero 
the parts that are being "set").

-

Changes requested by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18555#pullrequestreview-1981533209

AOO Writer - Line Spacing icons

[Dean W]

Dear all,

On my copy of AOO Writer the icons for 1.0 and 1.5 line spacing seem to be
transposed. I have 1.0, 1.5 and 2.0 line spacing in my toolbar, and the gap
for 1.5 (on the icon) is smaller than the gap for the 1.0 line spacing (on
the icon). Line spacing works as otherwise intended, except the icons seem
to be incorrect.

Here's the link to the picture, with the 1.5 line spacing selected,
https://imgur.com/1dOCi9U.png

Disregard if this does not appear on your systems.

AOO4111m1 / Linux x86_64

Thanks

[Cscwg-public] CSCWG Agenda April 4, 2024

[Dean Coclin via Cscwg-public]

Here's the draft agenda for this week's call:

 

MINUTE TAKER: NEED A VOLUNTEER, START RECORDING

 

1.  Roll Call
2.  Antitrust reminder
3.  Approve prior meeting minutes - F2F  (awaiting draft from Andrea),
March 21st (Brianca)
4.  Ballot status: Marking the EV CS guidelines obsolete (CSC-23). Do we
need an IPR review?
5.  Proposed ballots: Remove EV Guideline References
6.  Proposed ballot for Time-stamp Requirements update; CSC-24
7.  Continued discussion on Application for Associate Member status from
Keyfactor 
8.  Interested Party application from Wangmo Tenzing (as an individual)
9.  Other business
10. Next meeting - April 18th 
11. Adjourn

 

 

Dean Coclin 

CSCWG Chair



smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public

Re: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes

[Dean Long]

On Fri, 29 Mar 2024 19:35:45 GMT, Vladimir Kozlov  wrote:

> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE 
> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365)
>  which was used for AOT [JEP 295](https://openjdk.org/jeps/295) 
> implementation in JDK 9. The code was left in HotSpot assuming it will help 
> in a future. But during work on Leyden we decided to not use it. In Leyden 
> cached compiled code will be restored in CodeCache as normal nmethods: no 
> need to change VM's runtime and GC code to process them.
> 
> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce 
> header size in separate changes. In these changes I did simple fields 
> reordering to keep small (1 byte) fields together.
> 
> I do not see (and not expected) performance difference with these changes.
> 
> Tested tier1-5, xcomp, stress. Running performance testing.
> 
> I need help with testing on platforms which Oracle does not support.

The `not_used` state was introduced for AOT.  It can go away now.

-

PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2030282409

[kwin] [Bug 483229] Sometimes unable to bring background apps to the front while Chrome/Chromium is running

[Dean Hoover]

https://bugs.kde.org/show_bug.cgi?id=483229

--- Comment #10 from Dean Hoover  ---
> by any chance are you using a scale factor below 100%, and is Chrome/Chromium
running in native Wayland mode?

I am running native Wayland on the laptop, but the scale factor is set to
100% (it was originally set to 125% by the OS when I first installed it but
I changed it soon after).

I read the bug you listed.  Although my situation is with the scale factor
at 100% I will try to sneak some time to see if lowering/raising the factor
makes a dent.

Dean


On Mon, Apr 1, 2024 at 12:22 PM Nate Graham 
wrote:

> https://bugs.kde.org/show_bug.cgi?id=483229
>
> --- Comment #9 from Nate Graham  ---
> (In reply to Dean Hoover from comment #8)
> > Created attachment 167474 [details]
> > attachment-371693-0.html
> >
> > The only apps that I've been able to recreate this is Google Chrome and
> > UnGoogled Chromium.  I don't use any other Chromium-based browser, and it
> > doesn't seem to happen with Firefox.
> >
> > It's almost as if the browser believes that the window is larger than it
> > actually is.  For example, the browser window might be 800x1000 but it
> > tells the DE that it's 800x1050 so that if the mouse clicks between the
> > 1000 and 1050 the browser window becomes the foreground instead of the
> > actual app that they are trying to get to.
> Hmm... by any chance are you using a scale factor below 100%, and is
> Chrome/Chromium running in native Wayland mode? If so this sounds very much
> like Bug 477676.
>
> > Appreciate your time Nate.  I've been a UNIX and Linux server user and
> > administrator for almost 40 years, but every DE I've tried never worked
> > well enough for me.  KDE has changed my mind, and if it wasn't for a
> couple
> > Windows-only apps (Cisco ASDM, Teams' ability to take control of PC, etc)
> > I'd be 100% Linux and KDE for work and home.
> Thanks for the kind words! We try hard to make it a pleasant and productive
> environment. :)
>
> --
> You are receiving this mail because:
> You reported the bug.

-- 
You are receiving this mail because:
You are watching all bug changes.

pgsql: Add support for MERGE ... WHEN NOT MATCHED BY SOURCE.

[Dean Rasheed]

Add support for MERGE ... WHEN NOT MATCHED BY SOURCE.

This allows MERGE commands to include WHEN NOT MATCHED BY SOURCE
actions, which operate on rows that exist in the target relation, but
not in the data source. These actions can execute UPDATE, DELETE, or
DO NOTHING sub-commands.

This is in contrast to already-supported WHEN NOT MATCHED actions,
which operate on rows that exist in the data source, but not in the
target relation. To make this distinction clearer, such actions may
now be written as WHEN NOT MATCHED BY TARGET.

Writing WHEN NOT MATCHED without specifying BY SOURCE or BY TARGET is
equivalent to writing WHEN NOT MATCHED BY TARGET.

Dean Rasheed, reviewed by Alvaro Herrera, Ted Yu and Vik Fearing.

Discussion: 
https://postgr.es/m/CAEZATCWqnKGc57Y_JanUBHQXNKcXd7r=0r4nezuvwp+syrk...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/0294df2f1f842dfb0eed79007b21016f486a3c6c

Modified Files
--
doc/src/sgml/mvcc.sgml|  12 +-
doc/src/sgml/ref/merge.sgml   | 100 +--
src/backend/executor/execMain.c   |   6 +-
src/backend/executor/execPartition.c  |  21 +-
src/backend/executor/nodeModifyTable.c| 387 --
src/backend/nodes/nodeFuncs.c |   3 +
src/backend/optimizer/plan/createplan.c   |   8 +-
src/backend/optimizer/plan/planner.c  |  22 ++
src/backend/optimizer/plan/setrefs.c  |  20 +-
src/backend/optimizer/prep/prepjointree.c |  51 +++-
src/backend/optimizer/prep/preptlist.c|  26 +-
src/backend/optimizer/util/pathnode.c |   5 +-
src/backend/parser/gram.y |  62 +++--
src/backend/parser/parse_merge.c  |  56 ++--
src/backend/utils/adt/ruleutils.c |  41 ++-
src/bin/psql/tab-complete.c   |  30 +-
src/include/catalog/catversion.h  |   2 +-
src/include/nodes/execnodes.h |  15 +-
src/include/nodes/parsenodes.h|   7 +-
src/include/nodes/pathnodes.h |   2 +
src/include/nodes/plannodes.h |   2 +
src/include/nodes/primnodes.h |  10 +-
src/include/optimizer/pathnode.h  |   3 +-
src/include/parser/kwlist.h   |   2 +
src/test/isolation/expected/merge-update.out  |  88 --
src/test/isolation/specs/merge-update.spec|  10 +-
src/test/regress/expected/merge.out   | 299 +++-
src/test/regress/expected/rules.out   |  32 +++
src/test/regress/expected/updatable_views.out |  90 ++
src/test/regress/sql/merge.sql| 122 ++--
src/test/regress/sql/rules.sql|  19 ++
src/test/regress/sql/updatable_views.sql  |  32 +++
src/tools/pgindent/typedefs.list  |   1 +
33 files changed, 1226 insertions(+), 360 deletions(-)

XZ Utils Compromised Releases

[Frank Dean]

I received a security announcement on the Debian mailing list [1].  It appears 
versions 5.6.0 of XY Utils and later may be compromised.  I also found a 
discussion on Openwall [2].


[1]: https://lists.debian.org/debian-security-announce/2024/msg00057.html 


[2]: https://www.openwall.com/lists/oss-security/2024/03/29/4 



I'm afraid that's all I know.  Just a heads-up.

Re: Adding OLD/NEW support to RETURNING

[Dean Rasheed]

hat all that is probably reasonable, but it definitely needs
documenting, which I haven't attempted yet.

Overall, I'm pretty hesitant to try to commit this to v17. Aside from
the fact that there's a lot of new code that hasn't had much in the
way of review or discussion, I also feel that I probably haven't fully
considered all areas where additional complexity might arise. It
doesn't seem like that long ago that this was just a prototype, and
it's certainly not that long ago that I had to add a substantial
amount of new code to deal with the auto-updatable view case that I
had completely overlooked.

So on reflection, rather than trying to rush to get this into v17, I
think it would be better to leave it to v18.

Regards,
Dean

Re: Functions to return random numbers in a given range

[Dean Rasheed]

On Tue, 26 Mar 2024 at 06:57, Dean Rasheed  wrote:
>
> Based on the reviews so far, I think this is ready for commit, so
> unless anyone objects, I will do so in a day or so.
>

Committed. Thanks for the reviews.

Regards,
Dean

pgsql: Add functions to generate random numbers in a specified range.

[Dean Rasheed]

Add functions to generate random numbers in a specified range.

This adds 3 new variants of the random() function:

random(min integer, max integer) returns integer
random(min bigint, max bigint) returns bigint
random(min numeric, max numeric) returns numeric

Each returns a random number x in the range min <= x <= max.

For the numeric function, the number of digits after the decimal point
is equal to the number of digits that "min" or "max" has after the
decimal point, whichever has more.

The main entry points for these functions are in a new C source file.
The existing random(), random_normal(), and setseed() functions are
moved there too, so that they can all share the same PRNG state, which
is kept private to that file.

Dean Rasheed, reviewed by Jian He, David Zhang, Aleksander Alekseev,
and Tomas Vondra.

Discussion: 
https://postgr.es/m/caezatcv89vxuq93xqdmc0t-0y2zeenqtdsjbmv7dyfbpykb...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/e6341323a8da64b18e9af3e75a4578230702d61c

Modified Files
--
doc/src/sgml/func.sgml|  43 +++-
src/backend/utils/adt/Makefile|   1 +
src/backend/utils/adt/float.c |  95 
src/backend/utils/adt/meson.build |   1 +
src/backend/utils/adt/numeric.c   | 219 ++
src/backend/utils/adt/pseudorandomfuncs.c | 185 +++
src/common/pg_prng.c  |  36 +++
src/include/catalog/catversion.h  |   2 +-
src/include/catalog/pg_proc.dat   |  12 +
src/include/common/pg_prng.h  |   1 +
src/include/utils/numeric.h   |   4 +
src/test/regress/expected/random.out  | 360 ++
src/test/regress/sql/random.sql   | 164 ++
13 files changed, 1022 insertions(+), 101 deletions(-)

[Cscwg-public] Voting Results: Ballot CSC-23: Marking the EV Code Signing Guidelines SUPERCEDED

[Dean Coclin via Cscwg-public]

Voting has concluded on Ballot CSC-23 and the results are as follows:

 

Certificate Issuers:
Yes: 9

No: 0

Abstain: 0

Voting in favor: Actalis, Asseco (Certum), DigiCert, Entrust, Globalsign, 
HARICA, IdenTrust, Sectigo, SSL.com

 

 

Certificate Consumers:
Yes: 1

No: 0

Abstain: 0

Voting in favor: Microsoft

 

Quorum was met.


Therefore, the ballot passes.

 

Dean Coclin 

CSCWG Chair

 

 

 

 

From: Cscwg-public  On Behalf Of Dimitris 
Zacharopoulos (HARICA) via Cscwg-public
Sent: Tuesday, March 19, 2024 1:29 AM
To: cscwg-public@cabforum.org
Subject: [Cscwg-public] Voting Begins Ballot CSC-23: Marking the EV Code 
Signing Guidelines SUPERCEDED

 

Voting begins for ballot CSC-23.

Purpose of the Ballot

As agreed at the F2F#61 meeting, this is a ballot to mark the "Guidelines For 
The Issuance And Management Of Extended Validation Code Signing Certificates" 
as superceded. 

The following motion has been proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Scott Rea of eMudhra and Martijn Katerbarg of Sectigo.

MOTION BEGINS

Update the EVCS Guidelines v1.4 
<https://url.avanan.click/v2/___https:/cabforum.org/working-groups/code-signing/ev-code-signing-certificate-guidelines/___.YXAzOmRpZ2ljZXJ0OmE6bzpmNWE3YmVjN2QwODE4MzgyMGMyMmRiMDNkMzY5OTM1Yzo2OmQwM2Q6NjdkY2VmN2ZjNDZjMmFmMTliZTI1ODM4ODI2YWFjMjkzYzY0Zjc2OWQzZjYwNzhkZWQzZDhiMjFhMDVlMmMzMTpoOkY>
  to version 1.5 with the following changes:

In the "Notice to Readers" section, update the second paragraph to state:

"The Code Signing Working Group considers this document SUPERCEDED as of 
September 2, 2020. CAs SHOULD NOT use this standard but instead SHOULD use the 
"Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code 
Signing Certificates" that has incorporated and improved requirements related 
to Extended Validation (EV) Code Signing Certificates."

Update section 17.1 to state the following:

"As this document is marked SUPERCEDED, CAs SHOULD NOT be audited against this 
standard. "

MOTION ENDS

The procedure for this ballot is as follows:


Start time (8:00 UTC)

End time (8:00 UTC)


Discussion (at least 7 days)

2024-03-11

2024-03-18


Expected Vote for approval (7 days)

2024-03-19

2024-03-26

 



smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public

Re: Catalog domain not-null constraints

[Dean Rasheed]

On Tue, 26 Mar 2024 at 07:30, Alvaro Herrera  wrote:
>
> On 2024-Mar-25, Dean Rasheed wrote:
>
> > Also (not this patch's fault), psql doesn't seem to offer a way to
> > display domain constraint names -- something you need to know to drop
> > or alter them. Perhaps \dD+ could be made to do that?
>
> Ooh, I remember we had offered a patch for \d++ to display these
> constraint names for tables, but didn't get around to gather consensus
> for it.  We did gather consensus on *not* wanting \d+ to display them,
> but we need *something*.  I suppose we should do something symmetrical
> for tables and domains.  How about \dD++ and \dt++?
>

Personally, I quite like the fact that \d+ displays NOT NULL
constraints, because it puts them on an equal footing with CHECK
constraints. However, I can appreciate that it will significantly
increase the length of the output in some cases.

With \dD it's not so nice because of the way it puts all the details
on one line. The obvious output might look something like this:

\dD
   List of domains
 Schema | Name |  Type   | Collation | Nullable | Default |  Check
+--+-+---+--+-+---
 public | d1   | integer |   | NOT NULL | | CHECK (VALUE > 0)

\dD+
List of domains
 Schema | Name |  Type   | Collation | Nullable
| Default |Check  | Access privileges
| Description
+--+-+---+-+-+---+---+-
 public | d1   | integer |   | CONSTRAINT d1_not_null NOT NULL
| | CONSTRAINT d1_check CHECK (VALUE > 0) |
|

So you'd need quite a wide window to easily view it (or use \x). I
suppose the width could be reduced by dropping the word "CONSTRAINT"
in the \dD+ case, but it's probably still going to be wider than the
average window.

Regards,
Dean

Re: MERGE ... WHEN NOT MATCHED BY SOURCE

[Dean Rasheed]

On Thu, 21 Mar 2024 at 09:35, Dean Rasheed  wrote:
>
> Trivial rebase forced by 6185c9737c.
>

I think it would be good to get this committed.

It has had a decent amount of review, at least up to v9, but a number
of things have changed since then:

1). Concurrent update behaviour -- now if a concurrent update causes a
matched candidate row to no longer match the join condition, it will
execute the first qualifying NOT MATCHED BY SOURCE action, and then
the first qualifying NOT MATCHED [BY TARGET] action. I.e., it may
execute 2 actions, which makes sense because if the rows had started
out not matching, the full join would have output 2 rows.

2). ResultRelInfo now has 3 lists of actions, one per match kind.
Previously I was putting the NOT MATCHED BY SOURCE actions in the same
list as the MATCHED actions, since they are both handled by
ExecMergeMatched(). However, to achieve (1) above, it turned out to be
easier to have 3 separate lists, and this makes some other code a
little neater.

3). I've added a new field Query.mergeJoinCondition so that
transformMergeStmt() no longer puts the join conditions in
qry->jointree->quals. That's necessary to make it work correctly on an
auto-updatable view which might have its own quals, but it also seems
neater anyway.

4). To distinguish the MATCHED case from NOT MATCHED BY SOURCE case in
the executor, it now uses the join condition (previously it added a
"source IS [NOT] NULL" clause to each merge action). This has the
advantage that it involves just one qual check per candidate row,
rather than one for each action. On the downside, it's checking the
join condition twice (since the source subplan's join node already
checked it), but I couldn't see an easy way round that. (It only does
this if there are both MATCHED and NOT MATCHED BY SOURCE actions, so
it's not making any existing queries worse.)

5). To support (4), I added new fields
ModifyTablePath.mergeJoinConditions, ModifyTable.mergeJoinConditions
and ResultRelInfo.ri_MergeJoinCondition, since the attribute numbers
in the join condition might vary by partition.

6). I got rid of Query.mergeSourceRelation, which is no longer needed,
because of (4). (And as before, it also gets rid of
Query.mergeUseOuterJoin, since the parser is no longer making the
decision about what kind of join to build.)

7). To support (1), I added a new field
ModifyTableState.mt_merge_pending_not_matched, because if it has to
execute 2 actions following a concurrent update, and there is a
RETURNING clause, it has to defer the second action until the next
call to ExecModifyTable().

8). I've added isolation tests to test (1).

9). I've added a lot more regression tests.

10). I've made a lot of comment changes in nodeModifyTable.c,
especially relating to the discussion around concurrent updates.

Overall, I feel like this is in pretty good shape, and it manages to
make a few code simplifications that look quite nice.

Regards,
Dean

Re: Functions to return random numbers in a given range

[Dean Rasheed]

On Tue, 27 Feb 2024 at 17:33, Dean Rasheed  wrote:
>
> On Sat, 24 Feb 2024 at 17:10, Tomas Vondra
> >
> > I did a quick review and a little bit of testing on the patch today. I
> > think it's a good/useful idea, and I think the code is ready to go (the
> > code is certainly much cleaner than anything I'd written ...).
>

Based on the reviews so far, I think this is ready for commit, so
unless anyone objects, I will do so in a day or so.

As a quick summary, this adds a new file:

src/backend/utils/adt/pseudorandomfuncs.c

which contains SQL-callable functions that access a single shared
pseudorandom number generator, whose state is private to that file.
Currently the functions are:

  random() returns double precision [moved from float.c]
  random(min integer, max integer) returns integer  [new]
  random(min bigint, max bigint) returns bigint [new]
  random(min numeric, max numeric) returns numeric  [new]
  random_normal() returns double precision  [moved from float.c]
  setseed(seed double precision) returns void   [moved from float.c]

It's possible that functions to return other random distributions or
other datatypes might get added in the future, but I have no plans to
do so at the moment.

Regards,
Dean

Re: [Infrastructure] SC70 exclusion notice filled

[Dean Coclin via Infrastructure]

I think those conclusions have to come from the PAG and unfortunately, not
you. They may come to the same conclusions, but it’s better to be done that
way.

 

I would suggest convening a PAG post haste and work through the issues at
hand.


Dean 

 

 

 

 

 

From: Infrastructure  On Behalf Of
Inigo Barreira via Infrastructure
Sent: Monday, March 25, 2024 8:05 AM
To: Ben Wilson via Infrastructure 
Subject: [Infrastructure] SC70 exclusion notice filled

 

Hi all,

 

I´m sending this email to this group, knowing that this is maybe not the
right group to discuss this (I didn´t want to send it first to the
management list) but in where we have at least a lawyer (Ben) and an
“interested party” which could be Wayne as he´s listed in the patents even
not working now for GoDaddy.

 

The issue is, as you have read in the email sent to the public list, that an
exclusion notice has been filled against ballot SC70. And I have some
questions, some regarding the procedure and some others regarding the
exclusion notice itself and what we have in the wiki.

 

As per the bylaws, section 2.4, item 9 (emphasis mine):

 

1.  If Exclusion Notice(s) are filed during the Review Period (as
described in Section 4.3 of the IPR Policy), then the results of the Initial
Vote are automatically rescinded and deemed null and void, and;

a. A Patent Advisory Group (PAG) will be formed, in accordance with Section
7 of the IPR Policy, to address the conflict. The PAG will make a conclusion
as described in Section 7.3.2 of the IPR Policy, and communicate such
conclusion to the rest of the Forum, using the Member Mail List and the
Public Mail List; and

b. After the PAG provides its conclusion, if the proposer and endorsers
decide to proceed with the Draft Guidelines Ballot, and:

1.  The proposer and endorsers do not make any changes to the Draft
Guidelines Ballot, such ballot must go through the steps described in
Sections 2.4(2) through (4) above, replacing the “Initial Vote” with a
“Second Vote.” If a Draft Guidelines Ballot passes the Second Vote, then the
results of the Second Vote are deemed to be final and approved. Draft
Guidelines then become either Final Guidelines or Final Maintenance
Guidelines, as designated in the Draft Guidelines Ballot. The Chair will
notify the Public Mail List of the approval, as well as update the public
website of Final Guidelines and Final Maintenance Guidelines; or
2.  The proposer and endorsers make changes to the Draft Guidelines
Ballot, a new Draft Guidelines Ballot must be proposed, and must go through
the steps described in Sections 2.3(1) through (9) above.

So, independently of the exclusion notice, the ballot is considered null,
there´s no new TLS BRs version and a PAG need to be formed. I added this
topic to the WG call agenda for next Thursday (I won´t be running the call
because I´m on holidays for Easter) and I was going to send an email to the
SC public list indicating that the ballot is null (BTW, we don´t have any
kind of template to make such communication). Is this the right
interpretation of the bylaws?

OTOH, about the exclusion notice itself. This is what I´ve found that would
like to share.

*   This exclusion notice contains 7 patents

*   #1 (Method for a web site with a proxy domain name registration to
receive a secure socket layer certificate): Created in 2004 (there were no
BRs at that time), granted in 2010 and expires in 2017
*   #2 (Digital identity registration): Created in 2010, granted in 2011
and expires in 2027
*   #3 (Methods and systems for dynamic updates of digital certificates
via subscription): Created in 2004 (there were no BRs at that time), granted
in 2013 and expires in 2030
*   #4 (Website secure certificate status determination via partner
browser plugin): Created in 2010, granted in 2015 and expires in 2033
*   #5 (Systems for determining website secure certificate status via
partner browser plugin): Created in 2010, granted in 2015 and expires in
2033
*   #6 (Determining website secure certificate status via partner
browser plugin) : Created in 2015, granted in 2017 and expires in 2031
*   #7 (Method and system for managing secure custom domains): Created
in 2017, granted in 2018 and expires in 2037. This was initially filed and
assigned to Lantirn INC and later to the Bank of Canada. GoDaddy is not
listed anywhere.

*   All these 7 patents include a “no license granted” under column
License Grant Election Made
*   All of them make a reference to the EVGs, but ballot SC70 does not
touch the EVGs but the TLS BRs
*   In the wiki
<https://wiki.cabforum.org/books/forum/page/ipr-policy-exclusion-notices>
IPR Policy Exclusion N... | CABF Wiki (cabforum.org), there´re some
exclusion notices filled but:

*   Patent #1 declared in this PDF is already listed in the wiki but
with a slightly different number but under “willing to license” it says
“unstated”. 


 <https://wiki.cabforum.

Re: Catalog domain not-null constraints

[Dean Rasheed]

On Fri, 22 Mar 2024 at 08:28, jian he  wrote:
>
> On Thu, Mar 21, 2024 at 7:23 PM Peter Eisentraut  wrote:
> >
> > Hmm.  CREATE DOMAIN uses column constraint syntax, but ALTER DOMAIN uses
> > table constraint syntax.  Attached is a patch to try to sort this out.
>
> also you should also change src/backend/utils/adt/ruleutils.c?
>
> src6=# \dD
>   List of domains
>  Schema |Name |  Type   | Collation | Nullable | Default |
>  Check
> +-+-+---+--+-+--
>  public | domain_test | integer |   | not null | |
> CHECK (VALUE > 0) NOT NULL VALUE
> (1 row)
>
> probably change to CHECK (VALUE IS NOT NULL)

I'd say it should just output "NOT NULL", since that's the input
syntax that created the constraint. But then again, why display NOT
NULL constraints in that column at all, when there's a separate
"Nullable" column?

Also (not this patch's fault), psql doesn't seem to offer a way to
display domain constraint names -- something you need to know to drop
or alter them. Perhaps \dD+ could be made to do that?

+   The syntax NOT NULL in this command is a
+   PostgreSQL extension.  (A standard-conforming
+   way to write the same would be CHECK (VALUE IS NOT
+   NULL).  However, per ,
+   such constraints a best avoided in practice anyway.)  The
+   NULL constraint is a
+   PostgreSQL extension (see also ).

I didn't verify this, but I thought that according to the SQL
standard, only non-NULL values should be passed to CHECK constraints,
so there is no standard-conforming way to write a NOT NULL domain
constraint.

FWIW, I think NOT NULL domain constraints are a useful feature to
have, and I suspect that there are more people out there who use them
and like them, than who care what the SQL standard says. If so, I'm in
favour of allowing them to be named and managed in the same way as NOT
NULL table constraints.

+   processCASbits($5, @5, "CHECK",
+  NULL, NULL, >skip_validation,
+  >is_no_inherit, yyscanner);
+   n->initially_valid = !n->skip_validation;

+   /* no NOT VALID support yet */
+   processCASbits($3, @3, "NOT NULL",
+  NULL, NULL, NULL,
+  >is_no_inherit, yyscanner);
+   n->initially_valid = true;

NO INHERIT is allowed for domain constraints? What does that even mean?

There's something very wonky about this:

CREATE DOMAIN d1 AS int CHECK (value > 0) NO INHERIT; -- Rejected
ERROR:  check constraints for domains cannot be marked NO INHERIT

CREATE DOMAIN d1 AS int;
ALTER DOMAIN d1 ADD CHECK (value > 0) NO INHERIT; -- Allowed

CREATE DOMAIN d2 AS int NOT NULL NO INHERIT; -- Now allowed (used to
syntax error)

CREATE DOMAIN d3 AS int;
ALTER DOMAIN d3 ADD NOT NULL NO INHERIT; -- Allowed

Presumably all of those should be rejected in the grammar.

Regards,
Dean

Re: [Cscwg-public] Voting Begins Ballot CSC-23: Marking the EV Code Signing Guidelines SUPERCEDED

[Dean Coclin via Cscwg-public]

Reminder: Voting on this ballot ends tomorrow. We still need a vote from a 
Certificate Consumer.


Dean

 

 

 

 

From: Cscwg-public  On Behalf Of Dimitris 
Zacharopoulos (HARICA) via Cscwg-public
Sent: Tuesday, March 19, 2024 1:29 AM
To: cscwg-public@cabforum.org
Subject: [Cscwg-public] Voting Begins Ballot CSC-23: Marking the EV Code 
Signing Guidelines SUPERCEDED

 

Voting begins for ballot CSC-23.

Purpose of the Ballot

As agreed at the F2F#61 meeting, this is a ballot to mark the "Guidelines For 
The Issuance And Management Of Extended Validation Code Signing Certificates" 
as superceded. 

The following motion has been proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Scott Rea of eMudhra and Martijn Katerbarg of Sectigo.

MOTION BEGINS

Update the EVCS Guidelines v1.4 
<https://url.avanan.click/v2/___https:/cabforum.org/working-groups/code-signing/ev-code-signing-certificate-guidelines/___.YXAzOmRpZ2ljZXJ0OmE6bzpmNWE3YmVjN2QwODE4MzgyMGMyMmRiMDNkMzY5OTM1Yzo2OmQwM2Q6NjdkY2VmN2ZjNDZjMmFmMTliZTI1ODM4ODI2YWFjMjkzYzY0Zjc2OWQzZjYwNzhkZWQzZDhiMjFhMDVlMmMzMTpoOkY>
  to version 1.5 with the following changes:

In the "Notice to Readers" section, update the second paragraph to state:

"The Code Signing Working Group considers this document SUPERCEDED as of 
September 2, 2020. CAs SHOULD NOT use this standard but instead SHOULD use the 
"Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code 
Signing Certificates" that has incorporated and improved requirements related 
to Extended Validation (EV) Code Signing Certificates."

Update section 17.1 to state the following:

"As this document is marked SUPERCEDED, CAs SHOULD NOT be audited against this 
standard. "

MOTION ENDS

The procedure for this ballot is as follows:


Start time (8:00 UTC)

End time (8:00 UTC)


Discussion (at least 7 days)

2024-03-11

2024-03-18


Expected Vote for approval (7 days)

2024-03-19

2024-03-26

 



smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public

Re: [OMPI users] UFLM only works on a single node???

[Dean Anderson via users]

Also using IB.I tried with options—with-ft ulfm —mca pml ob1 —mca btl_tcp_if_include ib0 —mca btl tcp,sm,selfAnd still hangs.Build was just 5.0.2 (ulfm already on by default):—prefix=xx —with-ucx=pathtoucx1.15 —with-slurmSent from my iPhoneOn Mar 24, 2024, at 2:00 PM, George Bosilca  wrote:All the examples work for me on using ULFM ge87f595 compiled with minimalistic options:'--prefix=XXX --enable-picky --enable-debug --disable-heterogeneous --enable-contrib-no-build=vt --enable-mpirun-prefix-by-default --enable-mpi-ext=ftmpi --with-ft=mpi --with-pmi'.I run using ipoib, so I select the sm,self, tcp BTL and the OB1 PML.  George.On Sat, Mar 23, 2024 at 6:33 PM Dean Anderson via users <users@lists.open-mpi.org> wrote:If someone could take a look at https://github.com/open-mpi/ompi/issues/11404
and provide some guidance or a work around, I’d appreciate it.

The SC-22 Tutorials work just fine, but only on a single node.  If you arrange multiple nodes, it hangs in MPI_Finalize.

I attended the SC22 Tutorial and it was not my impression that UFLM only worked if your tasks were all on a single node.



Thanks!!


Sent from my iPhone

Stus-List Re: Hints on swapping winches?

[Dean McNeill via CnC-List]

Thanks everyone, some great hints and suggestions here. 

I’m a little less worried about the switch after reading all these comments. 
I’ll be sure to let you all know how it works out!

Cheers, Dean

Barrawind
1980 C 34
Halifax, NS
_

Please show your appreciation for this list and the Photo Album site and help 
me pay the associated bills.  Make a contribution at:
https://www.paypal.me/stumurray
Thanks for your help.
Stu

[OMPI users] UFLM only works on a single node???

[Dean Anderson via users]

If someone could take a look at https://github.com/open-mpi/ompi/issues/11404
and provide some guidance or a work around, I’d appreciate it.

The SC-22 Tutorials work just fine, but only on a single node.  If you arrange 
multiple nodes, it hangs in MPI_Finalize.

I attended the SC22 Tutorial and it was not my impression that UFLM only worked 
if your tasks were all on a single node.



Thanks!!


Sent from my iPhone

Stus-List Hints on swapping winches?

[Dean McNeill via CnC-List]

I'm about to finally replace my old 2 speed Barient 25 primary winches on my 
C 34, with Harken 46 Self tailing winches. 
Anyone have experience doing a similar swap? I fully expect I’ll need to fill 
old holes and drill new ones. And probably glass in aluminum or plywood backing 
plates.

Any other hints and tips?

Thanks, Dean
BarraWind
1980 C 34
Halifax, NS 

 
Please show your appreciation for this list and the Photo Album site and help 
me pay the associated bills.  Make a contribution at:
https://www.paypal.me/stumurray
Thanks for your help.
Stu

Re: Issue with tomcat version of GWT 2.11 for class javax.validation.Path

[Dean Zarras]

For whatever it might be worth...

I just went through a possibly similar exercise, getting my 2.11 
GWT-RPC-based app to run with Tomcat 10. I had to run around my codebase 
and replace 'javax' with 'jakarta', but the last key step was ensuring that 
my GWTRPC services inherited from this class:  
com.google.gwt.user.server.rpc.*jakarta*.RemoteServiceServlet

Note the .jakarta. in there, which otherwise is not present (in javax form) 
in the older/other class hierarchy -- a different package entirely.

Also note, my project is not using 'validation-api.jar' directly (not sure 
about indirectly), so I can't promise the above will help -- sorry.


On Wednesday, March 20, 2024 at 5:45:24 AM UTC-4 Priya wrote:

> Hi Team,
>
> We are working on development environment with Tomcat 10 where third party 
> jar  *jakarta.validation-api.jar *has been updated to tomcat specific 
> version where package structure is changed from javax.validation to 
> jakarta.validation.
>
> When GWT 2.11 with tomcat specific jars(Gwt-servlet and 
> requestfactory-server.jar) are deployed, it is trying to find 
> javax.validation.Path with below stack trace-
>
> Exception while dispatching incoming RPC call 
> java.lang.NoClassDefFoundError: javax/validation/Path
>  java.base/java.lang.Class.forName(Class.java:467)
>   at 
> com.google.gwt.user.server.rpc.SerializationPolicyLoader.loadFromStream(SerializationPolicyLoader.java:217)
>   at 
> com.google.gwt.user.server.rpc.jakarta.RemoteServiceServlet.loadSerializationPolicy(RemoteServiceServlet.java:98)
>   at 
> com.google.gwt.user.server.rpc.jakarta.RemoteServiceServlet.doGetSerializationPolicy(RemoteServiceServlet.java:437)
>   at 
> com.google.gwt.user.server.rpc.jakarta.RemoteServiceServlet.getSerializationPolicy(RemoteServiceServlet.java:251)
>   at 
> com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.prepareToRead(ServerSerializationStreamReader.java:505)
>   at com.google.gwt.user.server.rpc.jakarta.RPC.decodeRequest(RPC.java:241)
>
> As this package has been changed in our environment to 
> jakarta.validation.path, GWT source code is unable to find this class, 
> giving NoClassDefFoundError. 
>
> Also we can find several references of javax.validation.Path in gwt-user 
> and other jars under GWT 2.11 jars.
>
> My queries are  -
> 1. Has anyone come across such error, if yes, what is workaround. 
> 2. as javax packages are outdated and replaced by jakarta, is there a plan 
> to update them and what is significance of those classes .Also, how this 
> failure can be addressed. 
> 3. One solution I could see for older releases, is to add dependency for 
> gwt-servlet-deps.jar, but that is not viable solution to us,as we are 
> moving away from javax packages due to tomcat upgrade.
>
> Any immediate help will be appreciated. 
> Thanks!
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/f9db97be-397f-4bfe-a13a-de001fdcd311n%40googlegroups.com.

Re: Catalog domain not-null constraints

[Dean Rasheed]

On Wed, 20 Mar 2024 at 09:43, Peter Eisentraut  wrote:
>
> On 19.03.24 10:57, jian he wrote:
> > this new syntax need to be added into the alter_domain.sgml's synopsis and 
> > also
> > need an explanation varlistentry?
>
> The ALTER DOMAIN reference page refers to CREATE DOMAIN about the
> details of the constraint syntax.  I believe this is still accurate.  We
> could add more detail locally on the ALTER DOMAIN page, but that is not
> this patch's job.  For example, the details of CHECK constraints are
> also not shown on the ALTER DOMAIN page right now.
>

Hmm, for CHECK constraints, the ALTER DOMAIN syntax for adding a
constraint is the same as for CREATE DOMAIN, but that's not the case
for NOT NULL constraints. So, for example, these both work:

CREATE DOMAIN d AS int CONSTRAINT c1 CHECK (value > 0);

ALTER DOMAIN d ADD CONSTRAINT c2 CHECK (value < 10);

However, for NOT NULL constraints, the ALTER DOMAIN syntax differs
from the CREATE DOMAIN syntax, because it expects "NOT NULL" to be
followed by a column name. So the following CREATE DOMAIN syntax
works:

CREATE DOMAIN d AS int CONSTRAINT nn NOT NULL;

but the equivalent ALTER DOMAIN syntax doesn't work:

ALTER DOMAIN d ADD CONSTRAINT nn NOT NULL;

ERROR:  syntax error at or near ";"
LINE 1: ALTER DOMAIN d ADD CONSTRAINT nn NOT NULL;
 ^

All the examples in the tests append "value" to this, presumably by
analogy with CHECK constraints, but it looks as though anything works,
and is simply ignored:

ALTER DOMAIN d ADD CONSTRAINT nn NOT NULL xxx; -- works

That doesn't seem particularly satisfactory. I think it should not
require (and reject) a column name after "NOT NULL".

Looking in the SQL spec, it seems to only mention adding CHECK
constraints to domains, so the option to add NOT NULL constraints
should probably be listed in the "Compatibility" section.

Regards,
Dean

Re: Proposal to include --exclude-extension Flag in pg_dump

[Dean Rasheed]

On Tue, 19 Mar 2024 at 19:17, Ayush Vatsa  wrote:
>
> > I'm marking this ready-for-commit (which I'll probably do myself in a
> > day or two, unless anyone else claims it first).
>
> Thank you very much, this marks my first contribution to the open-source 
> community, and I'm enthusiastic about making further meaningful contributions 
> to PostgreSQL in the future.
>

Committed. Congratulations on your first contribution to PostgreSQL!
May it be the first of many to come.

Regards,
Dean

pgsql: Add "--exclude-extension" to pg_dump's options.

[Dean Rasheed]

Add "--exclude-extension" to pg_dump's options.

This option (or equivalently specifying "exclude extension pattern" in
a filter file) allows extensions matching the specified pattern to be
excluded from the dump.

Ayush Vatsa, reviewed by Junwang Zhao, Dean Rasheed, and Daniel
Gustafsson.

Discussion: 
https://postgr.es/m/CACX+KaP=VgVy9h-EUh598DTu+-fNr1jyEmpghC8rRp9s=w3...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/522ed12f7c600243870b13d9ff59f8fd5af10978

Modified Files
--
doc/src/sgml/ref/pg_dump.sgml   | 34 +--
src/bin/pg_dump/pg_dump.c   | 33 ++-
src/test/modules/test_pg_dump/t/001_base.pl | 88 ++---
3 files changed, 139 insertions(+), 16 deletions(-)

Re: Improving EXPLAIN's display of SubPlan nodes

[Dean Rasheed]

On Tue, 19 Mar 2024 at 21:40, Tom Lane  wrote:
>
> I'm inclined to leave that alone.  The actual source sub-SELECT
> could only have had one column, so no real confusion is possible.
> Yeah, there's a resjunk grouping column visible in the plan as well,
> but those exist in many other queries, and we've not gotten questions
> about them.
>

Fair enough. I have no further comments.

Regards,
Dean

Re: Improving EXPLAIN's display of SubPlan nodes

[Dean Rasheed]

On Tue, 19 Mar 2024 at 16:42, Tom Lane  wrote:
>
> Here's a hopefully-final version that makes that adjustment and
> tweaks a couple of comments.
>

This looks very good to me.

One final case that could possibly be improved is this one from aggregates.out:

explain (verbose, costs off)
select array(select sum(x+y) s
from generate_series(1,3) y group by y order by s)
  from generate_series(1,3) x;
QUERY PLAN
---
 Function Scan on pg_catalog.generate_series x
   Output: ARRAY(SubPlan 1)
   Function Call: generate_series(1, 3)
   SubPlan 1
 ->  Sort
   Output: (sum((x.x + y.y))), y.y
   Sort Key: (sum((x.x + y.y)))
   ->  HashAggregate
 Output: sum((x.x + y.y)), y.y
 Group Key: y.y
 ->  Function Scan on pg_catalog.generate_series y
   Output: y.y
   Function Call: generate_series(1, 3)

ARRAY operates on a SELECT with a single targetlist item, but in this
case it looks like the subplan output has 2 columns, which might
confuse people.

I wonder if we should output "ARRAY((SubPlan 1).col1)" to make it
clearer. Since ARRAY_SUBLINK is a special case, which always collects
the first column's values, we could just always output "col1" for
ARRAY.

Regards,
Dean

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v2]

[Dean Long]

On Tue, 19 Mar 2024 19:06:36 GMT, Yudi Zheng  wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic 
>> candidate to its caller simplifies the intrinsic implementation in JIT 
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   address comment.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4670:

> 4668: const Register tmp6  = r15;
> 4669: const Register tmp7  = r16;
> 4670: const Register tmp8  = r17;

It looks like tmp8 is never used.  The call to multiply_to_len() below needs to 
be adjusted.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1530986811

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic [v2]

[Dean Long]

On Tue, 19 Mar 2024 19:06:36 GMT, Yudi Zheng  wrote:

>> Moving array construction within BigInteger.implMultiplyToLen intrinsic 
>> candidate to its caller simplifies the intrinsic implementation in JIT 
>> compiler.
>
> Yudi Zheng has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   address comment.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 3559:

> 3557:  Register tmp5, Register tmp6, 
> Register product_hi, Register tmp8) {
> 3558: 
> 3559:   assert_different_registers(x, xlen, y, ylen, z, tmp1, tmp2, tmp3, 
> tmp4, tmp5, tmp6, tmp8);

Suggestion:

  assert_different_registers(x, xlen, y, ylen, z, tmp1, tmp2, tmp3, tmp4, tmp5, 
tmp6, tmp8, product_hi);

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1530980566

[kwin] [Bug 483229] Sometimes unable to bring background apps to the front while Chrome/Chromium is running

[Dean Hoover]

https://bugs.kde.org/show_bug.cgi?id=483229

--- Comment #8 from Dean Hoover  ---
The only apps that I've been able to recreate this is Google Chrome and
UnGoogled Chromium.  I don't use any other Chromium-based browser, and it
doesn't seem to happen with Firefox.

It's almost as if the browser believes that the window is larger than it
actually is.  For example, the browser window might be 800x1000 but it
tells the DE that it's 800x1050 so that if the mouse clicks between the
1000 and 1050 the browser window becomes the foreground instead of the
actual app that they are trying to get to.

Unless you think this still might be a KDE issue, I think you can close
this ticket.  I also submitted feedback to Google but I honestly don't
think they will say or do anything about it.  And now that I have a better
grasp of where and when it happens, I can adjust the way I do things to
mitigate the issue.

Appreciate your time Nate.  I've been a UNIX and Linux server user and
administrator for almost 40 years, but every DE I've tried never worked
well enough for me.  KDE has changed my mind, and if it wasn't for a couple
Windows-only apps (Cisco ASDM, Teams' ability to take control of PC, etc)
I'd be 100% Linux and KDE for work and home.

Keep up the great work!
Dean


On Mon, Mar 18, 2024 at 5:00 PM Nate Graham 
wrote:

> https://bugs.kde.org/show_bug.cgi?id=483229
>
> Nate Graham  changed:
>
>What|Removed |Added
>
> 
> Summary|Unable to click background  |Sometimes unable to bring
>|app/window to foreground|background apps to the
>|using mouse |front while
> Chrome/Chromium
>||is running
>
> --- Comment #7 from Nate Graham  ---
> Thanks. From those screen recordings, it looks like the problem only
> happens
> while Chrome/Chromium is running, and when it happens, it seemingly
> randomly
> affects all kinds of apps and not just Chrome/Chromium itself, right?
>
> --
> You are receiving this mail because:
> You reported the bug.

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: Proposal to include --exclude-extension Flag in pg_dump

[Dean Rasheed]

On Sat, 16 Mar 2024 at 17:36, Ayush Vatsa  wrote:
>
> Attached is the complete patch with all the required code changes.
> Looking forward to your review and feedback.
>

This looks good to me. I tested it and everything worked as expected.

I ran it through pgindent to fix some whitespace issues and added
another test for the filter option, based on the test case you added.

I'm marking this ready-for-commit (which I'll probably do myself in a
day or two, unless anyone else claims it first).

Regards,
Dean
From f757ebe748ab47d1e1ab40b343af2a43a9183287 Mon Sep 17 00:00:00 2001
From: Ayush Vatsa 
Date: Mon, 25 Dec 2023 14:46:05 +0530
Subject: [PATCH v3] Add support for --exclude-extension in pg_dump

When specified, extensions matching the given pattern are excluded
in dumps.
---
 doc/src/sgml/ref/pg_dump.sgml   | 34 ++--
 src/bin/pg_dump/pg_dump.c   | 33 +++-
 src/test/modules/test_pg_dump/t/001_base.pl | 88 ++---
 3 files changed, 139 insertions(+), 16 deletions(-)

diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index 0caf56e0e0..8edf03a03d 100644
--- a/doc/src/sgml/ref/pg_dump.sgml
+++ b/doc/src/sgml/ref/pg_dump.sgml
@@ -256,6 +256,27 @@ PostgreSQL documentation
   
  
 
+ 
+  --exclude-extension=pattern
+  
+   
+Do not dump any extensions matching pattern.  The pattern is
+interpreted according to the same rules as for -e.
+--exclude-extension can be given more than once to exclude extensions
+matching any of several patterns.
+   
+
+   
+When both -e and --exclude-extension are given, the behavior
+is to dump just the extensions that match at least one -e
+switch but no --exclude-extension switches.  If --exclude-extension
+appears without -e, then extensions matching --exclude-extension are
+excluded from what is otherwise a normal dump.
+   
+  
+ 
+
  
   -E encoding
   --encoding=encoding
@@ -848,10 +869,11 @@ PostgreSQL documentation
 --exclude-table-and-children or
 -T for tables,
 -n/--schema for schemas,
---include-foreign-data for data on foreign servers and
+--include-foreign-data for data on foreign servers,
 --exclude-table-data,
---exclude-table-data-and-children for table data,
--e/--extension for extensions.
+--exclude-table-data-and-children for table data, and
+-e/--extension or
+--exclude-extension for extensions.
 To read from STDIN, use - as the
 filename.  The --filter option can be specified in
 conjunction with the above listed options for including or excluding
@@ -874,8 +896,7 @@ PostgreSQL documentation
  
   
extension: extensions, works like the
-   --extension option. This keyword can only be
-   used with the include keyword.
+   -e/--extension option.
   
  
  
@@ -1278,7 +1299,8 @@ PostgreSQL documentation


 This option has no effect
-on -N/--exclude-schema,
+on --exclude-extension,
+-N/--exclude-schema,
 -T/--exclude-table,
 or --exclude-table-data.  An exclude pattern failing
 to match any objects is not considered an error.
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index a5149ca823..3ab7c6676a 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -136,6 +136,9 @@ static SimpleOidList foreign_servers_include_oids = {NULL, NULL};
 static SimpleStringList extension_include_patterns = {NULL, NULL};
 static SimpleOidList extension_include_oids = {NULL, NULL};
 
+static SimpleStringList extension_exclude_patterns = {NULL, NULL};
+static SimpleOidList extension_exclude_oids = {NULL, NULL};
+
 static const CatalogId nilCatalogId = {0, 0};
 
 /* override for standard extra_float_digits setting */
@@ -437,6 +440,7 @@ main(int argc, char **argv)
 		{"exclude-table-data-and-children", required_argument, NULL, 14},
 		{"sync-method", required_argument, NULL, 15},
 		{"filter", required_argument, NULL, 16},
+		{"exclude-extension", required_argument, NULL, 17},
 
 		{NULL, 0, NULL, 0}
 	};
@@ -672,6 +676,11 @@ main(int argc, char **argv)
 read_dump_filters(optarg, );
 break;
 
+			case 17:			/* exclude extension(s) */
+simple_string_list_append(_exclude_patterns,
+		  optarg);
+break;
+
 			default:
 /* getopt_long already emitted a complaint */
 pg_log_error_hint("Try \"%s --help\" for more information.", progname);
@@ -890,6 +899,10 @@ main(int argc, char **argv)
 		if (extension_include_oids.head == NULL)
 			pg_fatal("no matching extensions were found");
 	}
+	expand_extension_name_patterns(fout, _exclude_patterns,
+   _exclude_oids,
+   false

Re: Improving EXPLAIN's display of SubPlan nodes

[Dean Rasheed]

On Mon, 18 Mar 2024 at 23:19, Tom Lane  wrote:
>
> > Hm.  I used "rescan(SubPlan)" in the attached, but it still looks
> > a bit odd to my eye.
>
> After thinking a bit more, I understood what was bothering me about
> that notation: it looks too much like a call of a user-defined
> function named "rescan()".  I think we'd be better off with the
> all-caps "RESCAN()".
>

Or perhaps move the parentheses, and write "(rescan SubPlan N)" or
"(reset SubPlan N)". Dunno.

Regards,
Dean

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic

[Dean Long]

On Tue, 12 Mar 2024 10:44:54 GMT, Yudi Zheng  wrote:

> Moving array construction within BigInteger.implMultiplyToLen intrinsic 
> candidate to its caller simplifies the intrinsic implementation in JIT 
> compiler.

src/hotspot/share/opto/library_call.cpp line 5934:

> 5932: // 'y_start' points to y array + scaled ylen
> 5933: 
> 5934: Node* zlen = _gvn.transform(new AddINode(xlen, ylen));

Would could generate one less instruction in the code cache if we did this 
`add` in the native runtime function.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/18226#discussion_r1529102070

Re: Improving EXPLAIN's display of SubPlan nodes

[Dean Rasheed]

On Sun, 17 Mar 2024 at 19:39, Tom Lane  wrote:
>
> Here's a cleaned-up version that seems to successfully resolve
> PARAM_EXEC references in all cases.  I haven't changed the
> "(plan_name).colN" notation, but that's an easy fix once we have
> consensus on the spelling.

I took a more detailed look at this and the code and doc changes all
look good to me.

There's a comment at the end of find_param_generator() that should
probably say "No generator found", rather than "No referent found".

The get_rule_expr() code could perhaps be simplified a bit, getting
rid of the show_subplan_name variable and moving the recursive calls
to get_rule_expr() to after the switch statement -- if testexpr is
non-NULL, print it, else print the subplan name probably works for all
subplan types.

The "colN" notation has grown on me, especially when you look at
examples like those in partition_prune.out with a mix of Param types.
Not using "$n" for 2 different purposes is good, and I much prefer
this to the original "FROM [HASHED] SubPlan N (returns ...)" notation.

> There are two other loose ends bothering me:
>
> 1.  I see that Gather nodes sometimes print things like
>
>->  Gather (actual rows=N loops=N)
>  Workers Planned: 2
>  Params Evaluated: $0, $1
>  Workers Launched: N
>
> I propose we nuke the "Params Evaluated" output altogether.

+1

> 2.  MULTIEXPR_SUBLINK subplans now result in EXPLAIN output like
>
>->  Result
>  Output: (SubPlan 1).col1, (SubPlan 1).col2, (SubPlan 1), i.tableoid, 
> i.ctid
>
> The undecorated reference to (SubPlan 1) is fairly confusing, since
> it doesn't correspond to anything that will actually get output.
> I suggest that perhaps instead this should read
>
>  Output: (SubPlan 1).col1, (SubPlan 1).col2, IGNORE(SubPlan 1), 
> i.tableoid, i.ctid
>
> or
>
>  Output: (SubPlan 1).col1, (SubPlan 1).col2, RESET(SubPlan 1), 
> i.tableoid, i.ctid

I think "RESET()" or "RESCAN()" or something like that is better than
"INGORE()", because it indicates that it is actually doing something.
I don't really have a better idea. Perhaps not all uppercase though,
since that seems to go against the rest of the EXPLAIN output.

Regards,
Dean

Re: MERGE ... RETURNING

[Dean Rasheed]

On Fri, 15 Mar 2024 at 17:14, Jeff Davis  wrote:
>
> On Fri, 2024-03-15 at 11:20 +, Dean Rasheed wrote:
>
> > So barring any further objections, I'd like to go ahead and get this
> > patch committed.
>
> I like this feature from a user perspective. So +1 from me.
>

I have committed this. Thanks for all the feedback everyone.

Regards,
Dean

[Cscwg-public] CSCWG Agenda March 21, 2024

[Dean Coclin via Cscwg-public]

Here's the draft agenda for this week's call:

 

MINUTE TAKER: NEED A VOLUNTEER, START RECORDING

 

1.  Roll Call
2.  Antitrust reminder
3.  Approve prior meeting minutes - F2F  (awaiting draft as of March 17)
4.  Proposed ballots: Remove EV Guideline References and marking the EV
CS guidelines obsolete (CSC-23)
5.  Proposed ballot for Time-stamp Requirements update.
6.  Application for full membership from Identrust (included in MS Root
store per Ian)
7.  Application for Associate Member status from Keyfactor 
8.  Other business
9.  Next meeting - April 4th 
10. Adjourn

 

 

Dean Coclin 

CSCWG Chair



smime.p7s
Description: S/MIME cryptographic signature
___
Cscwg-public mailing list
Cscwg-public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/cscwg-public