On Wed, 2019-03-13 at 09:16 +0100, Thomas Monjalon wrote: > 13/03/2019 09:02, Jerin Jacob Kollanukkaran: > > On Tue, 2019-03-12 at 21:33 +0100, Thomas Monjalon wrote: > > > 12/03/2019 20:25, Jerin Jacob Kollanukkaran: > > > > On Fri, 2019-03-01 at 18:28 +0100, Thomas Monjalon wrote: > > > > > 01/03/2019 18:05, Ferruh Yigit: > > > > > > On 10/11/2017 3:33 PM, jerin.jacob at caviumnetworks.com > > > > > > (Jerin > > > > > > Jacob) wrote: > > > > > > > From: Thomas Monjalon <thomas at monjalon.net> > > > > > > > > 07/08/2017 14:04, Jerin Jacob: > > > > > > > > > baremetal execution environments may have a different > > > > > > > > > method to enable RTE_INIT instead of using compiler > > > > > > > > > constructor scheme. Move RTE_INIT* definition under > > > > > > > > > exec-env to support different execution environments. > > > > > > > > > > > > > > > > > > Signed-off-by: Jerin Jacob <jerin.jacob at > > > > > > > > > caviumnetworks.com> > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > I am not sure there is a real desire to make DPDK > > > > > ready for bare-metal (back again). > > > > > If any of you are aware of a real use-case, we can re- > > > > > consider. > > > > > > > > Some of the usecases: > > > > > > > > # PCIe endpoint mode aka Smart NIC(Where DPDK runs on PCIe > > > > card), > > > > May > > > > not need to waste one core for Linux. Specially Smart NIC > > > > market > > > > has > > > > less number of cores. > > > > On the endpoint side, It treats as FW so customer may not have > > > > access > > > > to so nobdoy cares it is Linux or baremetal so may need to > > > > waste > > > > one > > > > core for Linux > > > > > > > > # VM case, it possible to have bare metal guest just to save > > > > one a > > > > logical core for Linux > > > > > > > > # Some of the RTOS like Zephyr already provide TCP/IP stack and > > > > good > > > > subsystems for specific usecases. > > > > > > > > # We are using DPDK for pre silicon validation for SoC mode. > > > > Bringing > > > > up linux on emulator takes ages, Baremetal can be used for > > > > Harware > > > > verification too. > > > > > > > > > > > > IMO, As long as it not limiting the a feature of Linux app, Why > > > > not > > > > to > > > > allow baremetal? I agree with code duplication. I think, it can > > > > be > > > > fixed easily, Other than that, Is there any concern? > > > > > > The concern is about the effort required. > > > Which libc to use? Which dependency is acceptable? > > > > # It should be like FreeBSD or Windows EAL port(Where changes > > should be > > in lib/librte_eal/xxxxxx/) > > # Baremetal libc can be newlibc or musl. > > # IMO, If bare metal code is open source then the dependency does > > not > > matter > > # if RTOS supports POSIX wrappers, the common code changes will be > > very > > minimal. > > # In house, We have baremetal support as PoC, where 95% of changes > > are > > in lib/librte_eal/xxxxxx/ with POSIX wrappers. > > Then maybe you should send your patches so we can decide if it is > maintainable enough or not.
The __attribute__((constructor)) only stuff we have issue to support. The common code changes are related to adapt __attribute__((constructor)) scheme. This patch will fix that issue. Other than that there is no common code changes.i.e everything emulated under lib/librte_eal/new_port/ > >
