Query on VLAN on Linux DSA ports

2024-10-21 Thread SIMON BABY
Hello Team, Can I know what is the best way of implementing VLAN on linux DSA user ports ? I would like to know if I can go with VLAN interface or VLAN filtering on bridge interface. I am using Marvel DSA (88E6390) running on Linux 6.1 kernel. Below is my requirement. eth0 (conduit interface)

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-21 Thread Weijun Wang
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-21 Thread Kevin Walls
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-21 Thread Sean Mullan
On Sat, 19 Oct 2024 07:54:07 GMT, Alan Bateman wrote: > There are a couple of micro benchmarks in test/micro that fork with > `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be > examined. Fixed, will be in next drop. There are a couple of other micro tests that test th

Re: RFR: 8342075: HttpClient: improve HTTP/2 flow control checks

2024-10-21 Thread Andrey Turbanov
On Thu, 17 Oct 2024 16:33:47 GMT, Daniel Fuchs wrote: > Please find here a fix that improves flow control in the HTTP/2 > implementation. > > The change makes sure that flow control issues are reported to the server as > FLOW_CONTROL_ERROR. > It also clarify how some system properties that all

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-21 Thread Phil Race
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8342075: HttpClient: improve HTTP/2 flow control checks [v2]

2024-10-21 Thread Daniel Fuchs
> Please find here a fix that improves flow control in the HTTP/2 > implementation. > > The change makes sure that flow control issues are reported to the server as > FLOW_CONTROL_ERROR. > It also clarify how some system properties that allow to initialize flow > control windows are handled, by

Re: RFR: 8342075: HttpClient: improve HTTP/2 flow control checks

2024-10-21 Thread Daniel Fuchs
On Thu, 17 Oct 2024 16:33:47 GMT, Daniel Fuchs wrote: > Please find here a fix that improves flow control in the HTTP/2 > implementation. > > The change makes sure that flow control issues are reported to the server as > FLOW_CONTROL_ERROR. > It also clarify how some system properties that all

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-21 Thread Daniel Fuchs
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-21 Thread Weijun Wang
On Fri, 18 Oct 2024 19:52:35 GMT, Sean Mullan wrote: >> I assume for the second one above you mean >> `javax.security.auth.kerberos.ServicePermission`. These classes still have a >> lot of words like "grant" and "trust". I will make some changes to the >> class descriptions of those classes,

Re: RFR: 8342682: Errors related to unused code on Windows after 8339120

2024-10-21 Thread Julian Waters
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote: > After 8339120, gcc began catching many different instances of unused code in > the Windows specific codebase. Some of these seem to be bugs. I've taken the > effort to mark out all the relevant globals and locals that trigger the > unuse

RFR: 8342682: Errors related to unused code on Windows after 8339120

2024-10-21 Thread Julian Waters
After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code a

Re: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v2]

2024-10-21 Thread Daniel Fuchs
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security >> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The >> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the >> main ch

Re: RFR: 8305406: Add @spec tags in java.base/java.* (part 2) [v2]

2024-10-21 Thread Hannes Wallnöfer
> Please review a doc update to add `@spec` tags to crypto and security APIs in > `java.base`. > > This was authored and proposed as #13336 by @jonathan-gibbons as part of > [JDK-8296546] back in 2023, but although it was reviewed and approved it > never was integrated. Since I can't reopen Jo

Re: RFR: 8342682: Errors related to unused code on Windows after 8339120

2024-10-21 Thread David Holmes
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote: > and whatever team is responsible for HotSpot debugging. I don't see anything hotspot related here. I think you would be better off splitting this up into distinct issues and PRs for different areas. I expect the client team in particular

Re: RFR: 8342682: Errors related to unused code on Windows after 8339120

2024-10-21 Thread Julian Waters
On Tue, 22 Oct 2024 01:40:11 GMT, David Holmes wrote: > > and whatever team is responsible for HotSpot debugging. > > I don't see anything hotspot related here. > > I think you would be better off splitting this up into distinct issues and > PRs for different areas. I expect the client team in