(re)name cpumem_realloc to cpumem_malloc_ncpus
cos its not resizing the allocation, its allocating them for new cpus. the same goes for counters_realloc being named counters_alloc_ncpus. this adds doco for them too. ok? Index: share/man/man9/counters_alloc.9 === RCS file: /cvs/src/share/man/man9/counters_alloc.9,v retrieving revision 1.2 diff -u -p -r1.2 counters_alloc.9 --- share/man/man9/counters_alloc.9 21 Oct 2016 12:39:13 - 1.2 +++ share/man/man9/counters_alloc.9 24 Oct 2016 04:43:33 - @@ -20,6 +20,9 @@ .Sh NAME .Nm counters_alloc , .Nm counters_free , +.Nm COUNTERS_BOOT_MEMORY , +.Nm COUNTERS_BOOT_INITIALIZER , +.Nm counters_alloc_ncpus , .Nm counters_enter , .Nm counters_leave , .Nm counters_read , @@ -31,6 +34,14 @@ .Fn counters_alloc "unsigned int ncounters" "int type" .Ft void .Fn counters_free "struct cpumem *cm" "unsigned int ncounters" "int type" +.Fn COUNTERS_BOOT_MEMORY "NAME" "unsigned int ncounters" +.Fn COUNTERS_BOOT_INITIALIZER "NAME" +.Ft struct cpumemt * +.Fo counters_alloc_ncpus +.Fa "struct cpumem *cm" +.Fa "unsigned int ncounters" +.Fa "int type" +.Fc .Ft uint64_t * .Fn counters_enter "struct counters_ref *ref" "struct cpumem *cm" .Ft void @@ -84,6 +95,60 @@ arguments type originally provided to must be passed to .Fn counters_free . .Pp +If a set of per CPU counters needs to be usable as soon as the +kernel is booted, instead of after devices (which includes CPUs) +are attached, a cpumem pointer and counters for the boot CPU may be +statically allocated. +.Pp +.Fn COUNTERS_BOOT_MEMORY +allocates counters for use by the boot CPU in the kernel and before +the other CPUs are attached and run. +The allocation is identified by +.Fa NAME , +and provides memory for the number of counters specified by +.Fa ncounters . +.Pp +.Pp +.Fn COUNTERS_BOOT_INITIALIZER +is used to initialise a cpumem pointer with the memory that was previously +allocated using +.Fn COUNTERS_BOOT_MEMORY +and identified by +.Fa NAME . +.Pp +.Fn counters_alloc_ncpus +allocates additional per CPU counters for the CPUs that were attached +during boot to the cpumem structure +.Fa cm +that was previously allocated statically using +.Fn COUNTERS_BOOT_MEMORY +and initialised with +.Fn COUNTERS_BOOT_INITIALIZER . +.Fn counters_alloc_ncpus +allocates space for a number of counters specified by +.Fa ncounters . +The +.Fa type +argument specifies the type of memory that the counters will be +allocated as via +.Xr malloc 9 . +The memory will be zeroed on allocation by passing +.Fn M_ZERO +to +.Xr malloc 9 . +The same number of counters originally passed to +.Fa COUNTERS_BOOT_MEMORY +must be specified by +.Fa ncounters . +.Pp +Counters that have been allocated with +.Fn COUNTERS_BOOT_MEMORY +and +.Fn counters_alloc_ncpus +cannot be deallocated with +.Fa counters_free . +Any attempt to do so will lead to undefined behaviour. +.Pp .Fn counters_enter provides access to the current CPU's set of counters referenced by .Fa cm . @@ -119,6 +184,7 @@ up to the caller to serialise this call .Sh CONTEXT .Fn counters_alloc , .Fn counters_free , +.Fn counters_alloc_ncpus , and .Fn counters_read may be called during autoconf, or from process context. @@ -136,7 +202,9 @@ It is up to the caller to provide approp around calls to these functions to prevent concurrent access to the relevant data structures. .Sh RETURN VALUES -.Fn counters_get +.Fn counters_alloc +and +.Fn counters_alloc_ncpus will return an opaque cpumem pointer that references each CPU's set of counters. .Pp Index: share/man/man9/cpumem_get.9 === RCS file: /cvs/src/share/man/man9/cpumem_get.9,v retrieving revision 1.5 diff -u -p -r1.5 cpumem_get.9 --- share/man/man9/cpumem_get.9 21 Oct 2016 15:00:30 - 1.5 +++ share/man/man9/cpumem_get.9 24 Oct 2016 04:43:33 - @@ -21,7 +21,10 @@ .Nm cpumem_get , .Nm cpumem_put , .Nm cpumem_malloc , +.Nm cpumem_malloc_ncpus , .Nm cpumem_free , +.Nm CPUMEM_BOOT_MEMORY , +.Nm CPUMEM_BOOT_INITIALIZER , .Nm cpumem_enter , .Nm cpumem_leave , .Nm cpumem_first , @@ -37,6 +40,10 @@ .Fn cpumem_malloc "size_t sz" "int type" .Ft void .Fn cpumem_free "struct cpumem *cm" "int type" "size_t sz" +.Fn CPUMEM_BOOT_MEMORY "NAME" "size_t sz" +.Fn CPUMEM_BOOT_INITIALIZER "NAME" +.Ft struct cpumem * +.Fn cpumem_malloc_ncpus "struct cpumem *cm" "size_t sz" "int type" .Ft void * .Fn cpumem_enter "struct cpumem *cm" .Ft void @@ -100,6 +107,59 @@ must be specified by and .Fa type respectively. +.Pp +If a per CPU memory allocation needs to be usable as soon as the +kernel is booted, instead of after devices (which includes CPUs) +are attached, a cpumem pointer and memory for the boot CPU may be +statically allocated. +.Pp +.Fn CPUMEM_BOOT_MEMORY +allocates memory for use by the boot CPU in the kernel and before +the other CPUs are attached and run. The allocation is identified +by +.Fn NAME , +and provides +.Fn
Re: fix carp "carppeer" + "real mac-address"
FYI. I just commited regress tests on regress/netinet/carp/ . carp_4.sh demostrates the problem which the diff fixes. On Tue, 18 Oct 2016 19:33:01 +0900 (JST) YASUOKA Masahikowrote: > Currenlty when carppeer + "real mac-address" are used at once, > changing MASTER by carpdemote causes "MASTER-MASTER" problem, BACKUP > is to become MASTER but the present MASTER also will keep its state. > > The diff following will fix this problem. > > ok? > > Accept CARP advertisement packets whose destination is not for multicast. > When both "carppeer" and "real mac-address" are used at once and the > BACKUP is to take over the new MASTER, the present MASTER receives > such packets. > > found by and diff from nagasaka at iij > > diff --git a/sys/netinet/ip_carp.c b/sys/netinet/ip_carp.c > index 9eb5552..bfbf430 100644 > --- a/sys/netinet/ip_carp.c > +++ b/sys/netinet/ip_carp.c > @@ -453,7 +453,7 @@ carp_proto_input_if(struct ifnet *ifp, struct mbuf *m, > int hlen) > ismulti = IN_MULTICAST(ip->ip_dst.s_addr); > > /* check if received on a valid carp interface */ > - if (!((ifp->if_type == IFT_CARP && ismulti) || > + if (!(ifp->if_type == IFT_CARP || > (ifp->if_type != IFT_CARP && !ismulti && ifp->if_carp != NULL))) { > carpstats.carps_badif++; > CARP_LOG(LOG_INFO, sc, >
Re: Quirks for pkcbc?
> Since the patch isn't a proper solution, I was wondering whether there's > a quirks mechanism for pckbc, similar to what e.g. some of the USB HID > drivers do for things like joysticks with weird button mappings. No way. quirk layers are really unacceptable to maintain in the long term. Instead, I ask you to figure out logical conditions under which this should happen, or if some interaction is wrong. This is very complicated stuff with a lot of legacy, prepare for it to take months to get good sufficient reports from people, for your proposals. > > -- > Gregor > > Index: dev/ic/pckbc.c > === > RCS file: /mnt/media/cvs/src/sys/dev/ic/pckbc.c,v > retrieving revision 1.49 > diff -u -p -r1.49 pckbc.c > --- dev/ic/pckbc.c 24 May 2015 10:57:47 - 1.49 > +++ dev/ic/pckbc.c 23 Oct 2016 21:19:56 - > @@ -378,6 +378,8 @@ pckbc_attach(struct pckbc_softc *sc, int > bus_space_write_1(iot, ioh_d, 0, 0x5a); /* a random value */ > res = pckbc_poll_data1(iot, ioh_d, ioh_c, PCKBC_AUX_SLOT, 1); > > + t->t_flags |= PCKBC_NEED_AUXWRITE; > + > if (ISSET(t->t_flags, PCKBC_NEED_AUXWRITE)) { > /* > * The following code is necessary to find the aux port on the >
Quirks for pkcbc?
Hi people, the patch below the signature makes the touchpad on my new laptop work. pms(4) didnt' attach previously because the AUX slot on the keyboard was not enabled. Since the patch isn't a proper solution, I was wondering whether there's a quirks mechanism for pckbc, similar to what e.g. some of the USB HID drivers do for things like joysticks with weird button mappings. -- Gregor Index: dev/ic/pckbc.c === RCS file: /mnt/media/cvs/src/sys/dev/ic/pckbc.c,v retrieving revision 1.49 diff -u -p -r1.49 pckbc.c --- dev/ic/pckbc.c 24 May 2015 10:57:47 - 1.49 +++ dev/ic/pckbc.c 23 Oct 2016 21:19:56 - @@ -378,6 +378,8 @@ pckbc_attach(struct pckbc_softc *sc, int bus_space_write_1(iot, ioh_d, 0, 0x5a); /* a random value */ res = pckbc_poll_data1(iot, ioh_d, ioh_c, PCKBC_AUX_SLOT, 1); + t->t_flags |= PCKBC_NEED_AUXWRITE; + if (ISSET(t->t_flags, PCKBC_NEED_AUXWRITE)) { /* * The following code is necessary to find the aux port on the
Re: FAQ entry for vmm
Hi, On Wed, Oct 19, 2016 at 06:42:08PM +0200, Daniel Jakots wrote: > The second sentence in the FAQ is 'It covers the latest release of > OpenBSD.'. Maybe it would be worth adding a sentence about the fact > that it covers mainly current (as in -stable vmm is not enabled). Just to keep the list in the loop, here is the version of the vmm faq diff which I now have OKs for. We have decided however, to not commit this until 6.1 release. Thanks for all the feedback. Index: faq/faq6.html === RCS file: /home/edd/cvsync/www/faq/faq6.html,v retrieving revision 1.419 diff -u -p -r1.419 faq6.html --- faq/faq6.html 8 Oct 2016 03:17:45 - 1.419 +++ faq/faq6.html 21 Oct 2016 15:22:13 - @@ -50,6 +50,7 @@ Setting up a network bridge Equal-cost multipath routing Adding and replacing NICs +Networking vmm(4) guests @@ -1183,6 +1184,89 @@ Some likely candidates might include: Bridge configuration (/etc/hostname.bridge*) Trunk configuration (/etc/hostname.trunk*) + +Networking vmm(4) guests + +Giving network access to a http://man.openbsd.org/vmm;>vmm(4) +guest is easy if the host machine uses a wired connection. +You can simply put the guest's http://man.openbsd.org/tap;>tap(4) +interface into a bridged virtual switch with the host's wired interface. +Inside the guest, the http://man.openbsd.org/vio;>vio(4) +interface can then be configured as if it were a real machine physically +connected to the host network. +Unfortunately, this strategy does not work if the host machine uses a wireless +network interface. +Due to a limitation of the IEEE 802.11 standard, wireless interfaces cannot +participate in network bridges. +One way to work around this is to give the guest VM its own network and use +network address translation (NAT) to the host's network. + + +Suppose we have a host machine with network access via a wireless iwn0 +interface on the 192.168.1.0/24 network. +We want to install an OpenBSD guest onto the 10.0.0.0/24 network and +give the guest access to the host's network via NAT. +Assume that we configured the guest's host-side interface to be fixed as +tap0. +Although we could set up NAT directly between the tap0 and +iwn0, this tends to complicate matters, as tap0 will appear +and disappear as the guest is powered up and down. +In that case, we would have to reconfigure tap0 manually after each +guest power-on. +A more robust approach is to use an always-existing +http://man.openbsd.org/vether;>vether(4) interface and +have http://man.openbsd.org/vmd;>vmd(8) bridge this with +tap0 when the guest is powered on. +Since vether0 always exists regardless of whether the guest is powered +up or not, its configuration will persist across guest power cycles. + + +Let's make a vether0 interface: + + +# echo "inet 10.0.0.1 255.255.255.0" > /etc/hostname.vether0 +# sh /etc/netstart vether0 + + +Add the following to /etc/pf.conf: + + +match out on iwn0 inet from vether0:network to any nat-to (iwn0) + + +And to finish off the NAT configuration: + + +# pfctl -f /etc/pf.conf +# echo "net.inet.ip.forwarding=1" >> /etc/sysctl.conf +# sysctl net.inet.ip.forwarding=1 +net.inet.ip.forwarding: 0 -> 1 + + +In http://man.openbsd.org/vm.conf;vm.conf(5), ensure that you +put vether0 into a virtual switch alongside tap0. +For example: + + +switch "my_switch" { +add vether0 +interface bridge0 +} + +vm "my_vm" { +... +interface tap0 { switch "my_switch" } +} + + +Inside the guest, if we now assign vio0 an address on the +10.0.0.0/24 network and set the default route to 10.0.0.1, we +should be able to ping systems on the host network. +For convenience, you may wish to set up a DHCP server on vether0. +See http://man.openbsd.org/dhcpd;>dhcpd(8) and +http://man.openbsd.org/dhcpd.conf;>dhcpd.conf(5) for details on +how to set up a DHCP server (an example config file can be found at +/etc/examples/dhcpd.conf). Index: faq/index.html === RCS file: /home/edd/cvsync/www/faq/index.html,v retrieving revision 1.495 diff -u -p -r1.495 index.html --- faq/index.html 2 Oct 2016 21:16:26 - 1.495 +++ faq/index.html 20 Oct 2016 13:36:18 - @@ -112,6 +112,7 @@ that are not covered in the FAQ. Setting up a network bridge Equal-cost multipath routing Adding and replacing NICs +Networking vmm(4) guests Keyboard and Display Controls -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
snmpd(8): turn snmpd_env the only global
This diff removes all "extern struct snmpd *" lines from source files, replaces all 'env' occurences with 'snmpd_env' and adds the extern declaration for snmpd_env in the snmpd.h header. With this diff we only need to guarantee that this variable is set, we avoid shadowing other 'env' variables and we diminish the confusion about this env variable thing. We need this diff (or something with the same effect) to proceed with fork+exec, because jca@ found out that traphandler child process do not set env. We could alternatively just set env in traphandler p_init() and remove snmpd_env, however it looks cleaner to me to not have all this extern in all .c files and have a propper name for 'env'. ok? Index: kroute.c === RCS file: /home/obsdcvs/src/usr.sbin/snmpd/kroute.c,v retrieving revision 1.33 diff -u -p -r1.33 kroute.c --- kroute.c3 Sep 2016 15:45:02 - 1.33 +++ kroute.c22 Oct 2016 22:20:00 - @@ -44,8 +44,6 @@ #include "snmpd.h" -extern struct snmpd*env; - struct ktable **krt; u_intkrt_size; @@ -173,8 +171,9 @@ kr_init(void) , sizeof(opt)) == -1) log_warn("%s: SO_USELOOPBACK", __func__); /* not fatal */ - if (env->sc_rtfilter && setsockopt(kr_state.ks_fd, PF_ROUTE, - ROUTE_MSGFILTER, >sc_rtfilter, sizeof(env->sc_rtfilter)) == -1) + if (snmpd_env->sc_rtfilter && setsockopt(kr_state.ks_fd, PF_ROUTE, + ROUTE_MSGFILTER, _env->sc_rtfilter, + sizeof(snmpd_env->sc_rtfilter)) == -1) log_warn("%s: ROUTE_MSGFILTER", __func__); /* grow receive buffer, don't wanna miss messages */ Index: mib.c === RCS file: /home/obsdcvs/src/usr.sbin/snmpd/mib.c,v retrieving revision 1.80 diff -u -p -r1.80 mib.c --- mib.c 17 Nov 2015 12:30:23 - 1.80 +++ mib.c 22 Oct 2016 22:26:52 - @@ -58,8 +58,6 @@ #include "snmpd.h" #include "mib.h" -extern struct snmpd*env; - /* * Defined in SNMPv2-MIB.txt (RFC 3418) */ @@ -255,7 +253,7 @@ mib_sysor(struct oid *oid, struct ber_oi int mib_getsnmp(struct oid *oid, struct ber_oid *o, struct ber_element **elm) { - struct snmp_stats *stats = >sc_stats; + struct snmp_stats *stats = _env->sc_stats; long longi; struct statsmap { u_int8_t m_id; @@ -316,7 +314,7 @@ mib_getsnmp(struct oid *oid, struct ber_ int mib_setsnmp(struct oid *oid, struct ber_oid *o, struct ber_element **elm) { - struct snmp_stats *stats = >sc_stats; + struct snmp_stats *stats = _env->sc_stats; long longi; if (ber_get_integer(*elm, ) == -1) @@ -354,11 +352,11 @@ mib_engine(struct oid *oid, struct ber_o { switch (oid->o_oid[OIDIDX_snmpEngine]) { case 1: - *elm = ber_add_nstring(*elm, env->sc_engineid, - env->sc_engineid_len); + *elm = ber_add_nstring(*elm, snmpd_env->sc_engineid, + snmpd_env->sc_engineid_len); break; case 2: - *elm = ber_add_integer(*elm, env->sc_engine_boots); + *elm = ber_add_integer(*elm, snmpd_env->sc_engine_boots); break; case 3: *elm = ber_add_integer(*elm, snmpd_engine_time()); @@ -375,7 +373,7 @@ mib_engine(struct oid *oid, struct ber_o int mib_usmstats(struct oid *oid, struct ber_oid *o, struct ber_element **elm) { - struct snmp_stats *stats = >sc_stats; + struct snmp_stats *stats = _env->sc_stats; long longi; struct statsmap { u_int8_t m_id; @@ -697,7 +695,7 @@ mib_hrdevice(struct oid *oid, struct ber /* Get and verify the current row index */ idx = o->bo_id[OIDIDX_hrDeviceEntry]; - if (idx > (u_int)env->sc_ncpu) + if (idx > (u_int)snmpd_env->sc_ncpu) return (1); /* Tables need to prepend the OID on their own */ @@ -748,7 +746,7 @@ mib_hrprocessor(struct oid *oid, struct /* Get and verify the current row index */ idx = o->bo_id[OIDIDX_hrDeviceEntry]; - if (idx > (u_int)env->sc_ncpu) + if (idx > (u_int)snmpd_env->sc_ncpu) return (1); else if (idx < 1) idx = 1; @@ -766,9 +764,9 @@ mib_hrprocessor(struct oid *oid, struct * The percentage of time that the system was not * idle during the last minute. */ - if (env->sc_cpustates == NULL) + if (snmpd_env->sc_cpustates == NULL) return (-1); - cptime2 = env->sc_cpustates + (CPUSTATES * (idx - 1)); + cptime2 = snmpd_env->sc_cpustates + (CPUSTATES * (idx - 1)); val = 100 -
Re: FreeType 2.7
On Sat, Oct 22, 2016 at 02:24:39PM +0200, Matthieu Herrb wrote: > On Sat, Oct 22, 2016 at 02:02:12PM +0200, David Coppa wrote: > > On Sat, Oct 22, 2016 at 11:52 AM, Matthieu Herrbwrote: > > > On Mon, Oct 10, 2016 at 12:46:41PM +0200, David Coppa wrote: > > >> > > >> Hi all, > > >> > > >> Here's the update to FreeType 2.7 (a gzipped diff is also attached). > > >> > > >> The biggest change is that now Subpixel hinting, also known as > > >> ClearType hinting, is enabled by default. > > >> > > >> As usual, a ports bulk build is appreciated. > > > > > > Hi, > > > > > > I'm not really sure that the bumping of the major revision of > > > libfontconfig, libXft and libXfont is needed or will help with out of > > > date packages. Can you explain ? > > > > We did this before. > > Yes, it's to avoid problems like the message below. > > > > Unfortunatly it will not avoid all of them. For now, after upgrading > xenocara, but with packages still linked to freetype.26 I get this > from firefox: > > firefox:/usr/X11R6/lib/libfreetype.so.26.0: > /usr/X11R6/lib/libfreetype.so.27.0 : WARNING: symbol(af_blue_strings) size > mismatch, relink your program > > For the extra major bumps to be useful in this situation, ld.so > would need to only load the revisions of the libs that the program was > linked against, and ignore the more recent versions But with dlopen() > which doesn't do versionning it won't be trivial. > > -- > Matthieu Herrb That said, the update (with fontconfig/Xft/Xfont bumps) survived a rebuild of my standard set of packages (including firefox, chrome, libreoffice & xfce4). So ok matthieu@ -- Matthieu Herrb signature.asc Description: PGP signature