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)
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
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
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
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
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
> 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
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
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
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,
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
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
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
> 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
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
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
16 matches
Mail list logo