Re: CVS commit: src/sys/rump/librump/rumpnet
Le 01/03/2018 à 04:50, m...@netbsd.org a écrit : On Tue, Feb 27, 2018 at 02:45:43PM +, Maxime Villard wrote: Oops, forgot this file; I just merged two IPsec functions, so adapt the rump stubs accordingly. .. __weak_alias(esp6_ctlinput,rumpnet_stub); __weak_alias(ipsec4_output,rumpnet_stub); __weak_alias(ipsec4_common_input,rumpnet_stub); -__weak_alias(ipsec4_delete_pcbpolicy,rumpnet_stub); __weak_alias(ipsec4_forward,rumpnet_stub); __weak_alias(ipsec4_input,rumpnet_stub); __weak_alias(ipsec4_set_policy,rumpnet_stub); __weak_alias(ipsec6_common_input,rumpnet_stub); __weak_alias(ipsec6_input,rumpnet_stub); __weak_alias(ipsec6_check_policy,rumpnet_stub); -__weak_alias(ipsec6_delete_pcbpolicy,rumpnet_stub); -__weak_alias(ipsec6_get_policy,rumpnet_stub); __weak_alias(ipsec6_process_packet,rumpnet_stub); __weak_alias(ipsec6_set_policy,rumpnet_stub); +__weak_alias(ipsec_get_policy,rumpnet_stub); +__weak_alias(ipsec_delete_pcbpolicy,rumpnet_stub); __weak_alias(ipsec_hdrsiz,rumpnet_stub); __weak_alias(ipsec_in_reject,rumpnet_stub); __weak_alias(ipsec_init_policy,rumpnet_stub); For a normal library I assume this would require a major bump. do we do this for rump? I don't know.
Re: CVS commit: src/sys/dev
If you're going to #include an opt_*.h file, perhaps you ought to embed that within #ifdef _KERNEL_OPT In the distant future, if/when acpi becomes a module, it will get built in an environment that does not include the opt_*.h files (all needed macros such as NPCI get supplied via CPPFLAGS in the module's Makefile). :) On Thu, 1 Mar 2018, Masanobu SAITOH wrote: On 2018/03/01 14:04, m...@netbsd.org wrote: On Wed, Feb 28, 2018 at 05:50:06AM +, SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Wed Feb 28 05:50:06 UTC 2018 Modified Files: src/sys/dev/acpi: acpi_mcfg.c src/sys/dev/pci: pci_quirks.c pcivar.h Log Message: - Add new PCI quirk PCI_QUIRK_HASEXTCNF and PCI_QUIRK_NOEXTCNF. Some devices' extended configuration area may be broken or violate spec. If an extended configuration space is strange but it really exist, use PCI_QUIRK_HASEXTCNF. If an extended configuration space is plausible to exist but it really doesn't exist, use PCI_QUIRK_NOEXTCNF. - Add PCI_PRODUCT_INTEL_XEOND_MEM_0_TTR_1(0x6fa8) and PCI_PRODUCT_INTEL_COREI76K_IMC_0(0x6f68) with PCI_QUIRK_HASEXTCNF. The document clearly states they violate spec and it support the extended configuration space. this is causing ia64 builds to fail. they have acpi, but not pci defined. then, pci_quirks.c is not built, and we get an undefined reference: http://releng.netbsd.org/builds/HEAD/201802282130Z/ia64.build.failed acpi_mcfg.c sounds like a very pci-only thing, from commit history. the following patch makes it explicitly a pci only thing, although I haven't tried to boot it. Is this the right thing? IMHO, it would be OK. With this change, I can build amd64 and ia64 kernels. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org) !DSPAM:5a97918b157948785462255! +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: CVS commit: src/sys/dev
On 2018/03/01 14:04, m...@netbsd.org wrote: On Wed, Feb 28, 2018 at 05:50:06AM +, SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Wed Feb 28 05:50:06 UTC 2018 Modified Files: src/sys/dev/acpi: acpi_mcfg.c src/sys/dev/pci: pci_quirks.c pcivar.h Log Message: - Add new PCI quirk PCI_QUIRK_HASEXTCNF and PCI_QUIRK_NOEXTCNF. Some devices' extended configuration area may be broken or violate spec. If an extended configuration space is strange but it really exist, use PCI_QUIRK_HASEXTCNF. If an extended configuration space is plausible to exist but it really doesn't exist, use PCI_QUIRK_NOEXTCNF. - Add PCI_PRODUCT_INTEL_XEOND_MEM_0_TTR_1(0x6fa8) and PCI_PRODUCT_INTEL_COREI76K_IMC_0(0x6f68) with PCI_QUIRK_HASEXTCNF. The document clearly states they violate spec and it support the extended configuration space. this is causing ia64 builds to fail. they have acpi, but not pci defined. then, pci_quirks.c is not built, and we get an undefined reference: http://releng.netbsd.org/builds/HEAD/201802282130Z/ia64.build.failed acpi_mcfg.c sounds like a very pci-only thing, from commit history. the following patch makes it explicitly a pci only thing, although I haven't tried to boot it. Is this the right thing? IMHO, it would be OK. With this change, I can build amd64 and ia64 kernels. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: CVS commit: src/sys/dev
On Wed, Feb 28, 2018 at 05:50:06AM +, SAITOH Masanobu wrote: > Module Name: src > Committed By: msaitoh > Date: Wed Feb 28 05:50:06 UTC 2018 > > Modified Files: > src/sys/dev/acpi: acpi_mcfg.c > src/sys/dev/pci: pci_quirks.c pcivar.h > > Log Message: > - Add new PCI quirk PCI_QUIRK_HASEXTCNF and PCI_QUIRK_NOEXTCNF. Some devices' > extended configuration area may be broken or violate spec. If an extended > configuration space is strange but it really exist, use PCI_QUIRK_HASEXTCNF. > If an extended configuration space is plausible to exist but it really > doesn't exist, use PCI_QUIRK_NOEXTCNF. > - Add PCI_PRODUCT_INTEL_XEOND_MEM_0_TTR_1(0x6fa8) and > PCI_PRODUCT_INTEL_COREI76K_IMC_0(0x6f68) with PCI_QUIRK_HASEXTCNF. The > document clearly states they violate spec and it support the extended > configuration space. > > this is causing ia64 builds to fail. they have acpi, but not pci defined. then, pci_quirks.c is not built, and we get an undefined reference: http://releng.netbsd.org/builds/HEAD/201802282130Z/ia64.build.failed acpi_mcfg.c sounds like a very pci-only thing, from commit history. the following patch makes it explicitly a pci only thing, although I haven't tried to boot it. Is this the right thing? With this change, I can build amd64 and ia64 kernels. Index: dev/acpi/acpi.c === RCS file: /cvsroot/src/sys/dev/acpi/acpi.c,v retrieving revision 1.265 diff -u -r1.265 acpi.c --- dev/acpi/acpi.c 23 Nov 2017 15:48:24 - 1.265 +++ dev/acpi/acpi.c 1 Mar 2018 04:57:44 - @@ -103,6 +103,7 @@ __KERNEL_RCSID(0, "$NetBSD: acpi.c,v 1.265 2017/11/23 15:48:24 jmcneill Exp $"); #include "opt_acpi.h" +#include "opt_pci.h" #include "opt_pcifixup.h" #include @@ -487,10 +488,12 @@ */ acpi_build_tree(sc); +#ifdef NPCI /* * Probe MCFG table */ acpimcfg_probe(sc); +#endif acpi_md_callback(sc); Index: dev/acpi/files.acpi === RCS file: /cvsroot/src/sys/dev/acpi/files.acpi,v retrieving revision 1.100 diff -u -r1.100 files.acpi --- dev/acpi/files.acpi 10 Dec 2017 16:51:30 - 1.100 +++ dev/acpi/files.acpi 1 Mar 2018 04:57:44 - @@ -19,7 +19,7 @@ file dev/acpi/acpi.c acpi file dev/acpi/acpi_debug.c acpi file dev/acpi/acpi_i2c.c acpi -file dev/acpi/acpi_mcfg.cacpi +file dev/acpi/acpi_mcfg.cacpi & pci file dev/acpi/acpi_pci.c acpi file dev/acpi/acpi_pci_link.cacpi file dev/acpi/acpi_power.c acpi
Re: CVS commit: src/sys/rump/librump/rumpnet
On Tue, Feb 27, 2018 at 02:45:43PM +, Maxime Villard wrote: > Oops, forgot this file; I just merged two IPsec functions, so adapt > the rump stubs accordingly. .. > __weak_alias(esp6_ctlinput,rumpnet_stub); > __weak_alias(ipsec4_output,rumpnet_stub); > __weak_alias(ipsec4_common_input,rumpnet_stub); > -__weak_alias(ipsec4_delete_pcbpolicy,rumpnet_stub); > __weak_alias(ipsec4_forward,rumpnet_stub); > __weak_alias(ipsec4_input,rumpnet_stub); > __weak_alias(ipsec4_set_policy,rumpnet_stub); > __weak_alias(ipsec6_common_input,rumpnet_stub); > __weak_alias(ipsec6_input,rumpnet_stub); > __weak_alias(ipsec6_check_policy,rumpnet_stub); > -__weak_alias(ipsec6_delete_pcbpolicy,rumpnet_stub); > -__weak_alias(ipsec6_get_policy,rumpnet_stub); > __weak_alias(ipsec6_process_packet,rumpnet_stub); > __weak_alias(ipsec6_set_policy,rumpnet_stub); > +__weak_alias(ipsec_get_policy,rumpnet_stub); > +__weak_alias(ipsec_delete_pcbpolicy,rumpnet_stub); > __weak_alias(ipsec_hdrsiz,rumpnet_stub); > __weak_alias(ipsec_in_reject,rumpnet_stub); > __weak_alias(ipsec_init_policy,rumpnet_stub); > For a normal library I assume this would require a major bump. do we do this for rump?
