The notes below are not complete and will be update in the next few days.

= Planning code obsolesce =

- Hard to find obsolete code
- Hard to find users of old code
- We could remove used features and still keep unused code

- Proposal to document state of obsolete hardware

- How do we define "obsolete hardware"?

- Aren't we going to have "feature-removal-schedule" back again?

- Votes are to have Documentation/absolute

= Kprobes Jump Optimizations =

- kprobes has OPTPROBES only for 3 architectures (of 24)

- optimized jump provides lower overhead and reduces number of exceptions required for a breakpoint

- hard to implement optprobes on certain architectures due to limited range of branch instructions

- suggested optprobe optimization for RISC-V and c-sky

- suggested ISA idea for optprobes

= Cross-architecture collaboration =

- Reduce amount of code duplication between architectures

- New architecture review often asks for some new generalization to be part of the effort.

- Getting people to do something generic rather than specific to an architecture can be hard when it causes extra work. How to motivate architecture maintainers  - Takes someone to start the work / provide infrastructure.
  - There has to be incentive to convert it over. Sometimes a 'we will not support alternatives'.

-  People don't think about generic in the first place. Sometimes it isn't obvious something is generic until later. Sometime user ABI has been introduced at this stage.

- Switching away from a tried-and-tested/mature architecture-specific implementation to a new generic implementation is not necessarily a no-brainer as it can introduce user-visible regressions and generally cause the arch maintainer extra work, which they are unlikely to be paid to handle (hey, it worked fine before!)

- Which architectures are "important"? Do we want a set of primary and secondary architectures?

- Possible primary architectures: x86-64, arm64, ppc64, risc-v64, arm32, s390, mips

= unified vDSO =

- Extending the Unified vDSOs to more syscalls raises some questions:
    - Which information do we want to make accessible via vDSO?
    - Are those private to a process?
    - Is there a risk if another process accesses them?
    - Exposing private information requires a per process page instead of a global one•If we keep global vDSOdata pages what is the best approach a per-thread one or a per-cpu one?
    - Shall we make the vDSOdata pages writable?

- per-thread VDSO or per-cpu VDSO

- unclear whether that the performance advantage of saving syscall overhead outweighs the cost of remapping per-cpu pages of the memory overhead of per-thread pages

= Generic functionality for system call and trap entry and exit =

- arm64 has differences that became ABI, need to be accommodated by the generic code

- powerpc consider switching as well

- arm32 is hesitant

= 4G/4G memory split on 32-bit architectures =

- Linux divides virtual address space to 3G for user and 1G for kernel