On Tue, 8 Aug 2023 11:19:12 -0700 Tyler Retzlaff <roret...@linux.microsoft.com> wrote:
> On Tue, Aug 08, 2023 at 10:35:07AM -0700, Stephen Hemminger wrote: > > Since 23.11 is an LTS release it is time to remove the experimental > > bandaid off many API's. There are about 850 API's marked with experimental > > on current main branch. This addresses the easy to remove ones and > > gets it down to about 690 places. > > > > The rule is any API that has been in since 22.11 needs to have > > experimental removed (or deleted). The experimental flag is not a > > "get out of ABI stability for free" card. > > For the libraries here that are enabled for Windows are the APIs being > marked stable have real implementations or just stubs on Windows? > > If they are just stubs then i think more review is necessary for the > stubbed APIs to understand that they *can* be implemented on Windows. > > I would prefer not to have to encounter this later and have to go > through the overhead of deprecation like with rte_thread_ctrl_create > again. > > This obviously doesn't apply to libraries that are not currently enabled > for Windows. If the implementations aren't stubs then that's okay too. I don't see any stubs when looking. bpf: not built on Windows. Needs some libelf. pdump: not built on Windows. Needs bpf for filtering rte_tm: ok rte_mtr: ok cmdline: ok pcapng: ok net: ok rcu: ok lpm: ok mbuf: ok hash: ok timer: ok dmadev: ok meter: ok power: not on windows, probably need special API's kvargs: ok ip_frag: ok member: not build on windows, not sure why security: ok vhost: not build on windows, not sure why regexdev: not build on windows, not sure why node: not build on windows, not sure why Changes to eal need to be more selective.
