Multihabilidades de Supervisión y Coaching
Coaching y Multihabilidades de Supervisión SEMINARIO ONLINE EN VIVO este 27 de Septiembre de 2012. Tiene usted personal a su cargo? este seminario es para usted! El Nuevo concepto de Coaching y Multihabilidades le ayudará notablemente a mejorar y aumentar su capacidad de trabajo, le brindará las técnicas más modernas y efectivas que usted necesita para destacar en su organización. En este Seminario ONLINE en Vivo usted aprenderá: ¿Cómo se transforma un Supervisor en un Coach - Multihabilidades? Métodos prácticos para planear, organizar y controlar su trabajo y el de sus colaboradores. ¿Cuándo y cómo delegar y facultar a sus colaboradores? Establecer una cultura de previsión, eficiencia y proactividad hacia la solución de problemas. Técnicas avanzadas para medir el trabajo, controlar la eficiencia y rendimiento de la mano de obra. ¿Cómo administrar y distribuir mejor las cargas de trabajo? - Estándares de tiempo. Adquiera la información completa y sin compromiso solo responda este correo con asunto -Deseo Folleto Coaching o Comuníquese al (507) 279-1083 / 279-0258 / 279-0887 - y a la brevedad lo recibira. ESTE CORREO NO PUEDE SER CONSIDERADO INTRUSIVO YA QUE CUMPLE CON LAS POLÍTICAS ANTISPAM INTERNACIONALES Y LOCALES: Responda este correo con el Asunto borrar y automáticamente quedará fuera de nuestras listas. Este correo ha sido enviado a: tech@openbsd.org
uftdi baud rates
This diff is about the baud rate divisor calculation.
The driver should now support the full range of possible baud rates for
FT232BM and later devices.
(The calculation is described in the document "AN_120 Aliasing VCP
Baud Rates" from ftdi.)
Index: sys/dev/usb/uftdireg.h
===
RCS file: /cvs/src/sys/dev/usb/uftdireg.h,v
retrieving revision 1.13
diff -u -p -r1.13 uftdireg.h
--- sys/dev/usb/uftdireg.h 11 Sep 2012 16:04:44 - 1.13
+++ sys/dev/usb/uftdireg.h 20 Sep 2012 21:42:51 -
@@ -36,6 +36,7 @@
enum uftdi_type {
UFTDI_TYPE_SIO,
UFTDI_TYPE_8U232AM,
+ UFTDI_TYPE_232BM,
UFTDI_TYPE_2232H
};
Index: sys/dev/usb/uftdi.c
===
RCS file: /cvs/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.63
diff -u -p -r1.63 uftdi.c
--- sys/dev/usb/uftdi.c 11 Sep 2012 16:04:44 - 1.63
+++ sys/dev/usb/uftdi.c 20 Sep 2012 21:42:52 -
@@ -105,7 +105,7 @@ voiduftdi_write(void *sc, int portno, u
u_int32_t *count);
void uftdi_break(void *sc, int portno, int onoff);
intuftdi_8u232am_getrate(speed_t speed, int *rate);
-intuftdi_2232h_getrate(speed_t speed, int *rate);
+intuftdi_232bm_getrate(speed_t speed, int freq, int *rate);
struct ucom_methods uftdi_methods = {
uftdi_get_status,
@@ -821,17 +821,19 @@ uftdi_attach(struct device *parent, stru
sc->sc_udev = dev;
sc->sc_iface = iface;
+ sc->sc_hdrlen = 0;
if (uaa->release < 0x0200) {
sc->sc_type = UFTDI_TYPE_SIO;
sc->sc_hdrlen = 1;
- } else if (uaa->release == 0x0700 || uaa->release == 0x0800) {
+ } else if (uaa->release < 0x0500)
+ sc->sc_type = UFTDI_TYPE_8U232AM;
+ else if (uaa->release < 0x0700)
+ sc->sc_type = UFTDI_TYPE_232BM;
+ else if (uaa->release < 0x0A00)
sc->sc_type = UFTDI_TYPE_2232H;
- sc->sc_hdrlen = 0;
- } else {
+ else
sc->sc_type = UFTDI_TYPE_8U232AM;
- sc->sc_hdrlen = 0;
- }
uca.bulkin = uca.bulkout = -1;
for (i = 0; i < id->bNumEndpoints; i++) {
@@ -1083,9 +1085,19 @@ uftdi_param(void *vsc, int portno, struc
if (uftdi_8u232am_getrate(t->c_ospeed, &rate) == -1)
return (EINVAL);
break;
+ case UFTDI_TYPE_232BM:
+ if (uftdi_232bm_getrate(t->c_ospeed, FTDI_8U232AM_FREQ, &rate)
== -1)
+ return (EINVAL);
case UFTDI_TYPE_2232H:
- if (uftdi_2232h_getrate(t->c_ospeed, &rate) == -1)
-return (EINVAL);
+ if (t->c_ospeed <= FTDI_8U232AM_FREQ) {
+ if (uftdi_232bm_getrate(t->c_ospeed, FTDI_8U232AM_FREQ,
&rate) == -1)
+ return (EINVAL);
+ } else {
+ if (uftdi_232bm_getrate(t->c_ospeed, FTDI_2232H_FREQ,
&rate) == -1)
+ return (EINVAL);
+ /* Set this bit to turn off a divide by 2.5 */
+ rate|= 0x0002;
+ }
break;
}
req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
@@ -1263,31 +1275,37 @@ done:
}
int
-uftdi_2232h_getrate(speed_t speed, int *rate)
+uftdi_232bm_getrate(speed_t speed, int freq, int *rate)
{
char sub[8] = {0, 3, 2, 4, 1, 5, 6, 7};
- int n = (FTDI_2232H_FREQ << 3) / speed;
+ int n = ((freq << 3) + (speed >> 1)) / speed;
int s = n & 7;
- int result = (n >> 3) | (sub[s] << 14);
+ int resultint = (n >> 3);
+ int result = resultint | (sub[s] << 14);
int resultspeed, accuracy;
/* Special cases */
- if (result == 1)
- result = 0;
- else if (result == 0x4001)
+ if (resultint == 0 || resultint > 16384)
+ return -1;
+ else if (speed > 200 * 97 / 100 && speed < 200 * 103 / 100) {
result = 1;
+ goto done;
+ }
+ else if (resultint == 1) {
+ result = 0;
+ s = 0;
+ }
/* Check if resulting baud rate is within 3%. */
- if (result == 0)
+ if (resultint == 0)
goto done;
- resultspeed = (FTDI_2232H_FREQ << 3) /
- (((result & 0x3FFF) << 3) | s);
+ resultspeed = (freq << 3) /
+ ((resultint << 3) | s);
accuracy = (abs(speed - resultspeed) * 100) / speed;
- if (accuracy > 3)
+ if (accuracy >= 3)
return -1;
done:
- result|= 0x0002; /* Set this bit to turn off a divide by 2.5 */
*rate = result;
return 0;
}
Bypassing Intel SMEP on Windows 8 x64
Hello tech@. Very interesting security related article about bypassing Intel SMEP feature on x64 version of Windows 8. http://blog.ptsecurity.com/2012/09/bypassing-intel-smep-on-windows-8-x64.html Cheers, Alexey
Re: ntpd.8 SIGINFO and ntpd
On Wed, Sep 19, 2012 at 09:53:06PM +0100, Jason McIntyre wrote: > henning just committed a fix to this page. we decided on a different > diff because although the example you give above works, it is simpler to > just do "pkill -INFO ntpd". > > hope that is satisfactory, Sure it is! Thanks, Frank. -- Frank Brodbeck
Re: proto cksum madness
so, resurrecting, slighly updated diff.
I need your help testing. This diff has a kinda high breakage
potential, since there are quite a few output pathes. On the plus side
breakage is easy to spot, since that'll result in bad checksums and
thus these packets getting dropped. Should be all or none per given
output path.
Just run it. You'll notice when your network connections fail. The
more obscure your setup, the better, basically. bridge, tunnels, you
name it.
if you spot breakage, drop me a mail. if you don't, do so as well
please.
* Henning Brauer [2012-07-13 13:23]:
> after just 15 months i got this finally working.
>
> basically moving us to the assumption that there is some cksum offload
> engine in each an every output path, calling the software engine very
> late if we figure there is none. foremost this adds this logic to the
> alternate output pathes like bridge, the regular already followed that
> model.
> stop the cksum fucku^Wfixup in pf. just set the damn flags to indicate
> the packets needs to be re-checksummed. and since some stupid cards
> incorporated the terrible pseudo header checksum hack in hardware we
> have to fill that in as well.
>
> for now, this will have a little performance penalty since right now
> proto cksum offloading is disabled due to a bug in the pf<->cksum<->hw
> interaction that this change happens to eliminate, so we'll be able to
> turn on proto csum offloading in the drivers (which will lead to fun
> with silicone bugs, but that's another topic).
>
> i started hacking on that in iceland and touched it on every hackathon
> since... the horror.
> in6_proto_csum_out written by krw.
Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.196
diff -u -p -r1.196 if_bridge.c
--- net/if_bridge.c 20 Sep 2012 14:10:18 - 1.196
+++ net/if_bridge.c 20 Sep 2012 16:29:26 -
@@ -2,6 +2,7 @@
/*
* Copyright (c) 1999, 2000 Jason L. Wright (ja...@thought.net)
+ * Copyright (c) 2003 - 2012 Henning Brauer
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -1061,15 +1062,6 @@ bridge_output(struct ifnet *ifp, struct
return (0);
}
#endif /* IPSEC */
-
- /* Catch packets that need TCP/UDP hardware checksumming */
- if (m->m_pkthdr.csum_flags & M_TCP_CSUM_OUT ||
- m->m_pkthdr.csum_flags & M_UDP_CSUM_OUT) {
- m_freem(m);
- splx(s);
- return (0);
- }
-
bridge_span(sc, NULL, m);
LIST_FOREACH(p, &sc->sc_iflist, next) {
@@ -2459,6 +2451,12 @@ bridge_ipsec(struct bridge_softc *sc, st
}
if (m == NULL)
return (1);
+ else if (af == AF_INET)
+ in_proto_cksum_out(m, encif);
+#ifdef INET6
+ else if (af == AF_INET6)
+ in6_proto_cksum_out(m, encif);
+#endif /* INET6 */
#endif /* NPF */
ip = mtod(m, struct ip *);
@@ -2611,6 +2609,7 @@ bridge_ip(struct bridge_softc *sc, int d
return (NULL);
if (m->m_len < sizeof(struct ip))
goto dropit;
+ in_proto_cksum_out(m, ifp);
ip = mtod(m, struct ip *);
ip->ip_sum = 0;
if (0 && (ifp->if_capabilities & IFCAP_CSUM_IPv4)) {
@@ -2656,6 +2655,7 @@ bridge_ip(struct bridge_softc *sc, int d
if (m == NULL)
return (NULL);
#endif /* NPF > 0 */
+ in6_proto_cksum_out(m, ifp);
break;
}
Index: net/if_pflog.c
===
RCS file: /cvs/src/sys/net/if_pflog.c,v
retrieving revision 1.50
diff -u -p -r1.50 if_pflog.c
--- net/if_pflog.c 8 Jul 2012 07:58:09 - 1.50
+++ net/if_pflog.c 10 Jul 2012 10:18:29 -
@@ -443,7 +443,7 @@ pflog_bpfcopy(const void *src_arg, void
if (pd.virtual_proto != PF_VPROTO_FRAGMENT &&
(pfloghdr->rewritten = pf_translate(&pd, &pfloghdr->saddr,
pfloghdr->sport, &pfloghdr->daddr, pfloghdr->dport, 0,
- pfloghdr->dir))) {
+ pfloghdr->dir, pd.m))) {
m_copyback(pd.m, pd.off, min(pd.m->m_len - pd.off, pd.hdrlen),
pd.hdr.any, M_NOWAIT);
#if INET && INET6
Index: net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.812
diff -u -p -r1.812 pf.c
--- net/pf.c19 Sep 2012 12:35:07 - 1.812
+++ net/pf.c20 Sep 2012 10:44:45 -
@@ -2,7 +2,7 @@
/*
* Copyright (c) 2001 Daniel Hartmeier
- * Copyright (c) 2002 - 2010 Henning Br
Sepa Cómo Despedir Empleados en el Marco de la Ley
Sepa Cómo Despedir Empleados en el Marco de la Ley Panamá 26 de Septiembre de 2012 Sheraton Panama Hotel & Convention Center Despedir a una persona es un delicado proceso invadido de bombas legales. No importa que tan preparado se sienta o que tan acertada sea su decisión, no hacerlo de la manera correcta lo pone en riesgo de una demanda. ¡¡Ningún Propietario, Gerente o Jefe debe terminar la relación de trabajo con un empleado sin antes asistir a este seminario!! Quality Training Panamá le presenta directamente los hechos que necesita saber para manejar con confianza esta difícil situación. Usted aprenderá a preparar cada caso incluyendo la documentación necesaria y las mejores estrategias para discutir el despido, sabrá cómo protegerse a sí mismo y a su compañía y sobre todo; aprenderá a eliminar el miedo y la frustración del proceso de despido. Pero usted es humano y es muy difícil ser el portador de la mala noticia que alguien va a perder su trabajo, peor aún si se trata de algún amigo o familiar, la manera como maneje el despido es ¡sumamente importante! ¡Es un Hecho! Hasta los Gerentes con el mejor plan corren el riesgo de cometer errores y no importa si se cometen con buena o mala intención, esto puede derivar en una costosa demanda para usted y su compañía y en una situación de pánico hasta los Gerentes y Supervisores más experimentados pueden meterse en graves problemas ¿Por qué arriesgarse? Este seminario le ofrece: - Las estrategias que tanto usted como su compañía necesitan para sobrevivir legalmente a los despidos. - Terminar con el miedo y la frustración que acompaña el despido de un trabajador. - Asegurarse que todo despido realizado sea 100% bajo el marco legal. - Evitar los riesgos de las demandas por despedir a alguien de manera incorrecta. Adquiera la información completa y sin compromiso, solo responda este correo con asunto -Deseo Folleto Balanced o Comuníquese al (507) 279-1083 / 279-0258 / 279-0887 - y a la brevedad lo recibirá! ESTE CORREO NO PUEDE SER CONSIDERADO INTRUSIVO YA QUE CUMPLE CON LAS POLÍTICAS ANTISPAM INTERNACIONALES Y LOCALES: Responda este correo con el Asunto borrar y automáticamente quedará fuera de nuestras listas. Este correo ha sido enviado at...@openbsd.org
Re: [PATCH] Add send(2) MSG_DONTWAIT support
I'm going to commit. ok or commet are still welcome.
On Tue, 18 Sep 2012 22:27:19 +0200
Alexander Bluhm wrote:
> On Fri, Sep 07, 2012 at 01:43:29PM +0900, UMEZAWA Takeshi wrote:
>> I have added send(2) MSG_DONTWAIT support, which enables us to choose
>> nonblocking or blocking for each send(2) call.
>
> I think this diff is OK.
>
> Does anyone know why SS_NBIO and MSG_DONTWAIT are not used identically
> in sosend() and soreceive()? Especially locking the socket buffer
> sblock() with SS_NBIO is different in sosend() and soreceive().
>
> Should't SS_NBIO and MSG_DONTWAIT be evaluated consistently everywhere?
I looked into sosend()/soreceive() for a hour, but it's still mystery
for me..
But I think the diff itself will not hurt anything.
>> diff --git a/lib/libc/sys/send.2 b/lib/libc/sys/send.2
>> index d58588f..b3b8d93 100644
>> --- a/lib/libc/sys/send.2
>> +++ b/lib/libc/sys/send.2
>> @@ -103,6 +103,8 @@ bypass routing, use direct interface
>> .It Dv MSG_NOSIGNAL
>> don't send
>> .Dv SIGPIPE
>> +.It Dv MSG_DONTWAIT
>> +don't block
>> .El
>> .Pp
>> The flag
>> diff --git a/sys/kern/uipc_socket.c b/sys/kern/uipc_socket.c
>> index 653de7d..10ef153 100644
>> --- a/sys/kern/uipc_socket.c
>> +++ b/sys/kern/uipc_socket.c
>> @@ -451,7 +451,7 @@ restart:
>> snderr(EMSGSIZE);
>> if (space < resid + clen &&
>> (atomic || space < so->so_snd.sb_lowat || space < clen)) {
>> -if (so->so_state & SS_NBIO)
>> +if ((so->so_state & SS_NBIO) || (flags & MSG_DONTWAIT))
>> snderr(EWOULDBLOCK);
>> sbunlock(&so->so_snd);
>> error = sbwait(&so->so_snd);
Re: ln -s example
On 12-09-20 8:34 AM, Amit Kulkarni wrote: This is very helpful. Usually in OpenBSD, you create a symbolic link /var/www which has limited space and have it point to /home/www where actual data is stored and which has more space. This particular example could be Create a symbolic link named /var/www and point it to /home/www: # ln -s /home/www /var/www A good example is one that actually works. Since /var/www exists in the default configuration on OpenBSD, your example will create a symlink in the real /var/ww called www, pointing to /home/www, and will never get used. $ sudo ln -s /home/www /var/www $ ls -l /var/www/www lrwxr-xr-x 1 root daemon 9 Sep 20 12:36 /var/www/www -> /home/www $ To make it work, you'd have to explain the rationale, show the command for moving the contents (bikeshed warning!), then rmdir /var/www, and finally do your symlink. It's not worth it. Pick a simpler example.
Productividad y Excelencia Para Asistentes Administrativas y Secretarias
Congreso Internacional Productividad y Excelencia para Secretarias Ejecutivas Panama este 17 y 18 de Octubre de 2012 Sheraton Panama Hotel & Convention Center ¡En esta Era de cambios dramáticos en el mundo de los negocios, las Asistentes tienen más retos que nunca. Se espera que usted haga lo que sea necesario para mantener el tren en marcha en medio de la confusión que trae la re ingeniería, reestructuración, la nueva tecnología o cualquiera de los cambios que esté enfrentando su empresa. ¡ Un encuentro único que usted no puede dejar pasar!! En este Congreso aprenderá a - Construir y fortalecer sus relaciones interpersonales - Manejar múltiples proyectos, responsabilidades y jefes - Hacer más en menos tiempo - ¡Conviértase en una asistente estrella indispensable! ¡Impulse sus habilidades de comunicación, su productividad, su desarrollo profesional y su satisfacción personal! Adquiera la información completa y sin compromiso, solo responda este correo con asunto -Deseo Folleto Secretarias o Comuníquese al (507) 279-1083 / 279-0258 / 279-0887 - y a la brevedad lo recibirá! ESTE CORREO NO PUEDE SER CONSIDERADO INTRUSIVO YA QUE CUMPLE CON LAS POLÍTICAS ANTISPAM INTERNACIONALES Y LOCALES: Responda este correo con el Asunto borrar y automáticamente quedará fuera de nuestras listas. Este correo ha sido enviado a: tech@openbsd.org
Promotion, LED flood light, led downlight
Hello Friends, Mainlux Lighting here, now our led flood light and downlight are under promotion! Here we attached the price list for your reference. Sample order are always welcome! Thanks & Best Regards Oskar / Sales Manager Mainlux Lighting Technology Co.,Ltd Address: 3F,A2 Buliding ,Baosheng Industrial Area , Xixiang Town ,Baoan,Shenzhen,China Tel: +86-755-32905601Fax: +86-755-32905602 Email: sa...@mainlux-led.com mainlux...@gmail.com www.mainlux-led.com [demime 1.01d removed an attachment of type application/pdf which had a name of =?GBK?B?TWFpbmx1eC1mbG9vZGxpZ2h0IHByaWNlbGlzdC5wZGY=?=] [demime 1.01d removed an attachment of type application/pdf which had a name of =?GBK?B?TWFpbmx1eC1DT0IgZG93bmxpZ2h0IHByaWNlbGlzdC5wZGY=?=]
Re: ln -s example
>> > shouldn't this order be flipped? >> > >> >> the example does what its description says. why do you think it should >> be reversed? > > because people are often confused by symlinks? I always tell the > confused: the order is the same as cp(1): the first argument needs to > exits, the second one is created. > > -Otto This is very helpful. Usually in OpenBSD, you create a symbolic link /var/www which has limited space and have it point to /home/www where actual data is stored and which has more space. This particular example could be Create a symbolic link named /var/www and point it to /home/www: # ln -s /home/www /var/www
Re: Threads related SIGSEGV in random.c
On 2012/09/20 12:04, Paul Irofti wrote: > On Thu, Sep 20, 2012 at 09:42:16AM +0100, Stuart Henderson wrote: > > On 2012/09/19 22:06, Stefan Sperling wrote: > > > On Wed, Sep 19, 2012 at 10:37:09PM +0300, Alexey Suslikov wrote: > > > > Could you guide me how to rebuild/reinstall libc in a proper way? > > > > > > It's easy, just needs 11 steps. This is how I did it: > > > > > > 1) $ cd /usr/src/lib/libc > > > 2) edit files > > > 3) $ make obj > > > 4) $ make clean > > > 5) $ make > > > 6) pray !!! > > > 7) $ sudo make install > > > 8) ??? > > > 9) Realise that step 7) should really be: > > >$ sudo cp /usr/lib/libc.so.66.0 /usr/lib/libc.so.66.0.bak > > >$ sudo make install > > > 10) reinstall system from snapshot > > > > see? step 6 was pointless! > > Stop saying that or you'll get people mobing the streets destroying your > town. That's not until bonfire night! http://0.tqn.com/d/gouk/1/0/W/X/-/-/72410447.jpg
Re: Threads related SIGSEGV in random.c
On Thu, Sep 20, 2012 at 09:42:16AM +0100, Stuart Henderson wrote: > On 2012/09/19 22:06, Stefan Sperling wrote: > > On Wed, Sep 19, 2012 at 10:37:09PM +0300, Alexey Suslikov wrote: > > > Could you guide me how to rebuild/reinstall libc in a proper way? > > > > It's easy, just needs 11 steps. This is how I did it: > > > > 1) $ cd /usr/src/lib/libc > > 2) edit files > > 3) $ make obj > > 4) $ make clean > > 5) $ make > > 6) pray !!! > > 7) $ sudo make install > > 8) ??? > > 9) Realise that step 7) should really be: > >$ sudo cp /usr/lib/libc.so.66.0 /usr/lib/libc.so.66.0.bak > >$ sudo make install > > 10) reinstall system from snapshot > > see? step 6 was pointless! Stop saying that or you'll get people mobing the streets destroying your town. One does not simply laugh about Prophet Stefan's commandent number 6!
Re: Threads related SIGSEGV in random.c
On Thu, Sep 20, 2012 at 09:42:16AM +0100, Stuart Henderson wrote: > On 2012/09/19 22:06, Stefan Sperling wrote: > > On Wed, Sep 19, 2012 at 10:37:09PM +0300, Alexey Suslikov wrote: > > > Could you guide me how to rebuild/reinstall libc in a proper way? > > > > It's easy, just needs 11 steps. This is how I did it: > > > > 1) $ cd /usr/src/lib/libc > > 2) edit files > > 3) $ make obj > > 4) $ make clean > > 5) $ make > > 6) pray !!! > > 7) $ sudo make install > > 8) ??? > > 9) Realise that step 7) should really be: > >$ sudo cp /usr/lib/libc.so.66.0 /usr/lib/libc.so.66.0.bak > >$ sudo make install > > 10) reinstall system from snapshot > > see? step 6 was pointless! > > > 11) goto 2) Plus sudo needs a shared libc, so if you break libc you cannot copy a working one back unless yhou already have a root shell available. I remember doing that quite often in the early days of my malloc work. -Otto
Re: Threads related SIGSEGV in random.c
On Thu, Sep 20, 2012 at 09:15:42AM +0200, Remco wrote: > AFAICT at least the tools in /bin and /sbin are statically linked and would > need to be rebuilt to include any changes in libc. That's correct, and it's actually very convenient. If you make some mistake dynamic binaries might no longer be able to run because they fail to load libc. In that case, statically linked cp or mv can still fix your system if you have a backup of the original libc file. You can also crank the major library version in /usr/src/lib/libc/shlib_version before compiling your modified libc, so that only newly compiled programs will use it. > To take into account statically built binaries and since basically > everything else depends on libc, my advise is to rebuild/install at least > the whole base system from source. This way you should be able to test if > your system survives a reboot and some basic system usage with your changes > included. (You may actually need to build the base system once more to > check if the build itself didn't break) Usually, if you're hacking libc, you'll also be writing test programs that use the interfaces you're modifying or adding. It makes sense to run those little test programs before committing to rebuilding everything with the modified libc. Sometimes I even linked test programs directly to the libc in /usr/obj to save time (though I don't recall the details of how I did that -- I think it was easy for static linking but there were some impossible warp space hoops to jump through for the dynamic case). > Eventually xenocara and probably a ports bulk build would be necessary as > well. Yes. And building a release(8) and testing the resulting snapshot. I once broke disklabel(8), in the installer only, by changing libc (in the UTF-8 commit that was quoted on undeadly.org). Effects of libc changes tend to pop up in unexpected places. However, I suppose wrapping random() in a mutex can't break that much. Or can it? :)
Re: Threads related SIGSEGV in random.c
On 2012/09/19 22:06, Stefan Sperling wrote: > On Wed, Sep 19, 2012 at 10:37:09PM +0300, Alexey Suslikov wrote: > > Could you guide me how to rebuild/reinstall libc in a proper way? > > It's easy, just needs 11 steps. This is how I did it: > > 1) $ cd /usr/src/lib/libc > 2) edit files > 3) $ make obj > 4) $ make clean > 5) $ make > 6) pray !!! > 7) $ sudo make install > 8) ??? > 9) Realise that step 7) should really be: >$ sudo cp /usr/lib/libc.so.66.0 /usr/lib/libc.so.66.0.bak >$ sudo make install > 10) reinstall system from snapshot see? step 6 was pointless! > 11) goto 2)
help testing bridge diff
I need help testing this bridge diff, as I cannot test (or even imagine)
all the possible bridge setups.
It brings a nice speed improvement and simplifies the code.
Testing especially appreciated with gif, tun and vether interfaces in the
bridge.
I can provide i386 and amd64 kernels to make it convenient. :-)
Thanks!
Index: dev/isa/if_ie.c
===
RCS file: /cvs/src/sys/dev/isa/if_ie.c,v
retrieving revision 1.35
diff -u -p -r1.35 if_ie.c
--- dev/isa/if_ie.c 28 Nov 2008 02:44:17 - 1.35
+++ dev/isa/if_ie.c 18 Sep 2012 09:55:59 -
@@ -1054,16 +1054,16 @@ check_eh(sc, eh, to_bpf)
*/
#if NBPFILTER > 0
*to_bpf = (sc->sc_arpcom.ac_if.if_bpf != 0) ||
- (sc->sc_arpcom.ac_if.if_bridge != NULL);
+ (sc->sc_arpcom.ac_if.if_bridgeport != NULL);
#else
- *to_bpf = (sc->sc_arpcom.ac_if.if_bridge != NULL);
+ *to_bpf = (sc->sc_arpcom.ac_if.if_bridgeport != NULL);
#endif
/* If for us, accept and hand up to BPF */
if (ether_equal(eh->ether_dhost, sc->sc_arpcom.ac_enaddr))
return 1;
#if NBPFILTER > 0
- if (*to_bpf && sc->sc_arpcom.ac_if.if_bridge == NULL)
+ if (*to_bpf && sc->sc_arpcom.ac_if.if_bridgeport == NULL)
*to_bpf = 2; /* we don't need to see it */
#endif
@@ -1095,9 +1095,9 @@ check_eh(sc, eh, to_bpf)
*/
#if NBPFILTER > 0
*to_bpf = (sc->sc_arpcom.ac_if.if_bpf != 0) ||
- (sc->sc_arpcom.ac_if.if_bridge != NULL);
+ (sc->sc_arpcom.ac_if.if_bridgeport != NULL);
#else
- *to_bpf = (sc->sc_arpcom.ac_if.if_bridge != NULL);
+ *to_bpf = (sc->sc_arpcom.ac_if.if_bridgeport != NULL);
#endif
/* We want to see multicasts. */
if (eh->ether_dhost[0] & 1)
@@ -1109,7 +1109,7 @@ check_eh(sc, eh, to_bpf)
/* Anything else goes to BPF but nothing else. */
#if NBPFILTER > 0
- if (*to_bpf && sc->sc_arpcom.ac_if.if_bridge == NULL)
+ if (*to_bpf && sc->sc_arpcom.ac_if.if_bridgeport == NULL)
*to_bpf = 2;
#endif
return 1;
Index: net/bridgestp.c
===
RCS file: /cvs/src/sys/net/bridgestp.c,v
retrieving revision 1.40
diff -u -p -r1.40 bridgestp.c
--- net/bridgestp.c 9 Jul 2011 04:53:33 - 1.40
+++ net/bridgestp.c 18 Sep 2012 09:56:00 -
@@ -1640,7 +1640,6 @@ void
bstp_ifstate(void *arg)
{
struct ifnet *ifp = (struct ifnet *)arg;
- struct bridge_softc *sc;
struct bridge_iflist *p;
struct bstp_port *bp;
struct bstp_state *bs;
@@ -1648,16 +1647,11 @@ bstp_ifstate(void *arg)
if (ifp->if_type == IFT_BRIDGE)
return;
- sc = (struct bridge_softc *)ifp->if_bridge;
s = splnet();
- LIST_FOREACH(p, &sc->sc_iflist, next) {
- if ((p->bif_flags & IFBIF_STP) == 0)
- continue;
- if (p->ifp == ifp)
- break;
- }
- if (p == LIST_END(&sc->sc_iflist))
+ if ((p = (struct bridge_iflist *)ifp->if_bridgeport) == NULL)
+ goto done;
+ if ((p->bif_flags & IFBIF_STP) == 0)
goto done;
if ((bp = p->bif_stp) == NULL)
goto done;
@@ -2120,7 +2114,7 @@ bstp_ifsflags(struct bstp_port *bp, u_in
int
bstp_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
{
- struct bridge_softc *sc = (struct bridge_softc *)ifp;
+ struct bridge_softc *sc = (struct bridge_softc *)ifp->if_softc;
struct bstp_state *bs = sc->sc_stp;
struct ifbrparam *ifbp = (struct ifbrparam *)data;
struct ifbreq *ifbr = (struct ifbreq *)data;
@@ -2137,15 +2131,8 @@ bstp_ioctl(struct ifnet *ifp, u_long cmd
err = ENOENT;
break;
}
- if ((caddr_t)sc != ifs->if_bridge) {
- err = ESRCH;
- break;
- }
- LIST_FOREACH(p, &sc->sc_iflist, next) {
- if (p->ifp == ifs)
- break;
- }
- if (p == LIST_END(&sc->sc_iflist)) {
+ p = (struct bridge_iflist *)ifs->if_bridgeport;
+ if (p == NULL || p->bridge_sc != sc) {
err = ESRCH;
break;
}
Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.241
diff -u -p -r1.241 if.c
--- net/if.c3 Jan 2012 23:41:51 - 1.241
+++ net/if.c18 Sep 2012 09:56:00 -
@@ -531,7 +531,7 @@ if_detach(struct ifnet *ifp)
#if NBRIDGE > 0
Re: Threads related SIGSEGV in random.c
Stefan Sperling wrote: > On Wed, Sep 19, 2012 at 10:37:09PM +0300, Alexey Suslikov wrote: >> Could you guide me how to rebuild/reinstall libc in a proper way? > > It's easy, just needs 11 steps. This is how I did it: > > 1) $ cd /usr/src/lib/libc > 2) edit files > 3) $ make obj > 4) $ make clean > 5) $ make > 6) pray !!! > 7) $ sudo make install > 8) ??? > 9) Realise that step 7) should really be: >$ sudo cp /usr/lib/libc.so.66.0 /usr/lib/libc.so.66.0.bak >$ sudo make install > 10) reinstall system from snapshot (I may be the clueless one here so don't take this for granted) In my mind the best result you'll get here is when the snapshot has a newer libc (e.g. libc.so.66.1) your packages may still be linked against your new libc.so.66.0 but nothing in the base system will. AFAICT at least the tools in /bin and /sbin are statically linked and would need to be rebuilt to include any changes in libc. To take into account statically built binaries and since basically everything else depends on libc, my advise is to rebuild/install at least the whole base system from source. This way you should be able to test if your system survives a reboot and some basic system usage with your changes included. (You may actually need to build the base system once more to check if the build itself didn't break) Eventually xenocara and probably a ports bulk build would be necessary as well. > 11) goto 2)
Re: ln -s example
On Thu, Sep 20, 2012 at 07:07:01AM +0100, Jason McIntyre wrote: > On Wed, Sep 19, 2012 at 06:44:29PM -0500, Amit Kulkarni wrote: > > shouldn't this order be flipped? > > > > the example does what its description says. why do you think it should > be reversed? because people are often confused by symlinks? I always tell the confused: the order is the same as cp(1): the first argument needs to exits, the second one is created. -Otto > > jmc > > > Index: ln.1 > > === > > RCS file: /cvs/src/bin/ln/ln.1,v > > retrieving revision 1.29 > > diff -u -p -r1.29 ln.1 > > --- ln.12 Mar 2011 07:47:21 - 1.29 > > +++ ln.119 Sep 2012 23:27:04 - > > @@ -130,7 +130,7 @@ Create a symbolic link named > > and point it to > > .Pa /var/www : > > .Pp > > -.Dl # ln -s /var/www /home/www > > +.Dl # ln -s /home/www /var/www > > .Pp > > Hard link > > .Pa /usr/local/bin/fooprog
