svn commit: r266575 - in stable/10/sys/dev/usb: . controller

[Hans Petter Selasky]

Author: hselasky
Date: Fri May 23 06:20:25 2014
New Revision: 266575
URL: http://svnweb.freebsd.org/changeset/base/266575

Log:
  MFC r265358, r265427, r265777, r265783,
   r265806, r265872, r266012 and r266394:
  
  - Multiple DWC OTG host mode related fixes, improvements and optimisations.
  - Add full support for ISOCHRONOUS transfers to the DWC OTG driver.
  - Use the interrupt filter to handle basic USB FIFO interrupts.
  - Fixed unbalanced unlock in case of dwc_otg_init_fifo() failure.
  - Add common spinlock to the USB bus structure.

Modified:
  stable/10/sys/dev/usb/controller/dwc_otg.c
  stable/10/sys/dev/usb/controller/dwc_otg.h
  stable/10/sys/dev/usb/controller/dwc_otg_atmelarm.c
  stable/10/sys/dev/usb/controller/dwc_otg_fdt.c
  stable/10/sys/dev/usb/controller/dwc_otgreg.h
  stable/10/sys/dev/usb/controller/usb_controller.c
  stable/10/sys/dev/usb/usb_bus.h
  stable/10/sys/dev/usb/usb_core.h
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/sys/dev/usb/controller/dwc_otg.c
==
--- stable/10/sys/dev/usb/controller/dwc_otg.c  Fri May 23 05:35:43 2014
(r266574)
+++ stable/10/sys/dev/usb/controller/dwc_otg.c  Fri May 23 06:20:25 2014
(r266575)
@@ -89,19 +89,22 @@
((struct dwc_otg_softc *)(((uint8_t *)(bus)) - \
 ((uint8_t *)(((struct dwc_otg_softc *)0)-sc_bus
 
-#defineDWC_OTG_PC2SC(pc) \
-   DWC_OTG_BUS2SC(USB_DMATAG_TO_XROOT((pc)-tag_parent)-bus)
+#defineDWC_OTG_PC2UDEV(pc) \
+   (USB_DMATAG_TO_XROOT((pc)-tag_parent)-udev)
 
 #defineDWC_OTG_MSK_GINT_ENABLED\
-   (GINTSTS_ENUMDONE | \
-   GINTSTS_USBRST |\
-   GINTSTS_USBSUSP |   \
-   GINTSTS_IEPINT |\
-   GINTSTS_RXFLVL |\
-   GINTSTS_SESSREQINT |\
+   (GINTMSK_ENUMDONEMSK |  \
+   GINTMSK_USBRSTMSK | \
+   GINTMSK_USBSUSPMSK |\
+   GINTMSK_IEPINTMSK | \
+   GINTMSK_SESSREQINTMSK | \
GINTMSK_OTGINTMSK | \
-   GINTMSK_HCHINTMSK | \
-   GINTSTS_PRTINT)
+   GINTMSK_PRTINTMSK)
+
+#defineDWC_OTG_MSK_GINT_THREAD_IRQ \
+   (GINTSTS_USBRST | GINTSTS_ENUMDONE | GINTSTS_PRTINT |   \
+   GINTSTS_WKUPINT | GINTSTS_USBSUSP | GINTMSK_OTGINTMSK | \
+   GINTSTS_SESSREQINT)
 
 static int dwc_otg_use_hsic;
 
@@ -138,8 +141,9 @@ static dwc_otg_cmd_t dwc_otg_host_data_r
 static void dwc_otg_device_done(struct usb_xfer *, usb_error_t);
 static void dwc_otg_do_poll(struct usb_bus *);
 static void dwc_otg_standard_done(struct usb_xfer *);
-static void dwc_otg_root_intr(struct dwc_otg_softc *sc);
-static void dwc_otg_interrupt_poll(struct dwc_otg_softc *sc);
+static void dwc_otg_root_intr(struct dwc_otg_softc *);
+static void dwc_otg_interrupt_poll(struct dwc_otg_softc *);
+static void dwc_otg_host_channel_disable(struct dwc_otg_softc *, uint8_t);
 
 /*
  * Here is a configuration that the chip supports.
@@ -179,59 +183,81 @@ dwc_otg_init_fifo(struct dwc_otg_softc *
 
fifo_size = sc-sc_fifo_size;
 
-   fifo_regs = 4 * (sc-sc_dev_ep_max + sc-sc_dev_in_ep_max);
+   /*
+* NOTE: Reserved fixed size area at end of RAM, which must
+* not be allocated to the FIFOs:
+*/
+   fifo_regs = 4 * 16;
 
-   if (fifo_size = fifo_regs)
-   fifo_size -= fifo_regs;
-   else
-   fifo_size = 0;
+   if (fifo_size  fifo_regs) {
+   DPRINTF(Too little FIFO\n);
+   return (EINVAL);
+   }
+
+   /* subtract FIFO regs from total once */
+   fifo_size -= fifo_regs;
 
/* split equally for IN and OUT */
fifo_size /= 2;
 
-   DWC_OTG_WRITE_4(sc, DOTG_GRXFSIZ, fifo_size / 4);
-
-   /* align to 4-bytes */
+   /* align to 4 bytes boundary */
fifo_size = ~3;
 
+   /* set global receive FIFO size */
+   DWC_OTG_WRITE_4(sc, DOTG_GRXFSIZ, fifo_size / 4);
+
tx_start = fifo_size;
 
-   if (fifo_size  0x40) {
+   if (fifo_size  64) {
DPRINTFN(-1, Not enough data space for EP0 FIFO.\n);
-   USB_BUS_UNLOCK(sc-sc_bus);
return (EINVAL);
}
 
+   /* disable any leftover host channels */
+   for (x = 0; x != sc-sc_host_ch_max; x++) {
+   if (sc-sc_chan_state[x].wait_sof == 0)
+   continue;
+   dwc_otg_host_channel_disable(sc, x);
+   }
+
if (mode == DWC_MODE_HOST) {
 
/* reset active endpoints */
sc-sc_active_rx_ep = 0;
 
+   /* split equally for periodic and non-periodic */
fifo_size /= 2;
 
+   /* align to 4 bytes boundary */
+   fifo_size = ~3;
+
DWC_OTG_WRITE_4(sc, DOTG_GNPTXFSIZ,
   

svn commit: r266576 - stable/10/sys/modules/sound/sound

[Hans Petter Selasky]

Author: hselasky
Date: Fri May 23 06:28:31 2014
New Revision: 266576
URL: http://svnweb.freebsd.org/changeset/base/266576

Log:
  MFC r265359 and r265780:
  Remove ISA load dependency for the kernel sound
  driver module for ARM and MIPS.

Modified:
  stable/10/sys/modules/sound/sound/Makefile
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/sys/modules/sound/sound/Makefile
==
--- stable/10/sys/modules/sound/sound/Makefile  Fri May 23 06:20:25 2014
(r266575)
+++ stable/10/sys/modules/sound/sound/Makefile  Fri May 23 06:28:31 2014
(r266576)
@@ -44,7 +44,8 @@ CLEANFILES+=  feeder_eq_gen.h feeder_rate
 
 EXPORT_SYMS=   YES # XXX evaluate
 
-.if ${MACHINE_CPUARCH} == sparc64 || ${MACHINE_CPUARCH} == powerpc
+.if ${MACHINE_CPUARCH} != i386  ${MACHINE_CPUARCH} != amd64  \
+${MACHINE_CPUARCH} != ia64  ${MACHINE_CPUARCH} != pc98
 # Create an empty opt_isa.h in order to keep kmod.mk from linking in an
 # existing one from KERNBUILDDIR which possibly has DEV_ISA defined so
 # sound.ko is always built without isadma support.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r266577 - stable/10/sys/dev/usb/wlan

[Hans Petter Selasky]

Author: hselasky
Date: Fri May 23 06:35:45 2014
New Revision: 266577
URL: http://svnweb.freebsd.org/changeset/base/266577

Log:
  MFC r266466, r266471, r266484, r266505, r266535 and r266542:
  Fix multiple issues in the RSU driver.

Modified:
  stable/10/sys/dev/usb/wlan/if_rsu.c
  stable/10/sys/dev/usb/wlan/if_rsureg.h
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/sys/dev/usb/wlan/if_rsu.c
==
--- stable/10/sys/dev/usb/wlan/if_rsu.c Fri May 23 06:28:31 2014
(r266576)
+++ stable/10/sys/dev/usb/wlan/if_rsu.c Fri May 23 06:35:45 2014
(r266577)
@@ -127,7 +127,10 @@ static const STRUCT_USB_HOST_ID rsu_devs
 static device_probe_t   rsu_match;
 static device_attach_t  rsu_attach;
 static device_detach_t  rsu_detach;
-static usb_callback_t   rsu_bulk_tx_callback;
+static usb_callback_t   rsu_bulk_tx_callback_0;
+static usb_callback_t   rsu_bulk_tx_callback_1;
+static usb_callback_t   rsu_bulk_tx_callback_2;
+static usb_callback_t   rsu_bulk_tx_callback_3;
 static usb_callback_t   rsu_bulk_rx_callback;
 static usb_error_t rsu_do_request(struct rsu_softc *,
struct usb_device_request *, void *);
@@ -186,7 +189,6 @@ static int  rsu_raw_xmit(struct ieee80211
const struct ieee80211_bpf_params *);
 static voidrsu_init(void *);
 static voidrsu_init_locked(struct rsu_softc *);
-static voidrsu_watchdog(void *);
 static int rsu_tx_start(struct rsu_softc *, struct ieee80211_node *, 
struct mbuf *, struct rsu_data *);
 static voidrsu_start(struct ifnet *);
@@ -194,6 +196,7 @@ static void rsu_start_locked(struct ifne
 static int rsu_ioctl(struct ifnet *, u_long, caddr_t);
 static voidrsu_stop(struct ifnet *, int);
 static voidrsu_stop_locked(struct ifnet *, int);
+static voidrsu_ms_delay(struct rsu_softc *);
 
 static device_method_t rsu_methods[] = {
DEVMETHOD(device_probe, rsu_match),
@@ -239,7 +242,7 @@ static const struct usb_config rsu_confi
.pipe_bof = 1,
.force_short_xfer = 1
},
-   .callback = rsu_bulk_tx_callback,
+   .callback = rsu_bulk_tx_callback_0,
.timeout = RSU_TX_TIMEOUT
},
[RSU_BULK_TX_BK] = {
@@ -252,7 +255,7 @@ static const struct usb_config rsu_confi
.pipe_bof = 1,
.force_short_xfer = 1
},
-   .callback = rsu_bulk_tx_callback,
+   .callback = rsu_bulk_tx_callback_1,
.timeout = RSU_TX_TIMEOUT
},
[RSU_BULK_TX_VI] = {
@@ -265,7 +268,7 @@ static const struct usb_config rsu_confi
.pipe_bof = 1,
.force_short_xfer = 1
},
-   .callback = rsu_bulk_tx_callback,
+   .callback = rsu_bulk_tx_callback_2,
.timeout = RSU_TX_TIMEOUT
},
[RSU_BULK_TX_VO] = {
@@ -278,7 +281,7 @@ static const struct usb_config rsu_confi
.pipe_bof = 1,
.force_short_xfer = 1
},
-   .callback = rsu_bulk_tx_callback,
+   .callback = rsu_bulk_tx_callback_3,
.timeout = RSU_TX_TIMEOUT
},
 };
@@ -314,7 +317,20 @@ rsu_attach(device_t self)
MTX_DEF);
TIMEOUT_TASK_INIT(taskqueue_thread, sc-calib_task, 0, 
rsu_calib_task, sc);
-   callout_init(sc-sc_watchdog_ch, 0);
+
+   /* Allocate Tx/Rx buffers. */
+   error = rsu_alloc_rx_list(sc);
+   if (error != 0) {
+   device_printf(sc-sc_dev, could not allocate Rx buffers\n);
+   goto fail_usb;
+   }
+
+   error = rsu_alloc_tx_list(sc);
+   if (error != 0) {
+   device_printf(sc-sc_dev, could not allocate Tx buffers\n);
+   rsu_free_rx_list(sc);
+   goto fail_usb;
+   }
 
iface_index = 0;
error = usbd_transfer_setup(uaa-device, iface_index, sc-sc_xfer,
@@ -422,13 +438,10 @@ rsu_detach(device_t self)
struct ifnet *ifp = sc-sc_ifp;
struct ieee80211com *ic = ifp-if_l2com;
 
-   if (!device_is_attached(self))
-   return (0);
rsu_stop(ifp, 1);
usbd_transfer_unsetup(sc-sc_xfer, RSU_N_TRANSFER);
ieee80211_ifdetach(ic);
 
-   callout_drain(sc-sc_watchdog_ch);
taskqueue_drain_timeout(taskqueue_thread, sc-calib_task);
 
/* Free Tx/Rx buffers. */
@@ -453,7 +466,7 @@ rsu_do_request(struct rsu_softc *sc, str
while (ntries--) {
err = usbd_do_request_flags(sc-sc_udev, sc-sc_mtx,
req, data, 0, NULL, 250 /* ms */);
-   if (err == 0 || !device_is_attached(sc-sc_dev))
+   if (err == 0 || err == USB_ERR_NOT_CONFIGURED)
break;
  

svn commit: r266578 - in stable/10: share/man/man4 sys/conf sys/contrib/dev/urtwn sys/dev/usb sys/dev/usb/wlan sys/modules/usb/urtwnfw sys/modules/usb/urtwnfw/urtwnrtl8188eu

[Hans Petter Selasky]

Author: hselasky
Date: Fri May 23 06:47:47 2014
New Revision: 266578
URL: http://svnweb.freebsd.org/changeset/base/266578

Log:
  MFC r257543, r264912, r264972, r264982 and r266472:
  - Add preliminary support for the Realtek RTL8188EUS and RTL8188ETV chipsets.
  - Add device ID for 'Sanoxy 802.11N' USB
  - Initialize rssi variable.
  - Fix gcc build, initialize off variable.
  - The DELAY() should not be used in USB drivers.
  - The usb_pause_mtx() function takes ticks and not milliseconds as last 
argument.

Added:
  stable/10/sys/contrib/dev/urtwn/urtwn-rtl8188eufw.fw.uu
 - copied unchanged from r264912, 
head/sys/contrib/dev/urtwn/urtwn-rtl8188eufw.fw.uu
  stable/10/sys/modules/usb/urtwnfw/urtwnrtl8188eu/
 - copied from r264912, head/sys/modules/usb/urtwnfw/urtwnrtl8188eu/
Modified:
  stable/10/share/man/man4/urtwn.4
  stable/10/share/man/man4/urtwnfw.4
  stable/10/sys/conf/files
  stable/10/sys/dev/usb/usbdevs
  stable/10/sys/dev/usb/wlan/if_urtwn.c
  stable/10/sys/dev/usb/wlan/if_urtwnreg.h
  stable/10/sys/modules/usb/urtwnfw/Makefile
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/share/man/man4/urtwn.4
==
--- stable/10/share/man/man4/urtwn.4Fri May 23 06:35:45 2014
(r266577)
+++ stable/10/share/man/man4/urtwn.4Fri May 23 06:47:47 2014
(r266578)
@@ -19,7 +19,7 @@
 .Os
 .Sh NAME
 .Nm urtwn
-.Nd Realtek RTL8188CU/RTL8192CU USB IEEE 802.11b/g/n wireless network device
+.Nd Realtek RTL8188CU/RTL8188EU/RTL8192CU USB IEEE 802.11b/g/n wireless 
network device
 .Sh SYNOPSIS
 To compile this driver into the kernel,
 place the following lines in your
@@ -50,11 +50,11 @@ legal.realtek.license_ack=1
 The
 .Nm
 driver supports USB 2.0 wireless network devices based on Realtek
-RTL8188CUS, RTL8188CE-VAU, RTL8188RU and RTL8192CU chipsets.
+RTL8188CUS, RTL8188CE-VAU, RTL8188EUS, RTL8188RU and RTL8192CU chipsets.
 .Pp
-The RTL8188CUS is a highly integrated 802.11n adapter that combines
-a MAC, a 1T1R capable baseband and an RF in a single chip.
-It operates in the 2GHz spectrum only.
+The RTL8188CUS and RTL8188EUS are highly integrated 802.11n adapter that
+combine a MAC, a 1T1R capable baseband and an RF in a single chip.
+They operate in the 2GHz spectrum only.
 The RTL8188RU is a high-power variant of the RTL8188CUS.
 The RTL8188CE-VAU is a PCI Express Mini Card adapter that attaches
 to the USB interface.
@@ -93,6 +93,8 @@ IEEE 802.11b/g/n wireless network adapte
 .It Netgear WNA1000M
 .It Realtek RTL8192CU
 .It Realtek RTL8188CUS
+.It TP-LINK TL-WN723N v3
+.It TP-LINK TL-WN725N v2
 .El
 .Sh EXAMPLES
 Join an existing BSS network (i.e., connect to an access point):

Modified: stable/10/share/man/man4/urtwnfw.4
==
--- stable/10/share/man/man4/urtwnfw.4  Fri May 23 06:35:45 2014
(r266577)
+++ stable/10/share/man/man4/urtwnfw.4  Fri May 23 06:47:47 2014
(r266578)
@@ -22,7 +22,7 @@
 .\
 .\ $FreeBSD$
 .\
-.Dd October 31, 2013
+.Dd April 25, 2014
 .Dt URTWNFW 4
 .Os
 .Sh NAME
@@ -42,6 +42,7 @@ of the following:
 .Bd -ragged -offset indent
 .Cd device urtwn-rtl8192cfwT
 .Cd device urtwn-rtl8192cfwU
+.Cd device urtwn-rtl8188eufw
 .Ed
 .Pp
 Alternatively, to load the driver as a
@@ -50,10 +51,11 @@ module at boot time, place the following
 .Bd -literal -offset indent
 urtwn-rtl8192cfwT_load=YES
 urtwn-rtl8192cfwU_load=YES
+urtwn-rtl8188eufw_load=YES
 .Ed
 .Sh DESCRIPTION
 This module provides access to firmware sets for the
-Realtek RTL8188CUS, RTL8188CE-VAU, RTL8188RU and RTL8192CU
+Realtek RTL8188CUS, RTL8188CE-VAU, RTL8188EUS, RTL8188RU and RTL8192CU
 chip based USB WiFi adapters.
 It may be
 statically linked into the kernel, or loaded as a module.

Modified: stable/10/sys/conf/files
==
--- stable/10/sys/conf/filesFri May 23 06:35:45 2014(r266577)
+++ stable/10/sys/conf/filesFri May 23 06:47:47 2014(r266578)
@@ -2421,6 +2421,20 @@ dev/usb/wlan/if_upgt.c   optional upgt
 dev/usb/wlan/if_ural.c optional ural
 dev/usb/wlan/if_urtw.c optional urtw
 dev/usb/wlan/if_urtwn.coptional urtwn
+urtwn-rtl8188eufw.coptional urtwn-rtl8188eufw | urtwnfw\
+   compile-with${AWK} -f $S/tools/fw_stub.awk 
urtwn-rtl8188eufw.fw:urtwn-rtl8188eufw:111 -murtwn-rtl8188eufw -c${.TARGET} \
+   no-implicit-rule before-depend local\
+   clean   urtwn-rtl8188eufw.c
+urtwn-rtl8188eufw.fwo  optional urtwn-rtl8188eufw | urtwnfw\
+   dependency  urtwn-rtl8188eufw.fw  \
+   compile-with${NORMAL_FWO} \
+   no-implicit-rule\
+   clean   urtwn-rtl8188eufw.fwo
+urtwn-rtl8188eufw.fw

svn commit: r266579 - head/release/picobsd/build

[Luigi Rizzo]

Author: luigi
Date: Fri May 23 08:10:07 2014
New Revision: 266579
URL: http://svnweb.freebsd.org/changeset/base/266579

Log:
  add libraries to the initial build for picobsd.
  
  add a -j option so we can tune the amount of parallel make,
  the default we used (-j 8) is large and was giving problems
  with SUBDIR_PARALLEL due to some missing dependencies.

Modified:
  head/release/picobsd/build/picobsd

Modified: head/release/picobsd/build/picobsd
==
--- head/release/picobsd/build/picobsd  Fri May 23 06:47:47 2014
(r266578)
+++ head/release/picobsd/build/picobsd  Fri May 23 08:10:07 2014
(r266579)
@@ -177,7 +177,7 @@ create_includes_and_libraries2() { # opt
cd $1 ; ${BINMAKE} ${o_par} $2  # specific target, e.g. ld-elf.so
 else
export MAKEOBJDIRPREFIX=${l_objtree}
-   make ${o_par} $no toolchain
+   make ${o_par} $no toolchain libraries
# XXX do we need any of these ?
 eval export `cd ${SRC}; ${BINMAKE} -f Makefile.inc1 -V WMAKEENV`
[ ${o_arch} != `uname -m` ]  \
@@ -1055,8 +1055,13 @@ set_defaults
 while [ true ]; do
 log Parsing $1
 case $1 in
+-j)
+   o_par=-j $2
+   shift
+   ;;
+
 --par)
-   o_par=-j 8
+   o_par=-j 8# watch out, this might be too large
;;
 
 --src) # set the source path instead of /usr/src
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r266580 - head/release/picobsd/build

[Luigi Rizzo]

Author: luigi
Date: Fri May 23 08:34:30 2014
New Revision: 266580
URL: http://svnweb.freebsd.org/changeset/base/266580

Log:
  remove unused code (building older releases should use the
  picobsd file in the release itself)

Modified:
  head/release/picobsd/build/picobsd

Modified: head/release/picobsd/build/picobsd
==
--- head/release/picobsd/build/picobsd  Fri May 23 08:10:07 2014
(r266579)
+++ head/release/picobsd/build/picobsd  Fri May 23 08:34:30 2014
(r266580)
@@ -164,13 +164,11 @@ set_defaults() {  # no arguments
 create_includes_and_libraries2() { # opt_dir opt_target
 local no
 log create_includes_and_libraries2() for ${SRC} $1
-if [ ${OSVERSION} -ge 60 ] ; then
-   no=-DNO_CLEAN -DNO_PROFILE -DNO_GAMES -DNO_LIBC_R # WITHOUT_CDDL=1
-   no=$no -DWITHOUT_CASPER
-   no=$no -DMALLOC_PRODUCTION
-else
-   no=-DNOCLEAN -DNOPROFILE -DNOGAMES -DNOLIBC_R
-fi
+
+no=-DNO_CLEAN -DNO_PROFILE -DNO_GAMES -DNO_LIBC_R # WITHOUT_CDDL=1
+no=$no -DWITHOUT_CASPER
+no=$no -DMALLOC_PRODUCTION
+
 ( cd ${SRC};
 # make -DNOCLEAN -DNOPROFILE -DNOGAMES -DNOLIBC_R -DPICOBSD buildworld
 if [ -d $1 ] ; then
@@ -186,48 +184,6 @@ create_includes_and_libraries2() { # opt
 )
 }
 
-# entry for 4.x and earlier trees
-create_includes_and_libraries() {
-local e i
-
-log create_includes_and_libraries() for ${SRC}
-# Optionally creates include directory and libraries.
-mkdir -p ${l_usrtree}/include  # the include directory...
-mkdir -p ${l_usrtree}/share/misc   # a few things go here
-mkdir -p ${l_usrtree}/lib  # libraries
-mkdir -p ${l_usrtree}/sbin # some binaries
-# override variables for ownershiip and destinations
-# BINOWN:BINGRP are also used for include files
-(cd ${SRC}; \
-   BINOWN=`id -un` BINGRP=`id -gn` \
-   DESTDIR=${l_usrtree}/.. \
-   make -m ${SRC}/share/mk includes ) || fail $? includes
-# Pick up the correct headers for libraries.
-CFLAGS=-nostdinc -I${l_usrtree}/include ; export CFLAGS
-
-(cd ${SRC}
-   # $e is the invocation of make with correct environment
-   # XXX check the NO* options below, maybe system dependent.
-   e=MAKEOBJDIRPREFIX=${l_objtree}/picobsd/libraries \
-   BINOWN=`id -un` BINGRP=`id -gn` \
-   DESTDIR=${l_usrtree}/.. \
-   make -m ${SRC}/share/mk \
-   -DNOHTML -DNOINFO -DNOMAN -DNOSHARE -DNOFSCHG 
-   log do a 'make obj' in a few places.
-   # This is very version-specific... The following works for 5.0
-   for i in lib secure/lib gnu/lib \
-   gnu/usr.bin/perl usr.bin/lex usr.sbin/config ; do
-   (cd ${i}; eval $e obj)
-   done
-   log now make the static libraries
-   eval $e -DNOPROFILE -DNOPIC libraries
-   (cd ${SRC}/usr.sbin/config
-   eval $e # build binary
-   eval $e install # install it
-   )
-) || fail $? libraries
-log Libraries done
-}
 
 # set_type the_type [the_site] looks in user or system directories
 # for the directory named as the first argument, reads the configuration
@@ -964,11 +920,11 @@ fill_floppy_image() {
dd of=${BUILDDIR}/${c_img} oseek=1 obs=788 conv=notrunc 2/dev/null
 log done disk image
 # XXX (log Fixing permissions; cd ${dst}; chown -R root *)
+df -ik ${dst} | colrm 70  .build.reply
 # leave build stuff if verbose
 [ ${o_verbose} -gt 0 ]  return
 
 rm -rf ${BUILDDIR}/floppy.tree || true # cleanup
-# df -ik ${dst} | colrm 70  .build.reply
 rm -rf ${dst}
 rm ${BUILDDIR}/${c_fs}
 # rm ${BUILDDIR}/kernel.gz
@@ -991,7 +947,7 @@ set_build_parameters() {
 set `grep #define[\t ]__FreeBSD_version ${SRC}/sys/sys/param.h`
 OSVERSION=$3
 log OSVERSION is ${OSVERSION}
-if [ ${OSVERSION} -ge 500035 ] ; then
+
export MAKEOBJDIRPREFIX=${l_objtree}
export TARGET_ARCH=${o_arch} TARGET=${o_arch}
# XXX 20131001 see if CLANG fixes the build
@@ -1010,26 +966,12 @@ set_build_parameters() {
eval export BINMAKE=\`cd ${SRC}; make -f Makefile -V BINMAKE`\
[ $BINMAKE =  ]  \
   eval export BINMAKE=\`cd ${SRC}; make -f Makefile -V SUB_MAKE`\
-fi
 
 if [ ${o_init_src} !=  ] ; then
-   if [ ${OSVERSION} -lt 500035 ] ; then
-   create_includes_and_libraries
-   else
-   create_includes_and_libraries2
-   fi
+   create_includes_and_libraries2
 else
eval export `cd ${SRC}; ${BINMAKE} -f Makefile.inc1 -V WMAKEENV`
 fi
-if [ ${OSVERSION} -lt 500035 ] ; then
-   # Create the right LIBS and CFLAGS for further builds.
-   # and build the config program
-   LIBS=-L${l_usrtree}/lib
-   CFLAGS=-nostdinc -I${l_usrtree}/include
-   export LIBS CFLAGS
-   CONFIG=${l_usrtree}/sbin/config
-   export CONFIG
-fi
 
 # if we have o_objdir, 

svn commit: r266581 - in head: etc/mtree include lib/libcuse sys/conf sys/fs/cuse sys/modules/cuse

[Hans Petter Selasky]

Author: hselasky
Date: Fri May 23 08:46:28 2014
New Revision: 266581
URL: http://svnweb.freebsd.org/changeset/base/266581

Log:
  Initial import of character device in userspace support for FreeBSD.
  The CUSE library is a wrapper for the devfs kernel functionality which
  is exposed through /dev/cuse . In order to function the CUSE kernel
  code must either be enabled in the kernel configuration file or loaded
  separately as a module. Currently none of the committed items are
  connected to the default builds, except for installing the needed
  header files. The CUSE code will be connected to the default world and
  kernel builds in a follow-up commit.
  
  The CUSE module was written by Hans Petter Selasky, somewhat inspired
  by similar functionality found in FUSE. The CUSE library can be used
  for many purposes. Currently CUSE is used when running Linux kernel
  drivers in user-space, which need to create a character device node to
  communicate with its applications. CUSE has full support for almost
  all devfs functionality found in the kernel:
   - kevents
   - read
   - write
   - ioctl
   - poll
   - open
   - close
   - mmap
   - private per file handle data
  
  Requested by several people. Also see multimedia/cuse4bsd-kmod in
  ports.

Added:
  head/lib/libcuse/
  head/lib/libcuse/Makefile   (contents, props changed)
  head/lib/libcuse/cuse.3   (contents, props changed)
  head/lib/libcuse/cuse.h   (contents, props changed)
  head/lib/libcuse/cuse_lib.c   (contents, props changed)
  head/sys/fs/cuse/
  head/sys/fs/cuse/cuse.c   (contents, props changed)
  head/sys/fs/cuse/cuse_defs.h   (contents, props changed)
  head/sys/fs/cuse/cuse_ioctl.h   (contents, props changed)
  head/sys/modules/cuse/
  head/sys/modules/cuse/Makefile   (contents, props changed)
Modified:
  head/etc/mtree/BSD.include.dist
  head/include/Makefile
  head/sys/conf/files

Modified: head/etc/mtree/BSD.include.dist
==
--- head/etc/mtree/BSD.include.dist Fri May 23 08:34:30 2014
(r266580)
+++ head/etc/mtree/BSD.include.dist Fri May 23 08:46:28 2014
(r266581)
@@ -162,6 +162,8 @@
 ..
 ..
 fs
+   cuse
+   ..
 devfs
 ..
 fdescfs

Modified: head/include/Makefile
==
--- head/include/Makefile   Fri May 23 08:34:30 2014(r266580)
+++ head/include/Makefile   Fri May 23 08:46:28 2014(r266581)
@@ -45,6 +45,7 @@ LSUBDIRS= cam/ata cam/scsi \
dev/ic dev/iicbus ${_dev_ieee488} dev/io dev/lmc dev/mfi dev/nvme \
dev/ofw dev/pbio dev/pci ${_dev_powermac_nvram} dev/ppbus dev/smbus \
dev/speaker dev/usb dev/utopia dev/vkbd dev/wi \
+   fs/cuse \
fs/devfs fs/fdescfs fs/msdosfs fs/nandfs fs/nfs fs/nullfs \
fs/procfs fs/smbfs fs/udf fs/unionfs \
geom/cache geom/concat geom/eli geom/gate geom/journal geom/label \

Added: head/lib/libcuse/Makefile
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/lib/libcuse/Makefile   Fri May 23 08:46:28 2014(r266581)
@@ -0,0 +1,64 @@
+# $FreeBSD$
+#
+# Copyright (c) 2010 Hans Petter Selasky. All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#notice, this list of conditions and the following disclaimer in the
+#documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+
+LIB=   cuse
+SHLIB_MAJOR=   1
+SHLIB_MINOR=   0
+SRCS=  cuse_lib.c
+INCS=  cuse.h
+MAN=   cuse.3
+PTHREAD_LIBS?= -lpthread
+CFLAGS+=   -D_GNU_SOURCE
+.if defined(HAVE_DEBUG)
+CFLAGS+=   -g
+CFLAGS+=   -DHAVE_DEBUG
+.endif
+LDADD+=${PTHREAD_LIBS}
+
+MLINKS=
+MLINKS+= cuse.3 

svn commit: r266582 - in stable/10/sys: kern sys vm

[Konstantin Belousov]

Author: kib
Date: Fri May 23 09:29:04 2014
New Revision: 266582
URL: http://svnweb.freebsd.org/changeset/base/266582

Log:
  MFC r266464:
  In execve(2), postpone the free of old vmspace until the threads are resumed
  and exited.

Modified:
  stable/10/sys/kern/kern_exec.c
  stable/10/sys/sys/proc.h
  stable/10/sys/vm/vm_map.c
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/sys/kern/kern_exec.c
==
--- stable/10/sys/kern/kern_exec.c  Fri May 23 08:46:28 2014
(r266581)
+++ stable/10/sys/kern/kern_exec.c  Fri May 23 09:29:04 2014
(r266582)
@@ -283,6 +283,7 @@ kern_execve(td, args, mac_p)
struct mac *mac_p;
 {
struct proc *p = td-td_proc;
+   struct vmspace *oldvmspace;
int error;
 
AUDIT_ARG_ARGV(args-begin_argv, args-argc,
@@ -299,6 +300,8 @@ kern_execve(td, args, mac_p)
PROC_UNLOCK(p);
}
 
+   KASSERT((td-td_pflags  TDP_EXECVMSPC) == 0, (nested execve));
+   oldvmspace = td-td_proc-p_vmspace;
error = do_execve(td, args, mac_p);
 
if (p-p_flag  P_HADTHREADS) {
@@ -313,6 +316,12 @@ kern_execve(td, args, mac_p)
thread_single_end();
PROC_UNLOCK(p);
}
+   if ((td-td_pflags  TDP_EXECVMSPC) != 0) {
+   KASSERT(td-td_proc-p_vmspace != oldvmspace,
+   (oldvmspace still used));
+   vmspace_free(oldvmspace);
+   td-td_pflags = ~TDP_EXECVMSPC;
+   }
 
return (error);
 }

Modified: stable/10/sys/sys/proc.h
==
--- stable/10/sys/sys/proc.hFri May 23 08:46:28 2014(r266581)
+++ stable/10/sys/sys/proc.hFri May 23 09:29:04 2014(r266582)
@@ -425,6 +425,7 @@ do {
\
 #defineTDP_NERRNO  0x0800 /* Last errno is already in td_errno 
*/
 #defineTDP_UIOHELD 0x1000 /* Current uio has pages held in 
td_ma */
 #defineTDP_DEVMEMIO0x2000 /* Accessing memory for /dev/mem */
+#defineTDP_EXECVMSPC   0x4000 /* Execve destroyed old vmspace */
 
 /*
  * Reasons that the current thread can not be run yet.

Modified: stable/10/sys/vm/vm_map.c
==
--- stable/10/sys/vm/vm_map.c   Fri May 23 08:46:28 2014(r266581)
+++ stable/10/sys/vm/vm_map.c   Fri May 23 09:29:04 2014(r266582)
@@ -3751,6 +3751,8 @@ vmspace_exec(struct proc *p, vm_offset_t
struct vmspace *oldvmspace = p-p_vmspace;
struct vmspace *newvmspace;
 
+   KASSERT((curthread-td_pflags  TDP_EXECVMSPC) == 0,
+   (vmspace_exec recursed));
newvmspace = vmspace_alloc(minuser, maxuser, NULL);
if (newvmspace == NULL)
return (ENOMEM);
@@ -3767,7 +3769,7 @@ vmspace_exec(struct proc *p, vm_offset_t
PROC_VMSPACE_UNLOCK(p);
if (p == curthread-td_proc)
pmap_activate(curthread);
-   vmspace_free(oldvmspace);
+   curthread-td_pflags |= TDP_EXECVMSPC;
return (0);
 }
 
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r266583 - in stable/8/sys: kern sys vm

[Konstantin Belousov]

Author: kib
Date: Fri May 23 09:48:42 2014
New Revision: 266583
URL: http://svnweb.freebsd.org/changeset/base/266583

Log:
  MFC r266464:
  In execve(2), postpone the free of old vmspace until the threads are resumed
  and exited.

Modified:
  stable/8/sys/kern/kern_exec.c
  stable/8/sys/sys/proc.h
  stable/8/sys/vm/vm_map.c
Directory Properties:
  stable/8/sys/   (props changed)
  stable/8/sys/kern/   (props changed)
  stable/8/sys/sys/   (props changed)
  stable/8/sys/vm/   (props changed)

Modified: stable/8/sys/kern/kern_exec.c
==
--- stable/8/sys/kern/kern_exec.c   Fri May 23 09:29:04 2014
(r266582)
+++ stable/8/sys/kern/kern_exec.c   Fri May 23 09:48:42 2014
(r266583)
@@ -278,6 +278,7 @@ kern_execve(td, args, mac_p)
struct mac *mac_p;
 {
struct proc *p = td-td_proc;
+   struct vmspace *oldvmspace;
int error;
 
AUDIT_ARG_ARGV(args-begin_argv, args-argc,
@@ -294,6 +295,8 @@ kern_execve(td, args, mac_p)
PROC_UNLOCK(p);
}
 
+   KASSERT((td-td_pflags  TDP_EXECVMSPC) == 0, (nested execve));
+   oldvmspace = td-td_proc-p_vmspace;
error = do_execve(td, args, mac_p);
 
if (p-p_flag  P_HADTHREADS) {
@@ -308,6 +311,12 @@ kern_execve(td, args, mac_p)
thread_single_end();
PROC_UNLOCK(p);
}
+   if ((td-td_pflags  TDP_EXECVMSPC) != 0) {
+   KASSERT(td-td_proc-p_vmspace != oldvmspace,
+   (oldvmspace still used));
+   vmspace_free(oldvmspace);
+   td-td_pflags = ~TDP_EXECVMSPC;
+   }
 
return (error);
 }

Modified: stable/8/sys/sys/proc.h
==
--- stable/8/sys/sys/proc.h Fri May 23 09:29:04 2014(r266582)
+++ stable/8/sys/sys/proc.h Fri May 23 09:48:42 2014(r266583)
@@ -414,6 +414,7 @@ do {
\
 #defineTDP_AUDITREC0x0100 /* Audit record pending on thread */
 #defineTDP_RESETSPUR   0x0400 /* Reset spurious page fault 
history. */
 #defineTDP_NERRNO  0x0800 /* Last errno is already in td_errno 
*/
+#defineTDP_EXECVMSPC   0x4000 /* Execve destroyed old vmspace */
 
 /*
  * Reasons that the current thread can not be run yet.

Modified: stable/8/sys/vm/vm_map.c
==
--- stable/8/sys/vm/vm_map.cFri May 23 09:29:04 2014(r266582)
+++ stable/8/sys/vm/vm_map.cFri May 23 09:48:42 2014(r266583)
@@ -3521,6 +3521,8 @@ vmspace_exec(struct proc *p, vm_offset_t
struct vmspace *oldvmspace = p-p_vmspace;
struct vmspace *newvmspace;
 
+   KASSERT((curthread-td_pflags  TDP_EXECVMSPC) == 0,
+   (vmspace_exec recursed));
newvmspace = vmspace_alloc(minuser, maxuser);
if (newvmspace == NULL)
return (ENOMEM);
@@ -3537,7 +3539,7 @@ vmspace_exec(struct proc *p, vm_offset_t
PROC_VMSPACE_UNLOCK(p);
if (p == curthread-td_proc)
pmap_activate(curthread);
-   vmspace_free(oldvmspace);
+   curthread-td_pflags |= TDP_EXECVMSPC;
return (0);
 }
 
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r266584 - head/release/picobsd/build

[Luigi Rizzo]

Author: luigi
Date: Fri May 23 11:22:44 2014
New Revision: 266584
URL: http://svnweb.freebsd.org/changeset/base/266584

Log:
  do not build libraries, they require a lot more stuff

Modified:
  head/release/picobsd/build/picobsd

Modified: head/release/picobsd/build/picobsd
==
--- head/release/picobsd/build/picobsd  Fri May 23 09:48:42 2014
(r266583)
+++ head/release/picobsd/build/picobsd  Fri May 23 11:22:44 2014
(r266584)
@@ -175,7 +175,8 @@ create_includes_and_libraries2() { # opt
cd $1 ; ${BINMAKE} ${o_par} $2  # specific target, e.g. ld-elf.so
 else
export MAKEOBJDIRPREFIX=${l_objtree}
-   make ${o_par} $no toolchain libraries
+   make ${o_par} $no toolchain
+
# XXX do we need any of these ?
 eval export `cd ${SRC}; ${BINMAKE} -f Makefile.inc1 -V WMAKEENV`
[ ${o_arch} != `uname -m` ]  \
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r266585 - in stable/9/sys: kern sys vm

[Konstantin Belousov]

Author: kib
Date: Fri May 23 11:56:32 2014
New Revision: 266585
URL: http://svnweb.freebsd.org/changeset/base/266585

Log:
  MFC r266464:
  In execve(2), postpone the free of old vmspace until the threads are resumed
  and exited.
  
  Approved by:  re (marius)

Modified:
  stable/9/sys/kern/kern_exec.c
  stable/9/sys/sys/proc.h
  stable/9/sys/vm/vm_map.c
Directory Properties:
  stable/9/sys/   (props changed)
  stable/9/sys/sys/   (props changed)

Modified: stable/9/sys/kern/kern_exec.c
==
--- stable/9/sys/kern/kern_exec.c   Fri May 23 11:22:44 2014
(r266584)
+++ stable/9/sys/kern/kern_exec.c   Fri May 23 11:56:32 2014
(r266585)
@@ -282,6 +282,7 @@ kern_execve(td, args, mac_p)
struct mac *mac_p;
 {
struct proc *p = td-td_proc;
+   struct vmspace *oldvmspace;
int error;
 
AUDIT_ARG_ARGV(args-begin_argv, args-argc,
@@ -298,6 +299,8 @@ kern_execve(td, args, mac_p)
PROC_UNLOCK(p);
}
 
+   KASSERT((td-td_pflags  TDP_EXECVMSPC) == 0, (nested execve));
+   oldvmspace = td-td_proc-p_vmspace;
error = do_execve(td, args, mac_p);
 
if (p-p_flag  P_HADTHREADS) {
@@ -312,6 +315,12 @@ kern_execve(td, args, mac_p)
thread_single_end();
PROC_UNLOCK(p);
}
+   if ((td-td_pflags  TDP_EXECVMSPC) != 0) {
+   KASSERT(td-td_proc-p_vmspace != oldvmspace,
+   (oldvmspace still used));
+   vmspace_free(oldvmspace);
+   td-td_pflags = ~TDP_EXECVMSPC;
+   }
 
return (error);
 }

Modified: stable/9/sys/sys/proc.h
==
--- stable/9/sys/sys/proc.h Fri May 23 11:22:44 2014(r266584)
+++ stable/9/sys/sys/proc.h Fri May 23 11:56:32 2014(r266585)
@@ -426,6 +426,7 @@ do {
\
 #defineTDP_NERRNO  0x0800 /* Last errno is already in td_errno 
*/
 #defineTDP_UIOHELD 0x1000 /* Current uio has pages held in 
td_ma */
 #defineTDP_DEVMEMIO0x2000 /* Accessing memory for /dev/mem */
+#defineTDP_EXECVMSPC   0x4000 /* Execve destroyed old vmspace */
 
 /*
  * Reasons that the current thread can not be run yet.

Modified: stable/9/sys/vm/vm_map.c
==
--- stable/9/sys/vm/vm_map.cFri May 23 11:22:44 2014(r266584)
+++ stable/9/sys/vm/vm_map.cFri May 23 11:56:32 2014(r266585)
@@ -3752,6 +3752,8 @@ vmspace_exec(struct proc *p, vm_offset_t
struct vmspace *oldvmspace = p-p_vmspace;
struct vmspace *newvmspace;
 
+   KASSERT((curthread-td_pflags  TDP_EXECVMSPC) == 0,
+   (vmspace_exec recursed));
newvmspace = vmspace_alloc(minuser, maxuser);
if (newvmspace == NULL)
return (ENOMEM);
@@ -3768,7 +3770,7 @@ vmspace_exec(struct proc *p, vm_offset_t
PROC_VMSPACE_UNLOCK(p);
if (p == curthread-td_proc)
pmap_activate(curthread);
-   vmspace_free(oldvmspace);
+   curthread-td_pflags |= TDP_EXECVMSPC;
return (0);
 }
 
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266579 - head/release/picobsd/build

[Ian Lepore]

On Fri, 2014-05-23 at 08:10 +, Luigi Rizzo wrote:
 Author: luigi
 Date: Fri May 23 08:10:07 2014
 New Revision: 266579
 URL: http://svnweb.freebsd.org/changeset/base/266579
 
 Log:
   add libraries to the initial build for picobsd.
   
   add a -j option so we can tune the amount of parallel make,
   the default we used (-j 8) is large and was giving problems
   with SUBDIR_PARALLEL due to some missing dependencies.
 

Do you have info on what missing dependencies?  Were they in the lib/
hierarchy, or somewhere else?  I have a sketchy hand-wavy plan for
handling dependencies with finer-grained control than the current .WAIT
mechanism, but I haven't hurried to work on it because I didn't think
anyone was having any trouble.

-- Ian


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r266586 - head/sbin/fsck

[Tom Rhodes]

Author: trhodes
Date: Fri May 23 14:32:57 2014
New Revision: 266586
URL: http://svnweb.freebsd.org/changeset/base/266586

Log:
  If called without -T or -t, fsck attempts to detect the
  file system type.  If this fails, fsck will fail with
  unknown file system type message.
  
  PR:   188214

Modified:
  head/sbin/fsck/fsck.8

Modified: head/sbin/fsck/fsck.8
==
--- head/sbin/fsck/fsck.8   Fri May 23 11:56:32 2014(r266585)
+++ head/sbin/fsck/fsck.8   Fri May 23 14:32:57 2014(r266586)
@@ -29,7 +29,7 @@
 .\
 .\ $FreeBSD$
 .\
-.Dd January 25, 2009
+.Dd May 23, 2014
 .Dt FSCK 8
 .Os
 .Sh NAME
@@ -111,6 +111,18 @@ The disk drive containing each file syst
 of the device name that ends in a digit; the remaining characters are assumed
 to be the partition and slice designators.
 .Pp
+If the
+.Fl t
+or
+.Fl T
+flags are not specified,
+.Nm
+will attempt to determine the file system type and call the
+appropriated file system check utility.
+Failure to detect the file system type will cause
+.Nm
+to fail with a message that the partition has an unknown file system type.
+.Pp
 The options are as follows:
 .Bl -tag -width indent
 .It Fl C
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r266587 - head/share/mk

[Warner Losh]

Author: imp
Date: Fri May 23 14:34:22 2014
New Revision: 266587
URL: http://svnweb.freebsd.org/changeset/base/266587

Log:
  Allow CC to not actually exist. During the ports INDEX run, all the
  Makefiles are evaluated without building things. In a normal build,
  the prerequisites would be built, and CC would be an actual thing. In
  an INDEX build, though, they don't exists. Redirect stderr to get rid
  of annoying messages, and assume that the compiler version is 0 if the
  actual compiler can't tell us. Do this in preference to guessing based
  on numbers because gcc410 might be 4.10, or 4.1.0 and without
  carefully crafted special knowledge we differentiate between them
  easily (also ming-gcc has no clues at all). Elsewhere, don't trust
  the compiler version if it is 0.

Modified:
  head/share/mk/bsd.compiler.mk

Modified: head/share/mk/bsd.compiler.mk
==
--- head/share/mk/bsd.compiler.mk   Fri May 23 14:32:57 2014
(r266586)
+++ head/share/mk/bsd.compiler.mk   Fri May 23 14:34:22 2014
(r266587)
@@ -21,11 +21,11 @@
 .if !target(__bsd.compiler.mk__)
 __bsd.compiler.mk__:
 
-_v!=   ${CC} --version
+_v!=   ${CC} --version 2/dev/null || echo 0.0.0
 .if !defined(COMPILER_TYPE)
-. if ${CC:T:Mgcc*}
+. if ${CC:T:M*gcc*}
 COMPILER_TYPE:=gcc  
-. elif ${CC:T:Mclang}
+. elif ${CC:T:M*clang*}
 COMPILER_TYPE:=clang
 . elif ${_v:Mgcc}
 COMPILER_TYPE:=gcc
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Nathan Whitehorn]

Is there any chance of finally switching the pkg abi identifiers to just 
be uname -p?

-Nathan

On 05/22/14 12:22, Glen Barber wrote:

Author: gjb
Date: Thu May 22 19:22:03 2014
New Revision: 266553
URL: http://svnweb.freebsd.org/changeset/base/266553

Log:
   Add forward-compatibility glue with pkg-1.3:
- Use ASSUME_ALWAYS_YES=YES instead of ASSUME_ALWAYS_YES=1
  since pkg-1.3 expects yes or true values.
- Before exporting PKG_ABI, strip extra characters from what
  is parsed from 'pkg -vv'.  This causes problems further down
  when creating the packages directory for inclusion on the
  dvd1.iso.  Previously PKG_ABI would be 'freebsd:9:x86:64',
  but now is 'freebsd:9:x86:64;' in pkg-1.3
   
   Tested on:	stable/9@r265858 with ports-mgmt/pkg-devel

   MFC After:   3 days
   Sponsored by:The FreeBSD Foundation

Modified:
   head/release/scripts/pkg-stage.sh

Modified: head/release/scripts/pkg-stage.sh
==
--- head/release/scripts/pkg-stage.sh   Thu May 22 18:22:02 2014
(r266552)
+++ head/release/scripts/pkg-stage.sh   Thu May 22 19:22:03 2014
(r266553)
@@ -5,7 +5,7 @@
  
  set -e
  
-export ASSUME_ALWAYS_YES=1

+export ASSUME_ALWAYS_YES=YES
  export PKG_DBDIR=/tmp/pkg
  export PERMISSIVE=YES
  export REPO_AUTOUPDATE=NO
@@ -40,7 +40,10 @@ if [ ! -x /usr/local/sbin/pkg ]; then
/usr/bin/make -C /usr/ports/ports-mgmt/pkg install clean
  fi
  
-export PKG_ABI=$(pkg -vv | grep ^ABI | awk '{print $3}')

+PKG_ABI=$(pkg -vv | grep ^ABI | awk '{print $3}')
+PKG_ABI=${PKG_ABI%\;}
+PKG_ABI=${PKG_ABI#\}
+export PKG_ABI
  export PKG_CACHEDIR=dvd/packages/${PKG_ABI}
  
  /bin/mkdir -p ${PKG_CACHEDIR}




___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Glen Barber]

It would certainly make my life easier.  But until such thing is done in
pkg(7) code, I have to put things in a directory structure that pkg(7)
can just use for on-disc packages.

Glen

On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:
 Is there any chance of finally switching the pkg abi identifiers to just be
 uname -p?
 -Nathan
 
 On 05/22/14 12:22, Glen Barber wrote:
 Author: gjb
 Date: Thu May 22 19:22:03 2014
 New Revision: 266553
 URL: http://svnweb.freebsd.org/changeset/base/266553
 
 Log:
Add forward-compatibility glue with pkg-1.3:
 - Use ASSUME_ALWAYS_YES=YES instead of ASSUME_ALWAYS_YES=1
   since pkg-1.3 expects yes or true values.
 - Before exporting PKG_ABI, strip extra characters from what
   is parsed from 'pkg -vv'.  This causes problems further down
   when creating the packages directory for inclusion on the
   dvd1.iso.  Previously PKG_ABI would be 'freebsd:9:x86:64',
   but now is 'freebsd:9:x86:64;' in pkg-1.3
Tested on:stable/9@r265858 with ports-mgmt/pkg-devel
MFC After:3 days
Sponsored by: The FreeBSD Foundation
 
 Modified:
head/release/scripts/pkg-stage.sh
 
 Modified: head/release/scripts/pkg-stage.sh
 ==
 --- head/release/scripts/pkg-stage.shThu May 22 18:22:02 2014
 (r266552)
 +++ head/release/scripts/pkg-stage.shThu May 22 19:22:03 2014
 (r266553)
 @@ -5,7 +5,7 @@
   set -e
 -export ASSUME_ALWAYS_YES=1
 +export ASSUME_ALWAYS_YES=YES
   export PKG_DBDIR=/tmp/pkg
   export PERMISSIVE=YES
   export REPO_AUTOUPDATE=NO
 @@ -40,7 +40,10 @@ if [ ! -x /usr/local/sbin/pkg ]; then
  /usr/bin/make -C /usr/ports/ports-mgmt/pkg install clean
   fi
 -export PKG_ABI=$(pkg -vv | grep ^ABI | awk '{print $3}')
 +PKG_ABI=$(pkg -vv | grep ^ABI | awk '{print $3}')
 +PKG_ABI=${PKG_ABI%\;}
 +PKG_ABI=${PKG_ABI#\}
 +export PKG_ABI
   export PKG_CACHEDIR=dvd/packages/${PKG_ABI}
   /bin/mkdir -p ${PKG_CACHEDIR}
 


pgp9oL2q1K32w.pgp
Description: PGP signature

Re: svn commit: r266553 - head/release/scripts

[Baptiste Daroussin]

On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:
 Is there any chance of finally switching the pkg abi identifiers to just 
 be uname -p?
 -Nathan

Keeping asking won't make it happen, I have explained a large number of time 
why it
happened, why it is not easy for compatibility and why uname -p is still not
representing the ABI we do support, and what flexibility we need that the
current string offers to us.

if one is willing to do the work, please be my guess, just dig into the archives
and join the pkg development otherwise: no it won't happen before a while
because we have way too much work on the todo and this item is stored at the
very end of this todo.

regards,
Bapt


pgpoYdlDzErkb.pgp
Description: PGP signature

Re: svn commit: r266553 - head/release/scripts

[Nathan Whitehorn]

On 05/23/14 08:36, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:

Is there any chance of finally switching the pkg abi identifiers to just
be uname -p?
-Nathan

Keeping asking won't make it happen, I have explained a large number of time 
why it
happened, why it is not easy for compatibility and why uname -p is still not
representing the ABI we do support, and what flexibility we need that the
current string offers to us.

if one is willing to do the work, please be my guess, just dig into the archives
and join the pkg development otherwise: no it won't happen before a while
because we have way too much work on the todo and this item is stored at the
very end of this todo.

regards,
Bapt


I'm happy to do the work, and have volunteered now many times. If uname 
-p does not describe the ABI fully, then uname -p needs changes on the 
relevant platforms. Which are they? What extra flexibility does the 
string give you if uname -p describes the ABI completely?

-Nathan
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Baptiste Daroussin]

On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:
 On 05/23/14 08:36, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:
  Is there any chance of finally switching the pkg abi identifiers to just
  be uname -p?
  -Nathan
  Keeping asking won't make it happen, I have explained a large number of 
  time why it
  happened, why it is not easy for compatibility and why uname -p is still not
  representing the ABI we do support, and what flexibility we need that the
  current string offers to us.
 
  if one is willing to do the work, please be my guess, just dig into the 
  archives
  and join the pkg development otherwise: no it won't happen before a while
  because we have way too much work on the todo and this item is stored at the
  very end of this todo.
 
  regards,
  Bapt
 
 I'm happy to do the work, and have volunteered now many times. If uname 
 -p does not describe the ABI fully, then uname -p needs changes on the 
 relevant platforms. Which are they? What extra flexibility does the 
 string give you if uname -p describes the ABI completely?
 -Nathan

just simple examples in armv6:
- eabi vs oabi
- The different float abi (even if only one is supported for now others are
  being worked on)
- little endian vs big endian

the extras flexibilit is being able to say this binary do support freebsd i386
and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:*

regards,
Bapt


pgpBnkoQbBN7t.pgp
Description: PGP signature

svn commit: r266588 - head/sys/vm

[Alan Cox]

Author: alc
Date: Fri May 23 16:22:36 2014
New Revision: 266588
URL: http://svnweb.freebsd.org/changeset/base/266588

Log:
  There is no reason to perform the pmap_remove() on the kernel pmap while
  the kmem object lock is held.  Do the pmap_remove() before acquiring the
  kmem object lock.
  
  MFC after:1 week
  Sponsored by: EMC / Isilon Storage Division

Modified:
  head/sys/vm/vm_kern.c

Modified: head/sys/vm/vm_kern.c
==
--- head/sys/vm/vm_kern.c   Fri May 23 14:34:22 2014(r266587)
+++ head/sys/vm/vm_kern.c   Fri May 23 16:22:36 2014(r266588)
@@ -396,9 +396,9 @@ kmem_unback(vm_object_t object, vm_offse
KASSERT(object == kmem_object || object == kernel_object,
(kmem_unback: only supports kernel objects.));
 
+   pmap_remove(kernel_pmap, addr, addr + size);
offset = addr - VM_MIN_KERNEL_ADDRESS;
VM_OBJECT_WLOCK(object);
-   pmap_remove(kernel_pmap, addr, addr + size);
for (i = 0; i  size; i += PAGE_SIZE) {
m = vm_page_lookup(object, OFF_TO_IDX(offset + i));
vm_page_unwire(m, 0);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Nathan Whitehorn]

On 05/23/14 09:20, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:

On 05/23/14 08:36, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:

Is there any chance of finally switching the pkg abi identifiers to just
be uname -p?
-Nathan

Keeping asking won't make it happen, I have explained a large number of time 
why it
happened, why it is not easy for compatibility and why uname -p is still not
representing the ABI we do support, and what flexibility we need that the
current string offers to us.

if one is willing to do the work, please be my guess, just dig into the archives
and join the pkg development otherwise: no it won't happen before a while
because we have way too much work on the todo and this item is stored at the
very end of this todo.

regards,
Bapt

I'm happy to do the work, and have volunteered now many times. If uname
-p does not describe the ABI fully, then uname -p needs changes on the
relevant platforms. Which are they? What extra flexibility does the
string give you if uname -p describes the ABI completely?
-Nathan

just simple examples in armv6:
- eabi vs oabi


OABI is almost entirely dead, and will be entirely dead soon.


- The different float abi (even if only one is supported for now others are
   being worked on)


armv6 and armv6hf


- little endian vs big endian


armv6 and armv6eb (though I think armv6eb support in general has been 
removed from the tree, but armeb is still there)


These all already exist.


the extras flexibilit is being able to say this binary do support freebsd i386
and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:*



The second one already would work, wouldn't it? Just replacing x86:64 
with amd64 won't change anything. The first has to be outweighed by 
being able to reliably figure out where to fetch from without a lookup 
table.


We also added the kern.supported_archs sysctl last year to all branches 
to enable figuring out which architectures a given running kernel 
supports (e.g. amd64 and i386 on most amd64 systems). This was designed 
specifically to help pkg figure out what packages it can install.

-Nathan
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Baptiste Daroussin]

On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:
 On 05/23/14 09:20, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:
  On 05/23/14 08:36, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:
  Is there any chance of finally switching the pkg abi identifiers to just
  be uname -p?
  -Nathan
  Keeping asking won't make it happen, I have explained a large number of 
  time why it
  happened, why it is not easy for compatibility and why uname -p is still 
  not
  representing the ABI we do support, and what flexibility we need that the
  current string offers to us.
 
  if one is willing to do the work, please be my guess, just dig into the 
  archives
  and join the pkg development otherwise: no it won't happen before a while
  because we have way too much work on the todo and this item is stored at 
  the
  very end of this todo.
 
  regards,
  Bapt
  I'm happy to do the work, and have volunteered now many times. If uname
  -p does not describe the ABI fully, then uname -p needs changes on the
  relevant platforms. Which are they? What extra flexibility does the
  string give you if uname -p describes the ABI completely?
  -Nathan
  just simple examples in armv6:
  - eabi vs oabi
 
 OABI is almost entirely dead, and will be entirely dead soon.

Maybe but still for now it is there and pkg has to work now
 
  - The different float abi (even if only one is supported for now others are
 being worked on)
 
 armv6 and armv6hf
 
  - little endian vs big endian
 
 armv6 and armv6eb (though I think armv6eb support in general has been 
 removed from the tree, but armeb is still there)
what about combinaison? armv6 + eb + hf?
 
 These all already exist.
 
  the extras flexibilit is being able to say this binary do support freebsd 
  i386
  and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:*
 

arm was en example what about mips?
 
 The second one already would work, wouldn't it? Just replacing x86:64 
 with amd64 won't change anything. The first has to be outweighed by 
 being able to reliably figure out where to fetch from without a lookup 
 table.
 
 We also added the kern.supported_archs sysctl last year to all branches 
 to enable figuring out which architectures a given running kernel 
 supports (e.g. amd64 and i386 on most amd64 systems). This was designed 
 specifically to help pkg figure out what packages it can install.

I know, it means that we can switch only when freebsd 8 and 9 are EOL which 
means
in a couple of years

And it defeats cross installation (which is the reason why the ABI supported is
read from a binary and not from kernel)

and last thing is the current build packages should just work meaning that we
would need to have a kind of mapping table


pgpGVUGQaHiXK.pgp
Description: PGP signature

svn commit: r266589 - stable/10/sys/vm

[Alan Cox]

Author: alc
Date: Fri May 23 16:46:50 2014
New Revision: 266589
URL: http://svnweb.freebsd.org/changeset/base/266589

Log:
  MFC r265886, r265948
With the new-and-improved vm_fault_copy_entry() (r265843), we can always
avoid soft page faults when adding write access to user wired entries in
vm_map_protect().  Previously, we only avoided the soft page fault when
the underlying pages were copy-on-write.  In other words, we avoided the
pages faults that might sleep on page allocation, but not the trivial
page faults to update the physical map.
  
On a fork allow read-only wired pages to be copy-on-write shared between
the parent and child processes.  Previously, we copied these pages even
though they are read only.  However, the reason for copying them is
historical and no longer exists.  In recent times, vm_map_protect() has
developed the ability to copy pages when write access is added to wired
copy-on-write pages.  So, in this case, copy-on-write sharing of wired
pages is not to be feared.  It is not going to lead to copy-on-write
faults on wired memory.

Modified:
  stable/10/sys/vm/vm_map.c
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/sys/vm/vm_map.c
==
--- stable/10/sys/vm/vm_map.c   Fri May 23 16:22:36 2014(r266588)
+++ stable/10/sys/vm/vm_map.c   Fri May 23 16:46:50 2014(r266589)
@@ -1978,10 +1978,17 @@ vm_map_protect(vm_map_t map, vm_offset_t
else
current-protection = new_prot;
 
-   if ((current-eflags  (MAP_ENTRY_COW | MAP_ENTRY_USER_WIRED))
-== (MAP_ENTRY_COW | MAP_ENTRY_USER_WIRED) 
+   /*
+* For user wired map entries, the normal lazy evaluation of
+* write access upgrades through soft page faults is
+* undesirable.  Instead, immediately copy any pages that are
+* copy-on-write and enable write access in the physical map.
+*/
+   if ((current-eflags  MAP_ENTRY_USER_WIRED) != 0 
(current-protection  VM_PROT_WRITE) != 0 
(old_prot  VM_PROT_WRITE) == 0) {
+   KASSERT(old_prot != VM_PROT_NONE,
+   (vm_map_protect: inaccessible wired map entry));
vm_fault_copy_entry(map, map, current, current, NULL);
}
 
@@ -3017,8 +3024,8 @@ vm_map_copy_entry(
if ((dst_entry-eflags|src_entry-eflags)  MAP_ENTRY_IS_SUB_MAP)
return;
 
-   if (src_entry-wired_count == 0) {
-
+   if (src_entry-wired_count == 0 ||
+   (src_entry-protection  VM_PROT_WRITE) == 0) {
/*
 * If the source entry is marked needs_copy, it is already
 * write-protected.
@@ -3109,9 +3116,9 @@ vm_map_copy_entry(
dst_entry-end - dst_entry-start, src_entry-start);
} else {
/*
-* Of course, wired down pages can't be set copy-on-write.
-* Cause wired pages to be copied into the new map by
-* simulating faults (the new pages are pageable)
+* We don't want to make writeable wired pages copy-on-write.
+* Immediately copy these pages into the new map by simulating
+* page faults.  The new pages are pageable.
 */
vm_fault_copy_entry(dst_map, src_map, dst_entry, src_entry,
fork_charge);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Nathan Whitehorn]

On 05/23/14 09:45, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:20, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:

On 05/23/14 08:36, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:

Is there any chance of finally switching the pkg abi identifiers to just
be uname -p?
-Nathan

Keeping asking won't make it happen, I have explained a large number of time 
why it
happened, why it is not easy for compatibility and why uname -p is still not
representing the ABI we do support, and what flexibility we need that the
current string offers to us.

if one is willing to do the work, please be my guess, just dig into the archives
and join the pkg development otherwise: no it won't happen before a while
because we have way too much work on the todo and this item is stored at the
very end of this todo.

regards,
Bapt

I'm happy to do the work, and have volunteered now many times. If uname
-p does not describe the ABI fully, then uname -p needs changes on the
relevant platforms. Which are they? What extra flexibility does the
string give you if uname -p describes the ABI completely?
-Nathan

just simple examples in armv6:
- eabi vs oabi

OABI is almost entirely dead, and will be entirely dead soon.

Maybe but still for now it is there and pkg has to work now


We don't provide packages for ARM. Also, no platforms have defaulted to 
OABI for a very long time. Not making a distinction was a deliberate 
decision of the ARM group, since it was meant to be a clean switchover.



- The different float abi (even if only one is supported for now others are
being worked on)

armv6 and armv6hf


- little endian vs big endian

armv6 and armv6eb (though I think armv6eb support in general has been
removed from the tree, but armeb is still there)

what about combinaison? armv6 + eb + hf?


That would be armv6hfeb, I assume, if FreeBSD actually supported 
big-endian ARMv6 at all, which it doesn't.



These all already exist.


the extras flexibilit is being able to say this binary do support freebsd i386
and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:*


arm was en example what about mips?


The same. There is mips64el, mipsel, mips, mips64, etc. that go through 
all possible combinations. This is true for all platforms and has been 
for ages. There was a brief period (2007-2010, I think) where some 
Tier-3 embedded platforms didn't have enough options, but that era was 
obscure and is long past.



The second one already would work, wouldn't it? Just replacing x86:64
with amd64 won't change anything. The first has to be outweighed by
being able to reliably figure out where to fetch from without a lookup
table.

We also added the kern.supported_archs sysctl last year to all branches
to enable figuring out which architectures a given running kernel
supports (e.g. amd64 and i386 on most amd64 systems). This was designed
specifically to help pkg figure out what packages it can install.

I know, it means that we can switch only when freebsd 8 and 9 are EOL which 
means
in a couple of years


Why does it mean that? That doesn't make sense. A couple of symlinks on 
the FTP server ensure compatibility. For the sysctl, it has been merged 
all the back to 7.



And it defeats cross installation (which is the reason why the ABI supported is
read from a binary and not from kernel)


No. That's the point of the sysctl.


and last thing is the current build packages should just work meaning that we
would need to have a kind of mapping table


Sure, as a compat measure. No reason to lock it in forever. You could 
also detect old-style strings with a warning and install them 
unconditionally. It's not a big deal.

-nathan
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Bryan Drewery]

On 2014-05-23 12:11, Nathan Whitehorn wrote:

On 05/23/14 09:45, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:20, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:

On 05/23/14 08:36, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:
Is there any chance of finally switching the pkg abi identifiers 
to just

be uname -p?
-Nathan
Keeping asking won't make it happen, I have explained a large 
number of time why it
happened, why it is not easy for compatibility and why uname -p is 
still not
representing the ABI we do support, and what flexibility we need 
that the

current string offers to us.

if one is willing to do the work, please be my guess, just dig 
into the archives
and join the pkg development otherwise: no it won't happen before 
a while
because we have way too much work on the todo and this item is 
stored at the

very end of this todo.

regards,
Bapt
I'm happy to do the work, and have volunteered now many times. If 
uname
-p does not describe the ABI fully, then uname -p needs changes on 
the

relevant platforms. Which are they? What extra flexibility does the
string give you if uname -p describes the ABI completely?
-Nathan

just simple examples in armv6:
- eabi vs oabi

OABI is almost entirely dead, and will be entirely dead soon.

Maybe but still for now it is there and pkg has to work now


We don't provide packages for ARM. Also, no platforms have defaulted
to OABI for a very long time. Not making a distinction was a
deliberate decision of the ARM group, since it was meant to be a clean
switchover.

- The different float abi (even if only one is supported for now 
others are

being worked on)

armv6 and armv6hf


- little endian vs big endian

armv6 and armv6eb (though I think armv6eb support in general has been
removed from the tree, but armeb is still there)

what about combinaison? armv6 + eb + hf?


That would be armv6hfeb, I assume, if FreeBSD actually supported
big-endian ARMv6 at all, which it doesn't.


These all already exist.

the extras flexibilit is being able to say this binary do support 
freebsd i386

and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:*


arm was en example what about mips?


The same. There is mips64el, mipsel, mips, mips64, etc. that go
through all possible combinations. This is true for all platforms and
has been for ages. There was a brief period (2007-2010, I think) where
some Tier-3 embedded platforms didn't have enough options, but that
era was obscure and is long past.


The second one already would work, wouldn't it? Just replacing x86:64
with amd64 won't change anything. The first has to be outweighed by
being able to reliably figure out where to fetch from without a 
lookup

table.

We also added the kern.supported_archs sysctl last year to all 
branches

to enable figuring out which architectures a given running kernel
supports (e.g. amd64 and i386 on most amd64 systems). This was 
designed

specifically to help pkg figure out what packages it can install.
I know, it means that we can switch only when freebsd 8 and 9 are EOL 
which means

in a couple of years


Why does it mean that? That doesn't make sense. A couple of symlinks
on the FTP server ensure compatibility. For the sysctl, it has been
merged all the back to 7.


Symlinks are irrelevant for pkg. It may fetch based on ABI in the URL,
but once it opens the package it also compares the ABI from the package
and repository to the ABI of /bin/sh on the system. So the symlink 
wouldn't

help.



And it defeats cross installation (which is the reason why the ABI 
supported is

read from a binary and not from kernel)


No. That's the point of the sysctl.

and last thing is the current build packages should just work meaning 
that we

would need to have a kind of mapping table


Sure, as a compat measure. No reason to lock it in forever. You could
also detect old-style strings with a warning and install them
unconditionally. It's not a big deal.
-nathan


--
Regards,
Bryan Drewery
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Baptiste Daroussin]

On Fri, May 23, 2014 at 10:11:47AM -0700, Nathan Whitehorn wrote:
 
 On 05/23/14 09:45, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:
  On 05/23/14 09:20, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:
  On 05/23/14 08:36, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:
  Is there any chance of finally switching the pkg abi identifiers to 
  just
  be uname -p?
  -Nathan
  Keeping asking won't make it happen, I have explained a large number of 
  time why it
  happened, why it is not easy for compatibility and why uname -p is 
  still not
  representing the ABI we do support, and what flexibility we need that 
  the
  current string offers to us.
 
  if one is willing to do the work, please be my guess, just dig into the 
  archives
  and join the pkg development otherwise: no it won't happen before a 
  while
  because we have way too much work on the todo and this item is stored 
  at the
  very end of this todo.
 
  regards,
  Bapt
  I'm happy to do the work, and have volunteered now many times. If uname
  -p does not describe the ABI fully, then uname -p needs changes on the
  relevant platforms. Which are they? What extra flexibility does the
  string give you if uname -p describes the ABI completely?
  -Nathan
  just simple examples in armv6:
  - eabi vs oabi
  OABI is almost entirely dead, and will be entirely dead soon.
  Maybe but still for now it is there and pkg has to work now
 
 We don't provide packages for ARM. Also, no platforms have defaulted to 
 OABI for a very long time. Not making a distinction was a deliberate 
 decision of the ARM group, since it was meant to be a clean switchover.
 
  - The different float abi (even if only one is supported for now others 
  are
  being worked on)
  armv6 and armv6hf
 
  - little endian vs big endian
  armv6 and armv6eb (though I think armv6eb support in general has been
  removed from the tree, but armeb is still there)
  what about combinaison? armv6 + eb + hf?
 
 That would be armv6hfeb, I assume, if FreeBSD actually supported 
 big-endian ARMv6 at all, which it doesn't.
 
  These all already exist.
 
  the extras flexibilit is being able to say this binary do support freebsd 
  i386
  and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:*
 
  arm was en example what about mips?
 
 The same. There is mips64el, mipsel, mips, mips64, etc. that go through 
 all possible combinations. This is true for all platforms and has been 
 for ages. There was a brief period (2007-2010, I think) where some 
 Tier-3 embedded platforms didn't have enough options, but that era was 
 obscure and is long past.
 
  The second one already would work, wouldn't it? Just replacing x86:64
  with amd64 won't change anything. The first has to be outweighed by
  being able to reliably figure out where to fetch from without a lookup
  table.
 
  We also added the kern.supported_archs sysctl last year to all branches
  to enable figuring out which architectures a given running kernel
  supports (e.g. amd64 and i386 on most amd64 systems). This was designed
  specifically to help pkg figure out what packages it can install.
  I know, it means that we can switch only when freebsd 8 and 9 are EOL which 
  means
  in a couple of years
 
 Why does it mean that? That doesn't make sense. A couple of symlinks on 
 the FTP server ensure compatibility. For the sysctl, it has been merged 
 all the back to 7.

So We can switch after 8.4 death which is a good news (except if you say that it
is in 8.4)
 
  And it defeats cross installation (which is the reason why the ABI 
  supported is
  read from a binary and not from kernel)
 
 No. That's the point of the sysctl.
I'm speaking of installing packages in a arm chroot on a amd64 host I will need
to know what arch could be supported by the content of the chroot.
 
  and last thing is the current build packages should just work meaning that 
  we
  would need to have a kind of mapping table
 
 Sure, as a compat measure. No reason to lock it in forever. You could 
 also detect old-style strings with a warning and install them 
 unconditionally. It's not a big deal.

sure but one has to write it :)

 -nathan
 

regards,
Bapt


pgpA0FtZzrqri.pgp
Description: PGP signature

Re: svn commit: r266587 - head/share/mk

[Don Lewis]

On 23 May, Warner Losh wrote:
 Author: imp
 Date: Fri May 23 14:34:22 2014
 New Revision: 266587
 URL: http://svnweb.freebsd.org/changeset/base/266587
 
 Log:
   Allow CC to not actually exist. During the ports INDEX run, all the
   Makefiles are evaluated without building things. In a normal build,
   the prerequisites would be built, and CC would be an actual thing. In
   an INDEX build, though, they don't exists. Redirect stderr to get rid
   of annoying messages, and assume that the compiler version is 0 if the
   actual compiler can't tell us. Do this in preference to guessing based
   on numbers because gcc410 might be 4.10, or 4.1.0 and without
   carefully crafted special knowledge we differentiate between them
   easily (also ming-gcc has no clues at all). Elsewhere, don't trust
   the compiler version if it is 0.
 
 Modified:
   head/share/mk/bsd.compiler.mk
 
 Modified: head/share/mk/bsd.compiler.mk
 ==
 --- head/share/mk/bsd.compiler.mk Fri May 23 14:32:57 2014
 (r266586)
 +++ head/share/mk/bsd.compiler.mk Fri May 23 14:34:22 2014
 (r266587)
 @@ -21,11 +21,11 @@
  .if !target(__bsd.compiler.mk__)
  __bsd.compiler.mk__:
  
 -_v!= ${CC} --version
 +_v!= ${CC} --version 2/dev/null || echo 0.0.0
  .if !defined(COMPILER_TYPE)
 -. if ${CC:T:Mgcc*}
 +. if ${CC:T:M*gcc*}
  COMPILER_TYPE:=  gcc  
 -. elif ${CC:T:Mclang}
 +. elif ${CC:T:M*clang*}
  COMPILER_TYPE:=  clang
  . elif ${_v:Mgcc}
  COMPILER_TYPE:=  gcc
 

Thanks!

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r266590 - stable/10/usr.sbin/pmcstat

[Ed Maste]

Author: emaste
Date: Fri May 23 17:46:00 2014
New Revision: 266590
URL: http://svnweb.freebsd.org/changeset/base/266590

Log:
  MFC r266208: Speed up pmcstat by improving string hash
  
In one case generating callgraph output from a 24MB system-wide sampling
data file took 17.4 seconds on average.  Profiling showed pmcstat
spending a lot of time in strcmp, due to hash collisions.
  
Replacing the XOR-only hash with FNV-1a reduces the run time for my
test by 40%.

Modified:
  stable/10/usr.sbin/pmcstat/pmcstat_log.c
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/usr.sbin/pmcstat/pmcstat_log.c
==
--- stable/10/usr.sbin/pmcstat/pmcstat_log.cFri May 23 16:46:50 2014
(r266589)
+++ stable/10/usr.sbin/pmcstat/pmcstat_log.cFri May 23 17:46:00 2014
(r266590)
@@ -307,10 +307,10 @@ pmcstat_stats_reset(int reset_global)
 static int
 pmcstat_string_compute_hash(const char *s)
 {
-   int hash;
+   unsigned hash;
 
-   for (hash = 0; *s; s++)
-   hash ^= *s;
+   for (hash = 2166136261; *s; s++)
+   hash = (hash ^ *s) * 16777619;
 
return (hash  PMCSTAT_HASH_MASK);
 }
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r266591 - stable/10/sys/vm

[Alan Cox]

Author: alc
Date: Fri May 23 17:47:49 2014
New Revision: 266591
URL: http://svnweb.freebsd.org/changeset/base/266591

Log:
  MFC r259107
Eliminate a redundant parameter to vm_radix_replace().
  
Improve the wording of the comment describing vm_radix_replace().

Modified:
  stable/10/sys/vm/vm_page.c
  stable/10/sys/vm/vm_radix.c
  stable/10/sys/vm/vm_radix.h
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/sys/vm/vm_page.c
==
--- stable/10/sys/vm/vm_page.c  Fri May 23 17:46:00 2014(r266590)
+++ stable/10/sys/vm/vm_page.c  Fri May 23 17:47:49 2014(r266591)
@@ -1200,7 +1200,7 @@ vm_page_replace(vm_page_t mnew, vm_objec
 
mnew-object = object;
mnew-pindex = pindex;
-   mold = vm_radix_replace(object-rtree, mnew, pindex);
+   mold = vm_radix_replace(object-rtree, mnew);
KASSERT(mold-queue == PQ_NONE,
(vm_page_replace: mold is on a paging queue));
 

Modified: stable/10/sys/vm/vm_radix.c
==
--- stable/10/sys/vm/vm_radix.c Fri May 23 17:46:00 2014(r266590)
+++ stable/10/sys/vm/vm_radix.c Fri May 23 17:47:49 2014(r266591)
@@ -788,20 +788,18 @@ vm_radix_reclaim_allnodes(struct vm_radi
 }
 
 /*
- * Replace an existing page into the trie with another one.
- * Panics if the replacing page is not present or if the new page has an
- * invalid key.
+ * Replace an existing page in the trie with another one.
+ * Panics if there is not an old page in the trie at the new page's index.
  */
 vm_page_t
-vm_radix_replace(struct vm_radix *rtree, vm_page_t newpage, vm_pindex_t index)
+vm_radix_replace(struct vm_radix *rtree, vm_page_t newpage)
 {
struct vm_radix_node *rnode;
vm_page_t m;
+   vm_pindex_t index;
int slot;
 
-   KASSERT(newpage-pindex == index, (%s: newpage index invalid,
-   __func__));
-
+   index = newpage-pindex;
rnode = vm_radix_getroot(rtree);
if (rnode == NULL)
panic(%s: replacing page on an empty trie, __func__);

Modified: stable/10/sys/vm/vm_radix.h
==
--- stable/10/sys/vm/vm_radix.h Fri May 23 17:46:00 2014(r266590)
+++ stable/10/sys/vm/vm_radix.h Fri May 23 17:47:49 2014(r266591)
@@ -43,8 +43,7 @@ vm_page_t vm_radix_lookup_ge(struct vm_r
 vm_page_t  vm_radix_lookup_le(struct vm_radix *rtree, vm_pindex_t index);
 void   vm_radix_reclaim_allnodes(struct vm_radix *rtree);
 void   vm_radix_remove(struct vm_radix *rtree, vm_pindex_t index);
-vm_page_t  vm_radix_replace(struct vm_radix *rtree, vm_page_t newpage,
-   vm_pindex_t index);
+vm_page_t  vm_radix_replace(struct vm_radix *rtree, vm_page_t newpage);
 
 #endif /* _KERNEL */
 #endif /* !_VM_RADIX_H_ */
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Nathan Whitehorn]

On 05/23/14 10:24, Bryan Drewery wrote:

On 2014-05-23 12:11, Nathan Whitehorn wrote:

On 05/23/14 09:45, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:20, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:

On 05/23/14 08:36, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:
Is there any chance of finally switching the pkg abi 
identifiers to just

be uname -p?
-Nathan
Keeping asking won't make it happen, I have explained a large 
number of time why it
happened, why it is not easy for compatibility and why uname -p 
is still not
representing the ABI we do support, and what flexibility we need 
that the

current string offers to us.

if one is willing to do the work, please be my guess, just dig 
into the archives
and join the pkg development otherwise: no it won't happen 
before a while
because we have way too much work on the todo and this item is 
stored at the

very end of this todo.

regards,
Bapt
I'm happy to do the work, and have volunteered now many times. If 
uname
-p does not describe the ABI fully, then uname -p needs changes 
on the

relevant platforms. Which are they? What extra flexibility does the
string give you if uname -p describes the ABI completely?
-Nathan

just simple examples in armv6:
- eabi vs oabi

OABI is almost entirely dead, and will be entirely dead soon.

Maybe but still for now it is there and pkg has to work now


We don't provide packages for ARM. Also, no platforms have defaulted
to OABI for a very long time. Not making a distinction was a
deliberate decision of the ARM group, since it was meant to be a clean
switchover.

- The different float abi (even if only one is supported for now 
others are

being worked on)

armv6 and armv6hf


- little endian vs big endian

armv6 and armv6eb (though I think armv6eb support in general has been
removed from the tree, but armeb is still there)

what about combinaison? armv6 + eb + hf?


That would be armv6hfeb, I assume, if FreeBSD actually supported
big-endian ARMv6 at all, which it doesn't.


These all already exist.

the extras flexibilit is being able to say this binary do support 
freebsd i386

and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:*


arm was en example what about mips?


The same. There is mips64el, mipsel, mips, mips64, etc. that go
through all possible combinations. This is true for all platforms and
has been for ages. There was a brief period (2007-2010, I think) where
some Tier-3 embedded platforms didn't have enough options, but that
era was obscure and is long past.


The second one already would work, wouldn't it? Just replacing x86:64
with amd64 won't change anything. The first has to be outweighed by
being able to reliably figure out where to fetch from without a lookup
table.

We also added the kern.supported_archs sysctl last year to all 
branches

to enable figuring out which architectures a given running kernel
supports (e.g. amd64 and i386 on most amd64 systems). This was 
designed

specifically to help pkg figure out what packages it can install.
I know, it means that we can switch only when freebsd 8 and 9 are 
EOL which means

in a couple of years


Why does it mean that? That doesn't make sense. A couple of symlinks
on the FTP server ensure compatibility. For the sysctl, it has been
merged all the back to 7.


Symlinks are irrelevant for pkg. It may fetch based on ABI in the URL,
but once it opens the package it also compares the ABI from the package
and repository to the ABI of /bin/sh on the system. So the symlink 
wouldn't

help.


That is a highly questionable design choice. Why not just check 
MACHINE_ARCH?


In any case, packages only exist for i386 and amd64 in the wild in a 
supported way. Those two can be special cased for compatibility in about 
two lines of code if you're worried about this.

-Nathan
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Nathan Whitehorn]

On 05/23/14 10:26, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 10:11:47AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:45, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:20, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:

On 05/23/14 08:36, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:

Is there any chance of finally switching the pkg abi identifiers to just
be uname -p?
-Nathan

Keeping asking won't make it happen, I have explained a large number of time 
why it
happened, why it is not easy for compatibility and why uname -p is still not
representing the ABI we do support, and what flexibility we need that the
current string offers to us.

if one is willing to do the work, please be my guess, just dig into the archives
and join the pkg development otherwise: no it won't happen before a while
because we have way too much work on the todo and this item is stored at the
very end of this todo.

regards,
Bapt

I'm happy to do the work, and have volunteered now many times. If uname
-p does not describe the ABI fully, then uname -p needs changes on the
relevant platforms. Which are they? What extra flexibility does the
string give you if uname -p describes the ABI completely?
-Nathan

just simple examples in armv6:
- eabi vs oabi

OABI is almost entirely dead, and will be entirely dead soon.

Maybe but still for now it is there and pkg has to work now

We don't provide packages for ARM. Also, no platforms have defaulted to
OABI for a very long time. Not making a distinction was a deliberate
decision of the ARM group, since it was meant to be a clean switchover.


- The different float abi (even if only one is supported for now others are
 being worked on)

armv6 and armv6hf


- little endian vs big endian

armv6 and armv6eb (though I think armv6eb support in general has been
removed from the tree, but armeb is still there)

what about combinaison? armv6 + eb + hf?

That would be armv6hfeb, I assume, if FreeBSD actually supported
big-endian ARMv6 at all, which it doesn't.


These all already exist.


the extras flexibilit is being able to say this binary do support freebsd i386
and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:*


arm was en example what about mips?

The same. There is mips64el, mipsel, mips, mips64, etc. that go through
all possible combinations. This is true for all platforms and has been
for ages. There was a brief period (2007-2010, I think) where some
Tier-3 embedded platforms didn't have enough options, but that era was
obscure and is long past.


The second one already would work, wouldn't it? Just replacing x86:64
with amd64 won't change anything. The first has to be outweighed by
being able to reliably figure out where to fetch from without a lookup
table.

We also added the kern.supported_archs sysctl last year to all branches
to enable figuring out which architectures a given running kernel
supports (e.g. amd64 and i386 on most amd64 systems). This was designed
specifically to help pkg figure out what packages it can install.

I know, it means that we can switch only when freebsd 8 and 9 are EOL which 
means
in a couple of years

Why does it mean that? That doesn't make sense. A couple of symlinks on
the FTP server ensure compatibility. For the sysctl, it has been merged
all the back to 7.

So We can switch after 8.4 death which is a good news (except if you say that it
is in 8.4)


It means we can do it now. Very few people install i386 packages on 
amd64 anyway. It means people with very old releases on old branches 
might face a warning in an unusual situation. Not a big deal. Since we 
only provide i386 and amd64 packages anyway, this is also a trivial 
special case if you really want that.



And it defeats cross installation (which is the reason why the ABI supported is
read from a binary and not from kernel)

No. That's the point of the sysctl.

I'm speaking of installing packages in a arm chroot on a amd64 host I will need
to know what arch could be supported by the content of the chroot.


uname -p in the chroot (I guess this is with qemu) should return the 
right answer, just as it does with an i386 chroot. If it doesn't, 
something is broken in the qemu user mode support.



and last thing is the current build packages should just work meaning that we
would need to have a kind of mapping table

Sure, as a compat measure. No reason to lock it in forever. You could
also detect old-style strings with a warning and install them
unconditionally. It's not a big deal.

sure but one has to write it :)



That's fine. I'm happy to.
-Nathan
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r266592 - stable/10/usr.sbin/bhyve

[John Baldwin]

Author: jhb
Date: Fri May 23 19:06:35 2014
New Revision: 266592
URL: http://svnweb.freebsd.org/changeset/base/266592

Log:
  MFC 260469:
  Fix issue with the virtio descriptor region being truncated
  if it was above 4GB.

Modified:
  stable/10/usr.sbin/bhyve/virtio.c
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/usr.sbin/bhyve/virtio.c
==
--- stable/10/usr.sbin/bhyve/virtio.c   Fri May 23 17:47:49 2014
(r266591)
+++ stable/10/usr.sbin/bhyve/virtio.c   Fri May 23 19:06:35 2014
(r266592)
@@ -160,7 +160,7 @@ vi_vq_init(struct virtio_softc *vs, uint
 
vq = vs-vs_queues[vs-vs_curq];
vq-vq_pfn = pfn;
-   phys = pfn  VRING_PFN;
+   phys = (uint64_t)pfn  VRING_PFN;
size = vring_size(vq-vq_qsize);
base = paddr_guest2host(vs-vs_pi-pi_vmctx, phys, size);
 
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Baptiste Daroussin]

On Fri, May 23, 2014 at 12:01:08PM -0700, Nathan Whitehorn wrote:
 
 On 05/23/14 10:26, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 10:11:47AM -0700, Nathan Whitehorn wrote:
  On 05/23/14 09:45, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:
  On 05/23/14 09:20, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:
  On 05/23/14 08:36, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:
  Is there any chance of finally switching the pkg abi identifiers to 
  just
  be uname -p?
  -Nathan
  Keeping asking won't make it happen, I have explained a large number 
  of time why it
  happened, why it is not easy for compatibility and why uname -p is 
  still not
  representing the ABI we do support, and what flexibility we need that 
  the
  current string offers to us.
 
  if one is willing to do the work, please be my guess, just dig into 
  the archives
  and join the pkg development otherwise: no it won't happen before a 
  while
  because we have way too much work on the todo and this item is stored 
  at the
  very end of this todo.
 
  regards,
  Bapt
  I'm happy to do the work, and have volunteered now many times. If uname
  -p does not describe the ABI fully, then uname -p needs changes on the
  relevant platforms. Which are they? What extra flexibility does the
  string give you if uname -p describes the ABI completely?
  -Nathan
  just simple examples in armv6:
  - eabi vs oabi
  OABI is almost entirely dead, and will be entirely dead soon.
  Maybe but still for now it is there and pkg has to work now
  We don't provide packages for ARM. Also, no platforms have defaulted to
  OABI for a very long time. Not making a distinction was a deliberate
  decision of the ARM group, since it was meant to be a clean switchover.
 
  - The different float abi (even if only one is supported for now others 
  are
   being worked on)
  armv6 and armv6hf
 
  - little endian vs big endian
  armv6 and armv6eb (though I think armv6eb support in general has been
  removed from the tree, but armeb is still there)
  what about combinaison? armv6 + eb + hf?
  That would be armv6hfeb, I assume, if FreeBSD actually supported
  big-endian ARMv6 at all, which it doesn't.
 
  These all already exist.
 
  the extras flexibilit is being able to say this binary do support 
  freebsd i386
  and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:*
 
  arm was en example what about mips?
  The same. There is mips64el, mipsel, mips, mips64, etc. that go through
  all possible combinations. This is true for all platforms and has been
  for ages. There was a brief period (2007-2010, I think) where some
  Tier-3 embedded platforms didn't have enough options, but that era was
  obscure and is long past.
 
  The second one already would work, wouldn't it? Just replacing x86:64
  with amd64 won't change anything. The first has to be outweighed by
  being able to reliably figure out where to fetch from without a lookup
  table.
 
  We also added the kern.supported_archs sysctl last year to all branches
  to enable figuring out which architectures a given running kernel
  supports (e.g. amd64 and i386 on most amd64 systems). This was designed
  specifically to help pkg figure out what packages it can install.
  I know, it means that we can switch only when freebsd 8 and 9 are EOL 
  which means
  in a couple of years
  Why does it mean that? That doesn't make sense. A couple of symlinks on
  the FTP server ensure compatibility. For the sysctl, it has been merged
  all the back to 7.
  So We can switch after 8.4 death which is a good news (except if you say 
  that it
  is in 8.4)
 
 It means we can do it now. Very few people install i386 packages on 
 amd64 anyway. It means people with very old releases on old branches 
 might face a warning in an unusual situation. Not a big deal. Since we 
 only provide i386 and amd64 packages anyway, this is also a trivial 
 special case if you really want that.
 
  And it defeats cross installation (which is the reason why the ABI 
  supported is
  read from a binary and not from kernel)
  No. That's the point of the sysctl.
  I'm speaking of installing packages in a arm chroot on a amd64 host I will 
  need
  to know what arch could be supported by the content of the chroot.
 
 uname -p in the chroot (I guess this is with qemu) should return the 
 right answer, just as it does with an i386 chroot. If it doesn't, 
 something is broken in the qemu user mode support.

nope that is not with qemu it is basically cross buildworld, install in a
destdir, install packages in that destdir which is a very common usage that a
lot do expect to work
 
  and last thing is the current build packages should just work meaning 
  that we
  would need to have a kind of mapping table
  Sure, as a compat measure. No reason to lock it in forever. You could
  also detect old-style 

svn commit: r266593 - in stable/10/sys/amd64/vmm: . intel

[John Baldwin]

Author: jhb
Date: Fri May 23 19:39:58 2014
New Revision: 266593
URL: http://svnweb.freebsd.org/changeset/base/266593

Log:
  MFC 260802,260836,260863,261001,261074,261617:
  Various fixes for NMI and interrupt injection.
  - If a VM-exit happens during an NMI injection then clear the NMI Blocking
bit in the Guest Interruptibility-state VMCS field.
  - If the guest exits due to a fault while it is executing IRET then restore
the state of Virtual NMI blocking in the guest's interruptibility-state
field before resuming the guest.
  - Inject a pending NMI only if NMI_BLOCKING, MOVSS_BLOCKING, STI_BLOCKING
are all clear. If any of these bits are set then enable NMI window
exiting and inject the NMI in the VM-exit handler.
  - Handle a VM-exit due to a NMI properly by vectoring to the host's NMI
handler via a software interrupt.
  - Set Interrupt Window Exiting in the case where there is a vector to be
injected into the vcpu but the VM-entry interruption information field
already has the valid bit set.
  - For VM-exits due to an NMI, handle the NMI with interrupts disabled in
addition to blocking by NMI already established by the VM-exit.

Modified:
  stable/10/sys/amd64/vmm/intel/vmcs.h
  stable/10/sys/amd64/vmm/intel/vmx.c
  stable/10/sys/amd64/vmm/vmm_stat.c
  stable/10/sys/amd64/vmm/vmm_stat.h
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/sys/amd64/vmm/intel/vmcs.h
==
--- stable/10/sys/amd64/vmm/intel/vmcs.hFri May 23 19:06:35 2014
(r266592)
+++ stable/10/sys/amd64/vmm/intel/vmcs.hFri May 23 19:39:58 2014
(r266593)
@@ -333,12 +333,18 @@ vmcs_write(uint32_t encoding, uint64_t v
 #defineEXIT_REASON_APIC_WRITE  56
 
 /*
+ * NMI unblocking due to IRET.
+ *
+ * Applies to VM-exits due to hardware exception or EPT fault.
+ */
+#defineEXIT_QUAL_NMIUDTI   (1  12)
+/*
  * VMCS interrupt information fields
  */
-#defineVMCS_INTR_INFO_VALID(1U  31)
-#defineVMCS_INTR_INFO_TYPE(info)   (((info)  8)  0x7)
-#defineVMCS_INTR_INFO_HW_INTR  (0  8)
-#defineVMCS_INTR_INFO_NMI  (2  8)
+#defineVMCS_INTR_VALID (1U  31)
+#defineVMCS_INTR_T_MASK0x700   /* Interruption-info 
type */
+#defineVMCS_INTR_T_HWINTR  (0  8)
+#defineVMCS_INTR_T_NMI (2  8)
 
 /*
  * VMCS IDT-Vectoring information fields

Modified: stable/10/sys/amd64/vmm/intel/vmx.c
==
--- stable/10/sys/amd64/vmm/intel/vmx.c Fri May 23 19:06:35 2014
(r266592)
+++ stable/10/sys/amd64/vmm/intel/vmx.c Fri May 23 19:39:58 2014
(r266593)
@@ -147,21 +147,6 @@ SYSCTL_INT(_hw_vmm_vmx, OID_AUTO, initia
   vmx_initialized, 0, Intel VMX initialized);
 
 /*
- * Virtual NMI blocking conditions.
- *
- * Some processor implementations also require NMI to be blocked if
- * the STI_BLOCKING bit is set. It is possible to detect this at runtime
- * based on the (exit_reason,exit_qual) tuple being set to 
- * (EXIT_REASON_INVAL_VMCS, EXIT_QUAL_NMI_WHILE_STI_BLOCKING).
- *
- * We take the easy way out and also include STI_BLOCKING as one of the
- * gating items for vNMI injection.
- */
-static uint64_t nmi_blocking_bits = VMCS_INTERRUPTIBILITY_MOVSS_BLOCKING |
-   VMCS_INTERRUPTIBILITY_NMI_BLOCKING |
-   VMCS_INTERRUPTIBILITY_STI_BLOCKING;
-
-/*
  * Optional capabilities
  */
 static int cap_halt_exit;
@@ -1031,121 +1016,168 @@ static void __inline
 vmx_set_int_window_exiting(struct vmx *vmx, int vcpu)
 {
 
-   vmx-cap[vcpu].proc_ctls |= PROCBASED_INT_WINDOW_EXITING;
-   vmcs_write(VMCS_PRI_PROC_BASED_CTLS, vmx-cap[vcpu].proc_ctls);
+   if ((vmx-cap[vcpu].proc_ctls  PROCBASED_INT_WINDOW_EXITING) == 0) {
+   vmx-cap[vcpu].proc_ctls |= PROCBASED_INT_WINDOW_EXITING;
+   vmcs_write(VMCS_PRI_PROC_BASED_CTLS, vmx-cap[vcpu].proc_ctls);
+   VCPU_CTR0(vmx-vm, vcpu, Enabling interrupt window exiting);
+   }
 }
 
 static void __inline
 vmx_clear_int_window_exiting(struct vmx *vmx, int vcpu)
 {
 
+   KASSERT((vmx-cap[vcpu].proc_ctls  PROCBASED_INT_WINDOW_EXITING) != 0,
+   (intr_window_exiting not set: %#x, vmx-cap[vcpu].proc_ctls));
vmx-cap[vcpu].proc_ctls = ~PROCBASED_INT_WINDOW_EXITING;
vmcs_write(VMCS_PRI_PROC_BASED_CTLS, vmx-cap[vcpu].proc_ctls);
+   VCPU_CTR0(vmx-vm, vcpu, Disabling interrupt window exiting);
 }
 
 static void __inline
 vmx_set_nmi_window_exiting(struct vmx *vmx, int vcpu)
 {
 
-   vmx-cap[vcpu].proc_ctls |= PROCBASED_NMI_WINDOW_EXITING;
-   vmcs_write(VMCS_PRI_PROC_BASED_CTLS, vmx-cap[vcpu].proc_ctls);
+   if ((vmx-cap[vcpu].proc_ctls  PROCBASED_NMI_WINDOW_EXITING) == 0) {
+   

svn commit: r266594 - in stable/10/sys: dev/drm2/radeon modules/drm2/radeonkms

[Jean-Sebastien Pedron]

Author: dumbbell
Date: Fri May 23 19:43:20 2014
New Revision: 266594
URL: http://svnweb.freebsd.org/changeset/base/266594

Log:
  drm/radeon: Add 32bit ioctls support
  
  This allows to run 32bit applications on a 64bit host. This was tested
  successfully with Wine (emulators/i386-wine-devel) and StarCraft II.
  
  Submitted by: Jan Kokemüller jan.kokemuel...@gmail.com

Modified:
  stable/10/sys/dev/drm2/radeon/radeon_drv.c
  stable/10/sys/dev/drm2/radeon/radeon_ioc32.c
  stable/10/sys/modules/drm2/radeonkms/Makefile
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/sys/dev/drm2/radeon/radeon_drv.c
==
--- stable/10/sys/dev/drm2/radeon/radeon_drv.c  Fri May 23 19:39:58 2014
(r266593)
+++ stable/10/sys/dev/drm2/radeon/radeon_drv.c  Fri May 23 19:43:20 2014
(r266594)
@@ -85,6 +85,10 @@ extern int radeon_get_crtc_scanoutpos(st
  int *vpos, int *hpos);
 extern struct drm_ioctl_desc radeon_ioctls_kms[];
 extern int radeon_max_kms_ioctl;
+#ifdef COMPAT_FREEBSD32
+extern struct drm_ioctl_desc radeon_compat_ioctls[];
+extern int radeon_num_compat_ioctls;
+#endif
 #ifdef DUMBBELL_WIP
 int radeon_mmap(struct file *filp, struct vm_area_struct *vma);
 #endif /* DUMBBELL_WIP */
@@ -466,6 +470,10 @@ radeon_attach(device_t kdev)
if (radeon_modeset == 1) {
kms_driver.driver_features |= DRIVER_MODESET;
kms_driver.max_ioctl = radeon_max_kms_ioctl;
+#ifdef COMPAT_FREEBSD32
+   kms_driver.compat_ioctls = radeon_compat_ioctls;
+   kms_driver.compat_ioctls_nr = radeon_num_compat_ioctls;
+#endif
radeon_register_atpx_handler();
}
dev-driver = kms_driver;

Modified: stable/10/sys/dev/drm2/radeon/radeon_ioc32.c
==
--- stable/10/sys/dev/drm2/radeon/radeon_ioc32.cFri May 23 19:39:58 
2014(r266593)
+++ stable/10/sys/dev/drm2/radeon/radeon_ioc32.cFri May 23 19:43:20 
2014(r266594)
@@ -31,10 +31,13 @@
 #include sys/cdefs.h
 __FBSDID($FreeBSD$);
 
-#include linux/compat.h
+#include opt_compat.h
 
-#include drm/drmP.h
-#include drm/radeon_drm.h
+#ifdef COMPAT_FREEBSD32
+
+#include dev/drm2/drmP.h
+#include dev/drm2/drm.h
+#include dev/drm2/radeon/radeon_drm.h
 #include radeon_drv.h
 
 typedef struct drm_radeon_init32 {
@@ -60,42 +63,37 @@ typedef struct drm_radeon_init32 {
u32 gart_textures_offset;
 } drm_radeon_init32_t;
 
-static int compat_radeon_cp_init(struct file *file, unsigned int cmd,
-unsigned long arg)
+static int compat_radeon_cp_init(struct drm_device *dev, void *arg,
+struct drm_file *file_priv)
 {
-   drm_radeon_init32_t init32;
-   drm_radeon_init_t __user *init;
+   drm_radeon_init32_t *init32;
+   drm_radeon_init_t __user init;
 
-   if (copy_from_user(init32, (void __user *)arg, sizeof(init32)))
-   return -EFAULT;
+   init32 = arg;
 
-   init = compat_alloc_user_space(sizeof(*init));
-   if (!access_ok(VERIFY_WRITE, init, sizeof(*init))
-   || __put_user(init32.func, init-func)
-   || __put_user(init32.sarea_priv_offset, init-sarea_priv_offset)
-   || __put_user(init32.is_pci, init-is_pci)
-   || __put_user(init32.cp_mode, init-cp_mode)
-   || __put_user(init32.gart_size, init-gart_size)
-   || __put_user(init32.ring_size, init-ring_size)
-   || __put_user(init32.usec_timeout, init-usec_timeout)
-   || __put_user(init32.fb_bpp, init-fb_bpp)
-   || __put_user(init32.front_offset, init-front_offset)
-   || __put_user(init32.front_pitch, init-front_pitch)
-   || __put_user(init32.back_offset, init-back_offset)
-   || __put_user(init32.back_pitch, init-back_pitch)
-   || __put_user(init32.depth_bpp, init-depth_bpp)
-   || __put_user(init32.depth_offset, init-depth_offset)
-   || __put_user(init32.depth_pitch, init-depth_pitch)
-   || __put_user(init32.fb_offset, init-fb_offset)
-   || __put_user(init32.mmio_offset, init-mmio_offset)
-   || __put_user(init32.ring_offset, init-ring_offset)
-   || __put_user(init32.ring_rptr_offset, init-ring_rptr_offset)
-   || __put_user(init32.buffers_offset, init-buffers_offset)
-   || __put_user(init32.gart_textures_offset,
- init-gart_textures_offset))
-   return -EFAULT;
+   init.func = init32-func;
+   init.sarea_priv_offset = (unsigned long)init32-sarea_priv_offset;
+   init.is_pci = init32-is_pci;
+   init.cp_mode = init32-cp_mode;
+   init.gart_size = init32-gart_size;
+   init.ring_size = init32-ring_size;
+   init.usec_timeout = init32-usec_timeout;
+   init.fb_bpp = init32-fb_bpp;
+ 

svn commit: r266595 - in head: sys/amd64/include sys/amd64/vmm usr.sbin/bhyve

[Neel Natu]

Author: neel
Date: Fri May 23 19:59:14 2014
New Revision: 266595
URL: http://svnweb.freebsd.org/changeset/base/266595

Log:
  Check for alignment check violation when processing in/out string 
instructions.

Modified:
  head/sys/amd64/include/vmm_instruction_emul.h
  head/sys/amd64/vmm/vmm_instruction_emul.c
  head/sys/amd64/vmm/vmm_ioport.c
  head/usr.sbin/bhyve/inout.c

Modified: head/sys/amd64/include/vmm_instruction_emul.h
==
--- head/sys/amd64/include/vmm_instruction_emul.h   Fri May 23 19:43:20 
2014(r266594)
+++ head/sys/amd64/include/vmm_instruction_emul.h   Fri May 23 19:59:14 
2014(r266595)
@@ -116,6 +116,14 @@ int vmm_emulate_instruction(void *vm, in
 int vie_update_register(void *vm, int vcpuid, enum vm_reg_name reg,
 uint64_t val, int size);
 
+/*
+ * Returns 1 if an alignment check exception should be injected and 0 
otherwise.
+ */
+int vie_alignment_check(int cpl, int operand_size, uint64_t cr0,
+uint64_t rflags, uint64_t gla);
+
+uint64_t vie_size2mask(int size);
+
 #ifdef _KERNEL
 /*
  * APIs to fetch and decode the instruction from nested page fault handler.
@@ -139,8 +147,6 @@ int vmm_gla2gpa(struct vm *vm, int vcpui
 
 void vie_init(struct vie *vie);
 
-uint64_t vie_size2mask(int size);
-
 uint64_t vie_segbase(enum vm_reg_name segment, enum vie_cpu_mode cpu_mode,
 const struct seg_desc *desc);
 

Modified: head/sys/amd64/vmm/vmm_instruction_emul.c
==
--- head/sys/amd64/vmm/vmm_instruction_emul.c   Fri May 23 19:43:20 2014
(r266594)
+++ head/sys/amd64/vmm/vmm_instruction_emul.c   Fri May 23 19:59:14 2014
(r266595)
@@ -47,9 +47,14 @@ __FBSDID($FreeBSD$);
 
 #include machine/vmm.h
 
+#include assert.h
 #include vmmapi.h
+#defineKASSERT(exp,msg)assert((exp))
 #endif /* _KERNEL */
 
+#include x86/psl.h
+#include x86/specialreg.h
+
 /* struct vie_op.op_type */
 enum {
VIE_OP_TYPE_NONE = 0,
@@ -561,6 +566,27 @@ vmm_emulate_instruction(void *vm, int vc
return (error);
 }
 
+int
+vie_alignment_check(int cpl, int size, uint64_t cr0, uint64_t rf, uint64_t gla)
+{
+   KASSERT(size == 1 || size == 2 || size == 4 || size == 8,
+   (%s: invalid size %d, __func__, size));
+   KASSERT(cpl = 0  cpl = 3, (%s: invalid cpl %d, __func__, cpl));
+
+   if (cpl != 3 || (cr0  CR0_AM) == 0 || (rf  PSL_AC) == 0)
+   return (0);
+
+   return ((gla  (size - 1)) ? 1 : 0);
+}
+
+uint64_t
+vie_size2mask(int size)
+{
+   KASSERT(size == 1 || size == 2 || size == 4 || size == 8,
+   (vie_size2mask: invalid size %d, size));
+   return (size2mask[size]);
+}
+
 #ifdef _KERNEL
 void
 vie_init(struct vie *vie)
@@ -1220,14 +1246,6 @@ vmm_decode_instruction(struct vm *vm, in
 }
 
 uint64_t
-vie_size2mask(int size)
-{
-   KASSERT(size == 1 || size == 2 || size == 4 || size == 8,
-   (vie_size2mask: invalid size %d, size));
-   return (size2mask[size]);
-}
-
-uint64_t
 vie_segbase(enum vm_reg_name seg, enum vie_cpu_mode cpu_mode,
 const struct seg_desc *desc)
 {

Modified: head/sys/amd64/vmm/vmm_ioport.c
==
--- head/sys/amd64/vmm/vmm_ioport.c Fri May 23 19:43:20 2014
(r266594)
+++ head/sys/amd64/vmm/vmm_ioport.c Fri May 23 19:59:14 2014
(r266595)
@@ -144,7 +144,7 @@ emulate_inout_str(struct vm *vm, int vcp
 {
struct vm_inout_str *vis;
uint64_t gla, index, segbase;
-   int bytes, error, in;
+   int error, in;
 
vis = vmexit-u.inout_str;
in = vis-inout.in;
@@ -162,14 +162,10 @@ emulate_inout_str(struct vm *vm, int vcp
 
/*
 * XXX
-* inout string emulation only supported in 64-bit mode and only
-* for byte instructions.
+* inout string emulation only supported in 64-bit mode.
 *
 * The #GP(0) fault conditions described above don't apply in
 * 64-bit mode.
-*
-* The #AC(0) fault condition described above does not apply
-* because byte accesses don't have alignment constraints.
 */
if (vis-cpu_mode != CPU_MODE_64BIT) { 
VCPU_CTR1(vm, vcpuid, ins/outs not emulated in cpu mode %d,
@@ -177,13 +173,6 @@ emulate_inout_str(struct vm *vm, int vcp
return (EINVAL);
}
 
-   bytes = vis-inout.bytes;
-   if (bytes != 1) {
-   VCPU_CTR1(vm, vcpuid, ins/outs operand size %d not supported,
-   bytes);
-   return (EINVAL);
-   }
-
/*
 * XXX insb/insw/insd instructions not emulated at this time.
 */

Modified: head/usr.sbin/bhyve/inout.c
==
--- head/usr.sbin/bhyve/inout.c Fri May 23 19:43:20 2014(r266594)
+++ 

svn commit: r266596 - in head/sys: dev/cxgbe/tom netinet

[Bjoern A. Zeeb]

Author: bz
Date: Fri May 23 20:15:01 2014
New Revision: 266596
URL: http://svnweb.freebsd.org/changeset/base/266596

Log:
  Move the tcp_fields_to_host() and tcp_fields_to_net() (inline)
  functions to the tcp_var.h header file in order to avoid further
  duplication with upcoming commits.
  
  Reviewed by:  np
  MFC after:2 weeks

Modified:
  head/sys/dev/cxgbe/tom/t4_listen.c
  head/sys/netinet/tcp_input.c
  head/sys/netinet/tcp_var.h

Modified: head/sys/dev/cxgbe/tom/t4_listen.c
==
--- head/sys/dev/cxgbe/tom/t4_listen.c  Fri May 23 19:59:14 2014
(r266595)
+++ head/sys/dev/cxgbe/tom/t4_listen.c  Fri May 23 20:15:01 2014
(r266596)
@@ -1052,17 +1052,6 @@ calc_opt2p(struct adapter *sc, struct po
return htobe32(opt2);
 }
 
-/* XXX: duplication. */
-static inline void
-tcp_fields_to_host(struct tcphdr *th)
-{
-
-   th-th_seq = ntohl(th-th_seq);
-   th-th_ack = ntohl(th-th_ack);
-   th-th_win = ntohs(th-th_win);
-   th-th_urp = ntohs(th-th_urp);
-}
-
 static void
 pass_accept_req_to_protohdrs(const struct mbuf *m, struct in_conninfo *inc,
 struct tcphdr *th)

Modified: head/sys/netinet/tcp_input.c
==
--- head/sys/netinet/tcp_input.cFri May 23 19:59:14 2014
(r266595)
+++ head/sys/netinet/tcp_input.cFri May 23 20:15:01 2014
(r266596)
@@ -455,27 +455,7 @@ cc_post_recovery(struct tcpcb *tp, struc
tp-t_bytes_acked = 0;
 }
 
-static inline void
-tcp_fields_to_host(struct tcphdr *th)
-{
-
-   th-th_seq = ntohl(th-th_seq);
-   th-th_ack = ntohl(th-th_ack);
-   th-th_win = ntohs(th-th_win);
-   th-th_urp = ntohs(th-th_urp);
-}
-
 #ifdef TCP_SIGNATURE
-static inline void
-tcp_fields_to_net(struct tcphdr *th)
-{
-
-   th-th_seq = htonl(th-th_seq);
-   th-th_ack = htonl(th-th_ack);
-   th-th_win = htons(th-th_win);
-   th-th_urp = htons(th-th_urp);
-}
-
 static inline int
 tcp_signature_verify_input(struct mbuf *m, int off0, int tlen, int optlen,
 struct tcpopt *to, struct tcphdr *th, u_int tcpbflag)

Modified: head/sys/netinet/tcp_var.h
==
--- head/sys/netinet/tcp_var.h  Fri May 23 19:59:14 2014(r266595)
+++ head/sys/netinet/tcp_var.h  Fri May 23 20:15:01 2014(r266596)
@@ -719,6 +719,27 @@ u_long  tcp_seq_subtract(u_long, u_long 
 
 void   cc_cong_signal(struct tcpcb *tp, struct tcphdr *th, uint32_t type);
 
+static inline void
+tcp_fields_to_host(struct tcphdr *th)
+{
+
+   th-th_seq = ntohl(th-th_seq);
+   th-th_ack = ntohl(th-th_ack);
+   th-th_win = ntohs(th-th_win);
+   th-th_urp = ntohs(th-th_urp);
+}
+
+#ifdef TCP_SIGNATURE
+static inline void
+tcp_fields_to_net(struct tcphdr *th)
+{
+
+   th-th_seq = htonl(th-th_seq);
+   th-th_ack = htonl(th-th_ack);
+   th-th_win = htons(th-th_win);
+   th-th_urp = htons(th-th_urp);
+}
+#endif
 #endif /* _KERNEL */
 
 #endif /* _NETINET_TCP_VAR_H_ */
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

svn commit: r266597 - head/sys/netinet

[Bjoern A. Zeeb]

Author: bz
Date: Fri May 23 21:12:33 2014
New Revision: 266597
URL: http://svnweb.freebsd.org/changeset/base/266597

Log:
  Remove the prototypes for things that are no longer file local but were
  moved to the header file.
  
  Pointy hat to:clang || bz
  MFC after:2 weeks
  X-MFC with:   r266596
  Reported by:  gcc build of sparc64

Modified:
  head/sys/netinet/tcp_input.c

Modified: head/sys/netinet/tcp_input.c
==
--- head/sys/netinet/tcp_input.cFri May 23 20:15:01 2014
(r266596)
+++ head/sys/netinet/tcp_input.cFri May 23 21:12:33 2014
(r266597)
@@ -229,9 +229,7 @@ static void  tcp_pulloutofband(struct so
 struct tcphdr *, struct mbuf *, int);
 static void tcp_xmit_timer(struct tcpcb *, int);
 static void tcp_newreno_partial_ack(struct tcpcb *, struct tcphdr *);
-static void inline tcp_fields_to_host(struct tcphdr *);
 #ifdef TCP_SIGNATURE
-static void inline tcp_fields_to_net(struct tcphdr *);
 static int inline  tcp_signature_verify_input(struct mbuf *, int, int,
int, struct tcpopt *, struct tcphdr *, u_int);
 #endif
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Nathan Whitehorn]

On 05/23/14 12:27, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 12:01:08PM -0700, Nathan Whitehorn wrote:

On 05/23/14 10:26, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 10:11:47AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:45, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:20, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:

On 05/23/14 08:36, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:

Is there any chance of finally switching the pkg abi identifiers to just
be uname -p?
-Nathan

Keeping asking won't make it happen, I have explained a large number of time 
why it
happened, why it is not easy for compatibility and why uname -p is still not
representing the ABI we do support, and what flexibility we need that the
current string offers to us.

if one is willing to do the work, please be my guess, just dig into the archives
and join the pkg development otherwise: no it won't happen before a while
because we have way too much work on the todo and this item is stored at the
very end of this todo.

regards,
Bapt

I'm happy to do the work, and have volunteered now many times. If uname
-p does not describe the ABI fully, then uname -p needs changes on the
relevant platforms. Which are they? What extra flexibility does the
string give you if uname -p describes the ABI completely?
-Nathan

just simple examples in armv6:
- eabi vs oabi

OABI is almost entirely dead, and will be entirely dead soon.

Maybe but still for now it is there and pkg has to work now

We don't provide packages for ARM. Also, no platforms have defaulted to
OABI for a very long time. Not making a distinction was a deliberate
decision of the ARM group, since it was meant to be a clean switchover.


- The different float abi (even if only one is supported for now others are
  being worked on)

armv6 and armv6hf


- little endian vs big endian

armv6 and armv6eb (though I think armv6eb support in general has been
removed from the tree, but armeb is still there)

what about combinaison? armv6 + eb + hf?

That would be armv6hfeb, I assume, if FreeBSD actually supported
big-endian ARMv6 at all, which it doesn't.


These all already exist.


the extras flexibilit is being able to say this binary do support freebsd i386
and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:*


arm was en example what about mips?

The same. There is mips64el, mipsel, mips, mips64, etc. that go through
all possible combinations. This is true for all platforms and has been
for ages. There was a brief period (2007-2010, I think) where some
Tier-3 embedded platforms didn't have enough options, but that era was
obscure and is long past.


The second one already would work, wouldn't it? Just replacing x86:64
with amd64 won't change anything. The first has to be outweighed by
being able to reliably figure out where to fetch from without a lookup
table.

We also added the kern.supported_archs sysctl last year to all branches
to enable figuring out which architectures a given running kernel
supports (e.g. amd64 and i386 on most amd64 systems). This was designed
specifically to help pkg figure out what packages it can install.

I know, it means that we can switch only when freebsd 8 and 9 are EOL which 
means
in a couple of years

Why does it mean that? That doesn't make sense. A couple of symlinks on
the FTP server ensure compatibility. For the sysctl, it has been merged
all the back to 7.

So We can switch after 8.4 death which is a good news (except if you say that it
is in 8.4)

It means we can do it now. Very few people install i386 packages on
amd64 anyway. It means people with very old releases on old branches
might face a warning in an unusual situation. Not a big deal. Since we
only provide i386 and amd64 packages anyway, this is also a trivial
special case if you really want that.


And it defeats cross installation (which is the reason why the ABI supported is
read from a binary and not from kernel)

No. That's the point of the sysctl.

I'm speaking of installing packages in a arm chroot on a amd64 host I will need
to know what arch could be supported by the content of the chroot.

uname -p in the chroot (I guess this is with qemu) should return the
right answer, just as it does with an i386 chroot. If it doesn't,
something is broken in the qemu user mode support.

nope that is not with qemu it is basically cross buildworld, install in a
destdir, install packages in that destdir which is a very common usage that a
lot do expect to work



Knowing a priori which architectures are supported by a chroot based 
on ELF type of /bin/sh doesn't even work. How do you know what kernel 
will be running in there and how it will be configured? You don't. IA64 
can -- sometimes -- run i386 binaries, for example. amd64 may or may not 
be able to run i386, depending on kernel options.


In any 

Re: svn commit: r266553 - head/release/scripts

[Bryan Drewery]

On 2014-05-23 16:19, Nathan Whitehorn wrote:

On 05/23/14 12:27, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 12:01:08PM -0700, Nathan Whitehorn wrote:

On 05/23/14 10:26, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 10:11:47AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:45, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:20, Baptiste Daroussin wrote:
On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn 
wrote:

On 05/23/14 08:36, Baptiste Daroussin wrote:
On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn 
wrote:
Is there any chance of finally switching the pkg abi 
identifiers to just

be uname -p?
-Nathan
Keeping asking won't make it happen, I have explained a large 
number of time why it
happened, why it is not easy for compatibility and why uname 
-p is still not
representing the ABI we do support, and what flexibility we 
need that the

current string offers to us.

if one is willing to do the work, please be my guess, just dig 
into the archives
and join the pkg development otherwise: no it won't happen 
before a while
because we have way too much work on the todo and this item is 
stored at the

very end of this todo.

regards,
Bapt
I'm happy to do the work, and have volunteered now many times. 
If uname
-p does not describe the ABI fully, then uname -p needs changes 
on the
relevant platforms. Which are they? What extra flexibility does 
the

string give you if uname -p describes the ABI completely?
-Nathan

just simple examples in armv6:
- eabi vs oabi

OABI is almost entirely dead, and will be entirely dead soon.

Maybe but still for now it is there and pkg has to work now
We don't provide packages for ARM. Also, no platforms have 
defaulted to
OABI for a very long time. Not making a distinction was a 
deliberate
decision of the ARM group, since it was meant to be a clean 
switchover.


- The different float abi (even if only one is supported for now 
others are

  being worked on)

armv6 and armv6hf


- little endian vs big endian
armv6 and armv6eb (though I think armv6eb support in general has 
been

removed from the tree, but armeb is still there)

what about combinaison? armv6 + eb + hf?

That would be armv6hfeb, I assume, if FreeBSD actually supported
big-endian ARMv6 at all, which it doesn't.


These all already exist.

the extras flexibilit is being able to say this binary do 
support freebsd i386
and amd64 in one key, freebsd:9:x86:*, or or all arches 
freebsd:10:*



arm was en example what about mips?
The same. There is mips64el, mipsel, mips, mips64, etc. that go 
through
all possible combinations. This is true for all platforms and has 
been

for ages. There was a brief period (2007-2010, I think) where some
Tier-3 embedded platforms didn't have enough options, but that era 
was

obscure and is long past.

The second one already would work, wouldn't it? Just replacing 
x86:64
with amd64 won't change anything. The first has to be outweighed 
by
being able to reliably figure out where to fetch from without a 
lookup

table.

We also added the kern.supported_archs sysctl last year to all 
branches

to enable figuring out which architectures a given running kernel
supports (e.g. amd64 and i386 on most amd64 systems). This was 
designed

specifically to help pkg figure out what packages it can install.
I know, it means that we can switch only when freebsd 8 and 9 are 
EOL which means

in a couple of years
Why does it mean that? That doesn't make sense. A couple of 
symlinks on
the FTP server ensure compatibility. For the sysctl, it has been 
merged

all the back to 7.
So We can switch after 8.4 death which is a good news (except if you 
say that it

is in 8.4)

It means we can do it now. Very few people install i386 packages on
amd64 anyway. It means people with very old releases on old branches
might face a warning in an unusual situation. Not a big deal. Since 
we

only provide i386 and amd64 packages anyway, this is also a trivial
special case if you really want that.

And it defeats cross installation (which is the reason why the ABI 
supported is

read from a binary and not from kernel)

No. That's the point of the sysctl.
I'm speaking of installing packages in a arm chroot on a amd64 host 
I will need

to know what arch could be supported by the content of the chroot.

uname -p in the chroot (I guess this is with qemu) should return the
right answer, just as it does with an i386 chroot. If it doesn't,
something is broken in the qemu user mode support.
nope that is not with qemu it is basically cross buildworld, install 
in a
destdir, install packages in that destdir which is a very common usage 
that a

lot do expect to work



Knowing a priori which architectures are supported by a chroot based
on ELF type of /bin/sh doesn't even work. How do you know what kernel
will be running in there and how it will be configured? You don't.
IA64 can -- sometimes -- run i386 binaries, for example. 

Re: svn commit: r266553 - head/release/scripts

[John-Mark Gurney]

Bryan Drewery wrote this message on Fri, May 23, 2014 at 16:34 -0500:
 On 2014-05-23 16:19, Nathan Whitehorn wrote:
 Knowing a priori which architectures are supported by a chroot based
 on ELF type of /bin/sh doesn't even work. How do you know what kernel
 will be running in there and how it will be configured? You don't.
 IA64 can -- sometimes -- run i386 binaries, for example. amd64 may or
 may not be able to run i386, depending on kernel options.
 
 
 You're assuming that you would only use a chroot to RUN things. This is
 also useful for building images. Install a world into a chroot, run
 pkg -c install whatever and it picks the right ABI. Just an example.

Will there be a mode to output an mtree file (or append to one) w/ the
correct permissions?

We are slowly moving to not requiring root to build images, and if you
now need to have root to chroot or chown files, then it won't be as
useful for building images...

Right now I'm looking at tools/tools/makeroot that allows merging of
mtree files, which will allow us to easily customize the built image..

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Nathan Whitehorn]

On 05/23/14 14:34, Bryan Drewery wrote:

On 2014-05-23 16:19, Nathan Whitehorn wrote:

On 05/23/14 12:27, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 12:01:08PM -0700, Nathan Whitehorn wrote:

On 05/23/14 10:26, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 10:11:47AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:45, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:20, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:

On 05/23/14 08:36, Baptiste Daroussin wrote:
On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn 
wrote:
Is there any chance of finally switching the pkg abi 
identifiers to just

be uname -p?
-Nathan
Keeping asking won't make it happen, I have explained a 
large number of time why it
happened, why it is not easy for compatibility and why uname 
-p is still not
representing the ABI we do support, and what flexibility we 
need that the

current string offers to us.

if one is willing to do the work, please be my guess, just 
dig into the archives
and join the pkg development otherwise: no it won't happen 
before a while
because we have way too much work on the todo and this item 
is stored at the

very end of this todo.

regards,
Bapt
I'm happy to do the work, and have volunteered now many 
times. If uname
-p does not describe the ABI fully, then uname -p needs 
changes on the
relevant platforms. Which are they? What extra flexibility 
does the

string give you if uname -p describes the ABI completely?
-Nathan

just simple examples in armv6:
- eabi vs oabi

OABI is almost entirely dead, and will be entirely dead soon.

Maybe but still for now it is there and pkg has to work now
We don't provide packages for ARM. Also, no platforms have 
defaulted to

OABI for a very long time. Not making a distinction was a deliberate
decision of the ARM group, since it was meant to be a clean 
switchover.


- The different float abi (even if only one is supported for 
now others are

  being worked on)

armv6 and armv6hf


- little endian vs big endian
armv6 and armv6eb (though I think armv6eb support in general 
has been

removed from the tree, but armeb is still there)

what about combinaison? armv6 + eb + hf?

That would be armv6hfeb, I assume, if FreeBSD actually supported
big-endian ARMv6 at all, which it doesn't.


These all already exist.

the extras flexibilit is being able to say this binary do 
support freebsd i386
and amd64 in one key, freebsd:9:x86:*, or or all arches 
freebsd:10:*



arm was en example what about mips?
The same. There is mips64el, mipsel, mips, mips64, etc. that go 
through
all possible combinations. This is true for all platforms and has 
been

for ages. There was a brief period (2007-2010, I think) where some
Tier-3 embedded platforms didn't have enough options, but that 
era was

obscure and is long past.

The second one already would work, wouldn't it? Just replacing 
x86:64
with amd64 won't change anything. The first has to be 
outweighed by
being able to reliably figure out where to fetch from without a 
lookup

table.

We also added the kern.supported_archs sysctl last year to all 
branches

to enable figuring out which architectures a given running kernel
supports (e.g. amd64 and i386 on most amd64 systems). This was 
designed

specifically to help pkg figure out what packages it can install.
I know, it means that we can switch only when freebsd 8 and 9 
are EOL which means

in a couple of years
Why does it mean that? That doesn't make sense. A couple of 
symlinks on
the FTP server ensure compatibility. For the sysctl, it has been 
merged

all the back to 7.
So We can switch after 8.4 death which is a good news (except if 
you say that it

is in 8.4)

It means we can do it now. Very few people install i386 packages on
amd64 anyway. It means people with very old releases on old branches
might face a warning in an unusual situation. Not a big deal. Since we
only provide i386 and amd64 packages anyway, this is also a trivial
special case if you really want that.

And it defeats cross installation (which is the reason why the 
ABI supported is

read from a binary and not from kernel)

No. That's the point of the sysctl.
I'm speaking of installing packages in a arm chroot on a amd64 
host I will need

to know what arch could be supported by the content of the chroot.

uname -p in the chroot (I guess this is with qemu) should return the
right answer, just as it does with an i386 chroot. If it doesn't,
something is broken in the qemu user mode support.
nope that is not with qemu it is basically cross buildworld, install 
in a
destdir, install packages in that destdir which is a very common 
usage that a

lot do expect to work



Knowing a priori which architectures are supported by a chroot based
on ELF type of /bin/sh doesn't even work. How do you know what kernel
will be running in there and how it will be configured? You don't.
IA64 can -- 

Re: svn commit: r266553 - head/release/scripts

[Warner Losh]

On May 23, 2014, at 3:34 PM, Bryan Drewery bdrew...@freebsd.org wrote:

 On 2014-05-23 16:19, Nathan Whitehorn wrote:
 On 05/23/14 12:27, Baptiste Daroussin wrote:
 On Fri, May 23, 2014 at 12:01:08PM -0700, Nathan Whitehorn wrote:
 On 05/23/14 10:26, Baptiste Daroussin wrote:
 On Fri, May 23, 2014 at 10:11:47AM -0700, Nathan Whitehorn wrote:
 On 05/23/14 09:45, Baptiste Daroussin wrote:
 On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:
 On 05/23/14 09:20, Baptiste Daroussin wrote:
 On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:
 On 05/23/14 08:36, Baptiste Daroussin wrote:
 On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:
 Is there any chance of finally switching the pkg abi identifiers 
 to just
 be uname -p?
 -Nathan
 Keeping asking won't make it happen, I have explained a large 
 number of time why it
 happened, why it is not easy for compatibility and why uname -p is 
 still not
 representing the ABI we do support, and what flexibility we need 
 that the
 current string offers to us.
 if one is willing to do the work, please be my guess, just dig into 
 the archives
 and join the pkg development otherwise: no it won't happen before a 
 while
 because we have way too much work on the todo and this item is 
 stored at the
 very end of this todo.
 regards,
 Bapt
 I'm happy to do the work, and have volunteered now many times. If 
 uname
 -p does not describe the ABI fully, then uname -p needs changes on 
 the
 relevant platforms. Which are they? What extra flexibility does the
 string give you if uname -p describes the ABI completely?
 -Nathan
 just simple examples in armv6:
 - eabi vs oabi
 OABI is almost entirely dead, and will be entirely dead soon.
 Maybe but still for now it is there and pkg has to work now
 We don't provide packages for ARM. Also, no platforms have defaulted to
 OABI for a very long time. Not making a distinction was a deliberate
 decision of the ARM group, since it was meant to be a clean switchover.
 - The different float abi (even if only one is supported for now 
 others are
  being worked on)
 armv6 and armv6hf
 - little endian vs big endian
 armv6 and armv6eb (though I think armv6eb support in general has been
 removed from the tree, but armeb is still there)
 what about combinaison? armv6 + eb + hf?
 That would be armv6hfeb, I assume, if FreeBSD actually supported
 big-endian ARMv6 at all, which it doesn't.
 These all already exist.
 the extras flexibilit is being able to say this binary do support 
 freebsd i386
 and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:*
 arm was en example what about mips?
 The same. There is mips64el, mipsel, mips, mips64, etc. that go through
 all possible combinations. This is true for all platforms and has been
 for ages. There was a brief period (2007-2010, I think) where some
 Tier-3 embedded platforms didn't have enough options, but that era was
 obscure and is long past.
 The second one already would work, wouldn't it? Just replacing x86:64
 with amd64 won't change anything. The first has to be outweighed by
 being able to reliably figure out where to fetch from without a lookup
 table.
 We also added the kern.supported_archs sysctl last year to all branches
 to enable figuring out which architectures a given running kernel
 supports (e.g. amd64 and i386 on most amd64 systems). This was designed
 specifically to help pkg figure out what packages it can install.
 I know, it means that we can switch only when freebsd 8 and 9 are EOL 
 which means
 in a couple of years
 Why does it mean that? That doesn't make sense. A couple of symlinks on
 the FTP server ensure compatibility. For the sysctl, it has been merged
 all the back to 7.
 So We can switch after 8.4 death which is a good news (except if you say 
 that it
 is in 8.4)
 It means we can do it now. Very few people install i386 packages on
 amd64 anyway. It means people with very old releases on old branches
 might face a warning in an unusual situation. Not a big deal. Since we
 only provide i386 and amd64 packages anyway, this is also a trivial
 special case if you really want that.
 And it defeats cross installation (which is the reason why the ABI 
 supported is
 read from a binary and not from kernel)
 No. That's the point of the sysctl.
 I'm speaking of installing packages in a arm chroot on a amd64 host I 
 will need
 to know what arch could be supported by the content of the chroot.
 uname -p in the chroot (I guess this is with qemu) should return the
 right answer, just as it does with an i386 chroot. If it doesn't,
 something is broken in the qemu user mode support.
 nope that is not with qemu it is basically cross buildworld, install in a
 destdir, install packages in that destdir which is a very common usage that 
 a
 lot do expect to work
 Knowing a priori which architectures are supported by a chroot based
 on ELF type of /bin/sh doesn't even work. How do you know what kernel
 will be running in there 

Re: svn commit: r266553 - head/release/scripts

[Baptiste Daroussin]

On Fri, May 23, 2014 at 04:15:05PM -0700, Nathan Whitehorn wrote:
 
 On 05/23/14 14:34, Bryan Drewery wrote:
  On 2014-05-23 16:19, Nathan Whitehorn wrote:
  On 05/23/14 12:27, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 12:01:08PM -0700, Nathan Whitehorn wrote:
  On 05/23/14 10:26, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 10:11:47AM -0700, Nathan Whitehorn wrote:
  On 05/23/14 09:45, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:
  On 05/23/14 09:20, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:
  On 05/23/14 08:36, Baptiste Daroussin wrote:
  On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn 
  wrote:
  Is there any chance of finally switching the pkg abi 
  identifiers to just
  be uname -p?
  -Nathan
  Keeping asking won't make it happen, I have explained a 
  large number of time why it
  happened, why it is not easy for compatibility and why uname 
  -p is still not
  representing the ABI we do support, and what flexibility we 
  need that the
  current string offers to us.
 
  if one is willing to do the work, please be my guess, just 
  dig into the archives
  and join the pkg development otherwise: no it won't happen 
  before a while
  because we have way too much work on the todo and this item 
  is stored at the
  very end of this todo.
 
  regards,
  Bapt
  I'm happy to do the work, and have volunteered now many 
  times. If uname
  -p does not describe the ABI fully, then uname -p needs 
  changes on the
  relevant platforms. Which are they? What extra flexibility 
  does the
  string give you if uname -p describes the ABI completely?
  -Nathan
  just simple examples in armv6:
  - eabi vs oabi
  OABI is almost entirely dead, and will be entirely dead soon.
  Maybe but still for now it is there and pkg has to work now
  We don't provide packages for ARM. Also, no platforms have 
  defaulted to
  OABI for a very long time. Not making a distinction was a deliberate
  decision of the ARM group, since it was meant to be a clean 
  switchover.
 
  - The different float abi (even if only one is supported for 
  now others are
being worked on)
  armv6 and armv6hf
 
  - little endian vs big endian
  armv6 and armv6eb (though I think armv6eb support in general 
  has been
  removed from the tree, but armeb is still there)
  what about combinaison? armv6 + eb + hf?
  That would be armv6hfeb, I assume, if FreeBSD actually supported
  big-endian ARMv6 at all, which it doesn't.
 
  These all already exist.
 
  the extras flexibilit is being able to say this binary do 
  support freebsd i386
  and amd64 in one key, freebsd:9:x86:*, or or all arches 
  freebsd:10:*
 
  arm was en example what about mips?
  The same. There is mips64el, mipsel, mips, mips64, etc. that go 
  through
  all possible combinations. This is true for all platforms and has 
  been
  for ages. There was a brief period (2007-2010, I think) where some
  Tier-3 embedded platforms didn't have enough options, but that 
  era was
  obscure and is long past.
 
  The second one already would work, wouldn't it? Just replacing 
  x86:64
  with amd64 won't change anything. The first has to be 
  outweighed by
  being able to reliably figure out where to fetch from without a 
  lookup
  table.
 
  We also added the kern.supported_archs sysctl last year to all 
  branches
  to enable figuring out which architectures a given running kernel
  supports (e.g. amd64 and i386 on most amd64 systems). This was 
  designed
  specifically to help pkg figure out what packages it can install.
  I know, it means that we can switch only when freebsd 8 and 9 
  are EOL which means
  in a couple of years
  Why does it mean that? That doesn't make sense. A couple of 
  symlinks on
  the FTP server ensure compatibility. For the sysctl, it has been 
  merged
  all the back to 7.
  So We can switch after 8.4 death which is a good news (except if 
  you say that it
  is in 8.4)
  It means we can do it now. Very few people install i386 packages on
  amd64 anyway. It means people with very old releases on old branches
  might face a warning in an unusual situation. Not a big deal. Since we
  only provide i386 and amd64 packages anyway, this is also a trivial
  special case if you really want that.
 
  And it defeats cross installation (which is the reason why the 
  ABI supported is
  read from a binary and not from kernel)
  No. That's the point of the sysctl.
  I'm speaking of installing packages in a arm chroot on a amd64 
  host I will need
  to know what arch could be supported by the content of the chroot.
  uname -p in the chroot (I guess this is with qemu) should return the
  right answer, just as it does with an i386 chroot. If it doesn't,
  something is broken in the qemu user mode support.
  nope that is not with qemu it is basically cross buildworld, install 
  in a
  destdir, install packages in that destdir which is a very 

Re: svn commit: r266553 - head/release/scripts

[Warner Losh]

On May 23, 2014, at 5:22 PM, Baptiste Daroussin b...@freebsd.org wrote:

 On Fri, May 23, 2014 at 04:15:05PM -0700, Nathan Whitehorn wrote:
 
 On 05/23/14 14:34, Bryan Drewery wrote:
 On 2014-05-23 16:19, Nathan Whitehorn wrote:
 On 05/23/14 12:27, Baptiste Daroussin wrote:
 On Fri, May 23, 2014 at 12:01:08PM -0700, Nathan Whitehorn wrote:
 On 05/23/14 10:26, Baptiste Daroussin wrote:
 On Fri, May 23, 2014 at 10:11:47AM -0700, Nathan Whitehorn wrote:
 On 05/23/14 09:45, Baptiste Daroussin wrote:
 On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:
 On 05/23/14 09:20, Baptiste Daroussin wrote:
 On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:
 On 05/23/14 08:36, Baptiste Daroussin wrote:
 On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn 
 wrote:
 Is there any chance of finally switching the pkg abi 
 identifiers to just
 be uname -p?
 -Nathan
 Keeping asking won't make it happen, I have explained a 
 large number of time why it
 happened, why it is not easy for compatibility and why uname 
 -p is still not
 representing the ABI we do support, and what flexibility we 
 need that the
 current string offers to us.
 
 if one is willing to do the work, please be my guess, just 
 dig into the archives
 and join the pkg development otherwise: no it won't happen 
 before a while
 because we have way too much work on the todo and this item 
 is stored at the
 very end of this todo.
 
 regards,
 Bapt
 I'm happy to do the work, and have volunteered now many 
 times. If uname
 -p does not describe the ABI fully, then uname -p needs 
 changes on the
 relevant platforms. Which are they? What extra flexibility 
 does the
 string give you if uname -p describes the ABI completely?
 -Nathan
 just simple examples in armv6:
 - eabi vs oabi
 OABI is almost entirely dead, and will be entirely dead soon.
 Maybe but still for now it is there and pkg has to work now
 We don't provide packages for ARM. Also, no platforms have 
 defaulted to
 OABI for a very long time. Not making a distinction was a deliberate
 decision of the ARM group, since it was meant to be a clean 
 switchover.
 
 - The different float abi (even if only one is supported for 
 now others are
  being worked on)
 armv6 and armv6hf
 
 - little endian vs big endian
 armv6 and armv6eb (though I think armv6eb support in general 
 has been
 removed from the tree, but armeb is still there)
 what about combinaison? armv6 + eb + hf?
 That would be armv6hfeb, I assume, if FreeBSD actually supported
 big-endian ARMv6 at all, which it doesn't.
 
 These all already exist.
 
 the extras flexibilit is being able to say this binary do 
 support freebsd i386
 and amd64 in one key, freebsd:9:x86:*, or or all arches 
 freebsd:10:*
 
 arm was en example what about mips?
 The same. There is mips64el, mipsel, mips, mips64, etc. that go 
 through
 all possible combinations. This is true for all platforms and has 
 been
 for ages. There was a brief period (2007-2010, I think) where some
 Tier-3 embedded platforms didn't have enough options, but that 
 era was
 obscure and is long past.
 
 The second one already would work, wouldn't it? Just replacing 
 x86:64
 with amd64 won't change anything. The first has to be 
 outweighed by
 being able to reliably figure out where to fetch from without a 
 lookup
 table.
 
 We also added the kern.supported_archs sysctl last year to all 
 branches
 to enable figuring out which architectures a given running kernel
 supports (e.g. amd64 and i386 on most amd64 systems). This was 
 designed
 specifically to help pkg figure out what packages it can install.
 I know, it means that we can switch only when freebsd 8 and 9 
 are EOL which means
 in a couple of years
 Why does it mean that? That doesn't make sense. A couple of 
 symlinks on
 the FTP server ensure compatibility. For the sysctl, it has been 
 merged
 all the back to 7.
 So We can switch after 8.4 death which is a good news (except if 
 you say that it
 is in 8.4)
 It means we can do it now. Very few people install i386 packages on
 amd64 anyway. It means people with very old releases on old branches
 might face a warning in an unusual situation. Not a big deal. Since we
 only provide i386 and amd64 packages anyway, this is also a trivial
 special case if you really want that.
 
 And it defeats cross installation (which is the reason why the 
 ABI supported is
 read from a binary and not from kernel)
 No. That's the point of the sysctl.
 I'm speaking of installing packages in a arm chroot on a amd64 
 host I will need
 to know what arch could be supported by the content of the chroot.
 uname -p in the chroot (I guess this is with qemu) should return the
 right answer, just as it does with an i386 chroot. If it doesn't,
 something is broken in the qemu user mode support.
 nope that is not with qemu it is basically cross buildworld, install 
 in a
 destdir, install packages in that destdir which is a very common 
 usage that a
 lot do expect to work
 

Re: svn commit: r266553 - head/release/scripts

[Warner Losh]

On May 23, 2014, at 10:20 AM, Baptiste Daroussin b...@freebsd.org wrote:

 On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn wrote:
 On 05/23/14 08:36, Baptiste Daroussin wrote:
 On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:
 Is there any chance of finally switching the pkg abi identifiers to just
 be uname -p?
 -Nathan
 Keeping asking won't make it happen, I have explained a large number of 
 time why it
 happened, why it is not easy for compatibility and why uname -p is still not
 representing the ABI we do support, and what flexibility we need that the
 current string offers to us.
 
 if one is willing to do the work, please be my guess, just dig into the 
 archives
 and join the pkg development otherwise: no it won't happen before a while
 because we have way too much work on the todo and this item is stored at the
 very end of this todo.
 
 regards,
 Bapt
 
 I'm happy to do the work, and have volunteered now many times. If uname 
 -p does not describe the ABI fully, then uname -p needs changes on the 
 relevant platforms. Which are they? What extra flexibility does the 
 string give you if uname -p describes the ABI completely?
 -Nathan
 
 just simple examples in armv6:
 - eabi vs oabi
 - The different float abi (even if only one is supported for now others are
  being worked on)
 - little endian vs big endian

All of those are encoded in the MACHINE_ARCH + freebsd version, no exceptions
on supported architectures that are tier 2 or higher. This seems like a weak 
reason.

 the extras flexibilit is being able to say this binary do support freebsd i386
 and amd64 in one key, freebsd:9:x86:*, or or all arches freebsd:10:*

Will there be a program to convert this new, special invention to the standard
that we’ve used for the past 20 years? If you need the flexibility, which I’m 
not
entirely sure I’ve seen a good use case for. When would you have a x86 binary 
package? Wouldn’t it be either i386 or amd64?

Warner

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Warner Losh]

On May 23, 2014, at 9:52 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote:

 On 05/23/14 08:36, Baptiste Daroussin wrote:
 On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn wrote:
 Is there any chance of finally switching the pkg abi identifiers to just
 be uname -p?
 -Nathan
 Keeping asking won't make it happen, I have explained a large number of time 
 why it
 happened, why it is not easy for compatibility and why uname -p is still not
 representing the ABI we do support, and what flexibility we need that the
 current string offers to us.

What is not present? I’ve explained this many times. All examples that I’ve 
seen offered are the result of bugs, or are for unsupported configurations.

 if one is willing to do the work, please be my guess, just dig into the 
 archives
 and join the pkg development otherwise: no it won't happen before a while
 because we have way too much work on the todo and this item is stored at the
 very end of this todo.

I’m putting my hand up.

Warner

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266553 - head/release/scripts

[Nikolai Lifanov]

On 2014-05-23 17:34, Bryan Drewery wrote:

On 2014-05-23 16:19, Nathan Whitehorn wrote:

On 05/23/14 12:27, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 12:01:08PM -0700, Nathan Whitehorn wrote:

On 05/23/14 10:26, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 10:11:47AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:45, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:20, Baptiste Daroussin wrote:
On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn 
wrote:

On 05/23/14 08:36, Baptiste Daroussin wrote:
On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn 
wrote:
Is there any chance of finally switching the pkg abi 
identifiers to just

be uname -p?
-Nathan
Keeping asking won't make it happen, I have explained a large 
number of time why it
happened, why it is not easy for compatibility and why uname 
-p is still not
representing the ABI we do support, and what flexibility we 
need that the

current string offers to us.

if one is willing to do the work, please be my guess, just 
dig into the archives
and join the pkg development otherwise: no it won't happen 
before a while
because we have way too much work on the todo and this item 
is stored at the

very end of this todo.

regards,
Bapt
I'm happy to do the work, and have volunteered now many times. 
If uname
-p does not describe the ABI fully, then uname -p needs 
changes on the
relevant platforms. Which are they? What extra flexibility 
does the

string give you if uname -p describes the ABI completely?
-Nathan

just simple examples in armv6:
- eabi vs oabi

OABI is almost entirely dead, and will be entirely dead soon.

Maybe but still for now it is there and pkg has to work now
We don't provide packages for ARM. Also, no platforms have 
defaulted to
OABI for a very long time. Not making a distinction was a 
deliberate
decision of the ARM group, since it was meant to be a clean 
switchover.


- The different float abi (even if only one is supported for 
now others are

  being worked on)

armv6 and armv6hf


- little endian vs big endian
armv6 and armv6eb (though I think armv6eb support in general has 
been

removed from the tree, but armeb is still there)

what about combinaison? armv6 + eb + hf?

That would be armv6hfeb, I assume, if FreeBSD actually supported
big-endian ARMv6 at all, which it doesn't.


These all already exist.

the extras flexibilit is being able to say this binary do 
support freebsd i386
and amd64 in one key, freebsd:9:x86:*, or or all arches 
freebsd:10:*



arm was en example what about mips?
The same. There is mips64el, mipsel, mips, mips64, etc. that go 
through
all possible combinations. This is true for all platforms and has 
been

for ages. There was a brief period (2007-2010, I think) where some
Tier-3 embedded platforms didn't have enough options, but that era 
was

obscure and is long past.

The second one already would work, wouldn't it? Just replacing 
x86:64
with amd64 won't change anything. The first has to be outweighed 
by
being able to reliably figure out where to fetch from without a 
lookup

table.

We also added the kern.supported_archs sysctl last year to all 
branches
to enable figuring out which architectures a given running 
kernel
supports (e.g. amd64 and i386 on most amd64 systems). This was 
designed
specifically to help pkg figure out what packages it can 
install.
I know, it means that we can switch only when freebsd 8 and 9 are 
EOL which means

in a couple of years
Why does it mean that? That doesn't make sense. A couple of 
symlinks on
the FTP server ensure compatibility. For the sysctl, it has been 
merged

all the back to 7.
So We can switch after 8.4 death which is a good news (except if 
you say that it

is in 8.4)

It means we can do it now. Very few people install i386 packages on
amd64 anyway. It means people with very old releases on old branches
might face a warning in an unusual situation. Not a big deal. Since 
we

only provide i386 and amd64 packages anyway, this is also a trivial
special case if you really want that.

And it defeats cross installation (which is the reason why the 
ABI supported is

read from a binary and not from kernel)

No. That's the point of the sysctl.
I'm speaking of installing packages in a arm chroot on a amd64 host 
I will need
to know what arch could be supported by the content of the 
chroot.

uname -p in the chroot (I guess this is with qemu) should return the
right answer, just as it does with an i386 chroot. If it doesn't,
something is broken in the qemu user mode support.
nope that is not with qemu it is basically cross buildworld, install 
in a
destdir, install packages in that destdir which is a very common 
usage that a

lot do expect to work



Knowing a priori which architectures are supported by a chroot based
on ELF type of /bin/sh doesn't even work. How do you know what kernel
will be running in there and how it will be configured? You don't.
IA64 can -- 

Re: svn commit: r266553 - head/release/scripts

[Bryan Drewery]

On 2014-05-23 18:15, Nathan Whitehorn wrote:

On 05/23/14 14:34, Bryan Drewery wrote:

On 2014-05-23 16:19, Nathan Whitehorn wrote:

On 05/23/14 12:27, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 12:01:08PM -0700, Nathan Whitehorn wrote:

On 05/23/14 10:26, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 10:11:47AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:45, Baptiste Daroussin wrote:
On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn 
wrote:

On 05/23/14 09:20, Baptiste Daroussin wrote:
On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn 
wrote:

On 05/23/14 08:36, Baptiste Daroussin wrote:
On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn 
wrote:
Is there any chance of finally switching the pkg abi 
identifiers to just

be uname -p?
-Nathan
Keeping asking won't make it happen, I have explained a 
large number of time why it
happened, why it is not easy for compatibility and why uname 
-p is still not
representing the ABI we do support, and what flexibility we 
need that the

current string offers to us.

if one is willing to do the work, please be my guess, just 
dig into the archives
and join the pkg development otherwise: no it won't happen 
before a while
because we have way too much work on the todo and this item 
is stored at the

very end of this todo.

regards,
Bapt
I'm happy to do the work, and have volunteered now many 
times. If uname
-p does not describe the ABI fully, then uname -p needs 
changes on the
relevant platforms. Which are they? What extra flexibility 
does the

string give you if uname -p describes the ABI completely?
-Nathan

just simple examples in armv6:
- eabi vs oabi

OABI is almost entirely dead, and will be entirely dead soon.

Maybe but still for now it is there and pkg has to work now
We don't provide packages for ARM. Also, no platforms have 
defaulted to
OABI for a very long time. Not making a distinction was a 
deliberate
decision of the ARM group, since it was meant to be a clean 
switchover.


- The different float abi (even if only one is supported for 
now others are

  being worked on)

armv6 and armv6hf


- little endian vs big endian
armv6 and armv6eb (though I think armv6eb support in general 
has been

removed from the tree, but armeb is still there)

what about combinaison? armv6 + eb + hf?

That would be armv6hfeb, I assume, if FreeBSD actually supported
big-endian ARMv6 at all, which it doesn't.


These all already exist.

the extras flexibilit is being able to say this binary do 
support freebsd i386
and amd64 in one key, freebsd:9:x86:*, or or all arches 
freebsd:10:*



arm was en example what about mips?
The same. There is mips64el, mipsel, mips, mips64, etc. that go 
through
all possible combinations. This is true for all platforms and has 
been
for ages. There was a brief period (2007-2010, I think) where 
some
Tier-3 embedded platforms didn't have enough options, but that 
era was

obscure and is long past.

The second one already would work, wouldn't it? Just replacing 
x86:64
with amd64 won't change anything. The first has to be 
outweighed by
being able to reliably figure out where to fetch from without a 
lookup

table.

We also added the kern.supported_archs sysctl last year to all 
branches
to enable figuring out which architectures a given running 
kernel
supports (e.g. amd64 and i386 on most amd64 systems). This was 
designed
specifically to help pkg figure out what packages it can 
install.
I know, it means that we can switch only when freebsd 8 and 9 
are EOL which means

in a couple of years
Why does it mean that? That doesn't make sense. A couple of 
symlinks on
the FTP server ensure compatibility. For the sysctl, it has been 
merged

all the back to 7.
So We can switch after 8.4 death which is a good news (except if 
you say that it

is in 8.4)

It means we can do it now. Very few people install i386 packages on
amd64 anyway. It means people with very old releases on old 
branches
might face a warning in an unusual situation. Not a big deal. Since 
we

only provide i386 and amd64 packages anyway, this is also a trivial
special case if you really want that.

And it defeats cross installation (which is the reason why the 
ABI supported is

read from a binary and not from kernel)

No. That's the point of the sysctl.
I'm speaking of installing packages in a arm chroot on a amd64 
host I will need
to know what arch could be supported by the content of the 
chroot.
uname -p in the chroot (I guess this is with qemu) should return 
the

right answer, just as it does with an i386 chroot. If it doesn't,
something is broken in the qemu user mode support.
nope that is not with qemu it is basically cross buildworld, install 
in a
destdir, install packages in that destdir which is a very common 
usage that a

lot do expect to work



Knowing a priori which architectures are supported by a chroot 
based

on ELF type of /bin/sh doesn't even work. How do you know what kernel
will be running in there and how it 

Re: svn commit: r266553 - head/release/scripts

[Nathan Whitehorn]

On 05/23/14 19:33, Bryan Drewery wrote:

On 2014-05-23 18:15, Nathan Whitehorn wrote:

On 05/23/14 14:34, Bryan Drewery wrote:

On 2014-05-23 16:19, Nathan Whitehorn wrote:

On 05/23/14 12:27, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 12:01:08PM -0700, Nathan Whitehorn wrote:

On 05/23/14 10:26, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 10:11:47AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:45, Baptiste Daroussin wrote:

On Fri, May 23, 2014 at 09:38:14AM -0700, Nathan Whitehorn wrote:

On 05/23/14 09:20, Baptiste Daroussin wrote:
On Fri, May 23, 2014 at 08:52:28AM -0700, Nathan Whitehorn 
wrote:

On 05/23/14 08:36, Baptiste Daroussin wrote:
On Fri, May 23, 2014 at 08:19:34AM -0700, Nathan Whitehorn 
wrote:
Is there any chance of finally switching the pkg abi 
identifiers to just

be uname -p?
-Nathan
Keeping asking won't make it happen, I have explained a 
large number of time why it
happened, why it is not easy for compatibility and why 
uname -p is still not
representing the ABI we do support, and what flexibility 
we need that the

current string offers to us.

if one is willing to do the work, please be my guess, just 
dig into the archives
and join the pkg development otherwise: no it won't happen 
before a while
because we have way too much work on the todo and this 
item is stored at the

very end of this todo.

regards,
Bapt
I'm happy to do the work, and have volunteered now many 
times. If uname
-p does not describe the ABI fully, then uname -p needs 
changes on the
relevant platforms. Which are they? What extra flexibility 
does the

string give you if uname -p describes the ABI completely?
-Nathan

just simple examples in armv6:
- eabi vs oabi

OABI is almost entirely dead, and will be entirely dead soon.

Maybe but still for now it is there and pkg has to work now
We don't provide packages for ARM. Also, no platforms have 
defaulted to
OABI for a very long time. Not making a distinction was a 
deliberate
decision of the ARM group, since it was meant to be a clean 
switchover.


- The different float abi (even if only one is supported for 
now others are

  being worked on)

armv6 and armv6hf


- little endian vs big endian
armv6 and armv6eb (though I think armv6eb support in general 
has been

removed from the tree, but armeb is still there)

what about combinaison? armv6 + eb + hf?

That would be armv6hfeb, I assume, if FreeBSD actually supported
big-endian ARMv6 at all, which it doesn't.


These all already exist.

the extras flexibilit is being able to say this binary do 
support freebsd i386
and amd64 in one key, freebsd:9:x86:*, or or all arches 
freebsd:10:*



arm was en example what about mips?
The same. There is mips64el, mipsel, mips, mips64, etc. that go 
through
all possible combinations. This is true for all platforms and 
has been

for ages. There was a brief period (2007-2010, I think) where some
Tier-3 embedded platforms didn't have enough options, but that 
era was

obscure and is long past.

The second one already would work, wouldn't it? Just 
replacing x86:64
with amd64 won't change anything. The first has to be 
outweighed by
being able to reliably figure out where to fetch from without 
a lookup

table.

We also added the kern.supported_archs sysctl last year to 
all branches
to enable figuring out which architectures a given running 
kernel
supports (e.g. amd64 and i386 on most amd64 systems). This 
was designed
specifically to help pkg figure out what packages it can 
install.
I know, it means that we can switch only when freebsd 8 and 9 
are EOL which means

in a couple of years
Why does it mean that? That doesn't make sense. A couple of 
symlinks on
the FTP server ensure compatibility. For the sysctl, it has 
been merged

all the back to 7.
So We can switch after 8.4 death which is a good news (except if 
you say that it

is in 8.4)

It means we can do it now. Very few people install i386 packages on
amd64 anyway. It means people with very old releases on old branches
might face a warning in an unusual situation. Not a big deal. 
Since we

only provide i386 and amd64 packages anyway, this is also a trivial
special case if you really want that.

And it defeats cross installation (which is the reason why the 
ABI supported is

read from a binary and not from kernel)

No. That's the point of the sysctl.
I'm speaking of installing packages in a arm chroot on a amd64 
host I will need
to know what arch could be supported by the content of the 
chroot.

uname -p in the chroot (I guess this is with qemu) should return the
right answer, just as it does with an i386 chroot. If it doesn't,
something is broken in the qemu user mode support.
nope that is not with qemu it is basically cross buildworld, 
install in a
destdir, install packages in that destdir which is a very common 
usage that a

lot do expect to work



Knowing a priori which architectures are supported by a chroot based
on ELF type of /bin/sh doesn't even work. How do you know what