Лучшие почтовые рассылки
ËÓ×ØÈÅ ÐÀÑÑÛËÊÈ ÏÎ ÓÊÐÀÈÍÅ Âàì - ïî÷òîâàÿ ïîñûëêà Ïðåäëàãàåòñÿ ðàññûëêà Ìû êëèåíòîâ ïðèâåäåì Ðàäîñòü ôèðìàì ïðèíåñåì Ñòîèìîñòü ïî Óêðàèíå 800 ãðí, 3.9 ìëí ïîëó÷àòåëåé Ñòîèìîñòü ïî Êèåâó 700 ãðí, 1.7 ìëí ïîëó÷àòåëåé Ñòîèìîñòü ïî îáëàñòÿì Óêðàèíû - 400 ãðí E-mail: mailair2...@aol.com , ICQ: ×9Ç-179-46Î, Skype: abus.host
We got to meet. Details inside
I saw u having journey here and became aroused? Yeah, it's absolutely truth that I liked u from the first look. Usually I'm not calling or writing men first but some stuff happened to me when I checked up ur account. Oh, name of mine is Leandra. Write me about you. What's about your free time? What could impress you? Which food do u prefer? Will u write me tomorrow?;) I gonna be available at 10 pm tomorrow. Interested in having chat with you!
ongoing work on make
Some lucky people have been spammed with previous versions of this patch.
Caveat: this is work in progress, there might be bugs lurking.
Basically, I'm trying to achieve two goals:
- unify some more compat-make and make-j, so that there's less code duplication
and less weird semantics differences.
- give better, more precise error reports when things go wrong.
The main idea is that make-j used to spawn a subshell that would run commands.
This is all neat, except it gives main-make zero control over what's going
on, especially in case of trouble, and there was some ridiculously
complicated tail-optimization to avoid forking the last command when
possible.
Well, dpb does more or less the same work, but since I started it from scratch,
the architecture was radically different, with a single main process,
and a job data structure that would start each individual task in sequence,
continuation style.
In the process of the rewrite, I took apart the pipe stuff I added a few
years ago. Much to my surprise, it doesn't appear to be THAT useful now,
intermixed commands don't intermix so much, so I haven't put it back yet...
this also means that make-j now sees the terminal.
I also took apart the make as job control, since that's not really all
that useful either.
Right now, the error reports are probably TOO verbose, and there are probably
bugs to iron out. This seems to work thru make build without trouble.
Improvements you're likely to see with make-j:
- mentions the target being made in case of errors.
- pinpoints error location to the line of the command being run, instead
of a general in this target area.
- shows command last run in case of a fatal error and in case the command
was silent.
I have just kept compat-make running as it was, since the goal is to
remove its job-running code completely and use the same code as for jobs...
Index: engine.c
===
RCS file: /home/openbsd/cvs/src/usr.bin/make/engine.c,v
retrieving revision 1.30
diff -u -p -r1.30 engine.c
--- engine.c25 Aug 2012 08:12:56 - 1.30
+++ engine.c3 Sep 2012 11:30:03 -
@@ -66,13 +66,14 @@
static void MakeTimeStamp(void *, void *);
static int rewrite_time(const char *);
+typedef void (*psighandler)(int);
static void setup_signal(int, psighandler);
+static void setup_all_signals(void);
+static void notice_signal(int);
static void setup_meta(void);
static char **recheck_command_for_shell(char **);
-static int setup_and_run_command(char *, GNode *, int);
-static void run_command(const char *, bool);
-static int run_prepared_gnode(GNode *);
+static int setup_and_run_command(char *, GNode *);
static void handle_compat_interrupts(GNode *);
bool
@@ -464,27 +465,8 @@ setup_signal(int sig, psighandler h)
(void)signal(sig, h);
}
-void
-setup_all_signals(psighandler interrupt, psighandler jc)
-{
- /*
-* Catch the four signals that POSIX specifies if they aren't ignored.
-* handle_signal will take care of calling JobInterrupt if appropriate.
-*/
- setup_signal(SIGINT, interrupt);
- setup_signal(SIGHUP, interrupt);
- setup_signal(SIGQUIT, interrupt);
- setup_signal(SIGTERM, interrupt);
- setup_signal(SIGTSTP, jc);
- setup_signal(SIGTTOU, jc);
- setup_signal(SIGTTIN, jc);
- setup_signal(SIGWINCH, jc);
- setup_signal(SIGCONT, jc);
- got_signal = 0;
-}
-
-void
-SigHandler(int sig)
+static void
+notice_signal(int sig)
{
switch(sig) {
case SIGINT:
@@ -506,6 +488,20 @@ SigHandler(int sig)
}
}
+void
+setup_all_signals(void)
+{
+ /*
+* Catch the four signals that POSIX specifies if they aren't ignored.
+* handle_signal will take care of calling JobInterrupt if appropriate.
+*/
+ setup_signal(SIGINT, notice_signal);
+ setup_signal(SIGHUP, notice_signal);
+ setup_signal(SIGQUIT, notice_signal);
+ setup_signal(SIGTERM, notice_signal);
+ got_signal = 0;
+}
+
/* The following array is used to make a fast determination of which
* characters are interpreted specially by the shell. If a command
* contains any of these characters, it is executed by the shell, not
@@ -544,7 +540,7 @@ recheck_command_for_shell(char **av)
return av;
}
-static void
+void
run_command(const char *cmd, bool errCheck)
{
const char *p;
@@ -600,7 +596,7 @@ run_command(const char *cmd, bool errChe
*---
*/
static int
-setup_and_run_command(char *cmd, GNode *gn, int dont_fork)
+setup_and_run_command(char *cmd, GNode *gn)
{
bool silent;/* Don't print command */
bool doExecute; /* Execute the command */
@@ -635,24 +631,14 @@ setup_and_run_command(char *cmd, GNode *
cmd++;
/* Print the command before echoing if we're not supposed to be quiet
* for this one. We
Re: ongoing work on make
Date: Mon, 3 Sep 2012 13:59:44 +0200 From: Marc Espie es...@nerim.net In the process of the rewrite, I took apart the pipe stuff I added a few years ago. Much to my surprise, it doesn't appear to be THAT useful now, intermixed commands don't intermix so much, so I haven't put it back yet... this also means that make-j now sees the terminal. This makes me worried. I *don't* want to have make behave differently if it thinks it runs on a terminal.
Re: ongoing work on make
On Mon, Sep 03, 2012 at 02:20:34PM +0200, Mark Kettenis wrote: Date: Mon, 3 Sep 2012 13:59:44 +0200 From: Marc Espie es...@nerim.net In the process of the rewrite, I took apart the pipe stuff I added a few years ago. Much to my surprise, it doesn't appear to be THAT useful now, intermixed commands don't intermix so much, so I haven't put it back yet... this also means that make-j now sees the terminal. This makes me worried. I *don't* want to have make behave differently if it thinks it runs on a terminal. With that diff, compatmake and make -j now behaves the same way. You're worried ? you should have been worried ages ago, back when the difference happened.
Re: ongoing work on make
On Mon, Sep 03, 2012 at 02:20:34PM +0200, Mark Kettenis wrote: Date: Mon, 3 Sep 2012 13:59:44 +0200 From: Marc Espie es...@nerim.net In the process of the rewrite, I took apart the pipe stuff I added a few years ago. Much to my surprise, it doesn't appear to be THAT useful now, intermixed commands don't intermix so much, so I haven't put it back yet... this also means that make-j now sees the terminal. This makes me worried. I *don't* want to have make behave differently if it thinks it runs on a terminal. More precisely, I'm talking about commands run within make. With compatmake (make without -j): commands are run thru fork/exec, transparently. With -current make -j4: commands are run with stdout and stderr directed to a pipe (and in a separate process group). With the -current work: commands are run the same way with/without -j. Simply, fork/exec, transparently. make doesn't care at all whether you run things in a terminal or not. Commands run within make may care. make shouldn't interfere with that, as far as possible ! The pipe stuff was an attempt at serializing output properly, at some point we thought it would be difficult to make sense of multiple commands. Turns out things are ways better than expected, so there's no reason to do that.
arc4random_buf in bcrypt
There's an easy way to do this now.
Index: bcrypt.c
===
RCS file: /cvs/src/lib/libc/crypt/bcrypt.c,v
retrieving revision 1.24
diff -u -p -r1.24 bcrypt.c
--- bcrypt.c2 Apr 2008 19:54:05 - 1.24
+++ bcrypt.c3 Sep 2012 17:29:48 -
@@ -148,15 +148,8 @@ char *
bcrypt_gensalt(u_int8_t log_rounds)
{
u_int8_t csalt[BCRYPT_MAXSALT];
- u_int16_t i;
- u_int32_t seed = 0;
- for (i = 0; i BCRYPT_MAXSALT; i++) {
- if (i % 4 == 0)
- seed = arc4random();
- csalt[i] = seed 0xff;
- seed = seed 8;
- }
+ arc4random_buf(csalt, sizeof(csalt));
if (log_rounds 4)
log_rounds = 4;
Re: ThinkPad T60 x86emu panic on resume (w/patch)
* Theo de Raadt dera...@cvs.openbsd.org [120903 00:13]:
Index: vga_pci.c
===
RCS file: /cvs/src/sys/dev/pci/vga_pci.c,v
retrieving revision 1.68
diff -u -r1.68 vga_pci.c
--- vga_pci.c 22 Aug 2012 20:58:30 - 1.68
+++ vga_pci.c 2 Sep 2012 17:42:09 -
@@ -186,7 +186,13 @@
{ 0x, 0x, 0x, 0x }, 1, 0
},
- { /* All ATI video until further notice */
+ {
+ { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X1400,
+ 0x, 0x },
+ { 0x, 0x, 0x, 0x}, 0, 0
+ },
+
+ { /* Other ATI video until further notice */
{ PCI_VENDOR_ATI, 0x,
0x, 0x },
{ 0x, 0x, 0x, 0x}, 1, 0
That's a great patch, because it doesn't find or fix the underlying
issues.
Thanks.
Then, when the next person -- who's video did need this -- finds out
it no longer works, they can submit the inverse of your diff -- once
again not undercovering the real issue. Of course, now it is their
problem, not yours, right?
No, he'll add a record above mine with his subproduct/subvendor ids.
Your diff can be summarized as make it work for me, me, me, me.
Awesome work. You know how to fix it just for yourself and submit a
self-serving patch, hoping we'll commit it without looked deeper, so
truly you are now an open source wizard.
I don't hope you'll commit it as is. I hope you'll send some useful
comments and suggestions to improve the patch (not insults).
Now back to underlying issues: x86emu executes some code which causes
parity check NMI (bit 7 set in port 0x61) to be generated, which causes
drop to the debugger (I mistook it for a panic).
Btw, is it intended to not include isa.h in i386/trap.c? (removed in r.1.35).
Code wrapped in #if NISA 0 is thrown out by cpp now.
Re: arc4random_buf in bcrypt
Yup.
There's an easy way to do this now.
Index: bcrypt.c
===
RCS file: /cvs/src/lib/libc/crypt/bcrypt.c,v
retrieving revision 1.24
diff -u -p -r1.24 bcrypt.c
--- bcrypt.c 2 Apr 2008 19:54:05 - 1.24
+++ bcrypt.c 3 Sep 2012 17:29:48 -
@@ -148,15 +148,8 @@ char *
bcrypt_gensalt(u_int8_t log_rounds)
{
u_int8_t csalt[BCRYPT_MAXSALT];
- u_int16_t i;
- u_int32_t seed = 0;
- for (i = 0; i BCRYPT_MAXSALT; i++) {
- if (i % 4 == 0)
- seed = arc4random();
- csalt[i] = seed 0xff;
- seed = seed 8;
- }
+ arc4random_buf(csalt, sizeof(csalt));
if (log_rounds 4)
log_rounds = 4;
Re: ThinkPad T60 x86emu panic on resume (w/patch)
* Theo de Raadt dera...@cvs.openbsd.org [120903 00:13]:
Index: vga_pci.c
===
RCS file: /cvs/src/sys/dev/pci/vga_pci.c,v
retrieving revision 1.68
diff -u -r1.68 vga_pci.c
--- vga_pci.c 22 Aug 2012 20:58:30 - 1.68
+++ vga_pci.c 2 Sep 2012 17:42:09 -
@@ -186,7 +186,13 @@
{ 0x, 0x, 0x, 0x }, 1, 0
},
- { /* All ATI video until further notice */
+ {
+ { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X1400,
+ 0x, 0x },
+ { 0x, 0x, 0x, 0x}, 0, 0
+ },
+
+ { /* Other ATI video until further notice */
{ PCI_VENDOR_ATI, 0x,
0x, 0x },
{ 0x, 0x, 0x, 0x}, 1, 0
That's a great patch, because it doesn't find or fix the underlying
issues.
Thanks.
Then, when the next person -- who's video did need this -- finds out
it no longer works, they can submit the inverse of your diff -- once
again not undercovering the real issue. Of course, now it is their
problem, not yours, right?
No, he'll add a record above mine with his subproduct/subvendor ids.
I do not agree with that process.
Basically in 10 years we'll have a table full of garbage entries,
which would help only a handful of people. It is the wrong way to
approach this, and the cvs log already makes that clear.
There is code missing to handle all the types of video we need to
cleanup. This code you are looking at is not the solution. It is a
stupid quirk table.
Your diff can be summarized as make it work for me, me, me, me.
Awesome work. You know how to fix it just for yourself and submit a
self-serving patch, hoping we'll commit it without looked deeper, so
truly you are now an open source wizard.
I don't hope you'll commit it as is. I hope you'll send some useful
comments and suggestions to improve the patch (not insults).
We won't commit it.
Re: ThinkPad T60 x86emu panic on resume (w/patch)
On Mon, Sep 03, 2012 at 21:18, Alexander Polakov wrote: Now back to underlying issues: x86emu executes some code which causes parity check NMI (bit 7 set in port 0x61) to be generated, which causes drop to the debugger (I mistook it for a panic). Btw, is it intended to not include isa.h in i386/trap.c? (removed in r.1.35). Code wrapped in #if NISA 0 is thrown out by cpp now. Probably not, but after 11 years, it doesn't look like we used that code much. :) Putting the include back at the top of the file would be a good diff to propose. (I guess it may have been deleted because it looks funny in the middle of the file).
[clau...@openbsd.org: graceful restart diff]
I never got any negative test results back about this change. I assume
that either nobody is interested or that it just works. Since this is
getting in my way of working on bgpd I would like to commit this. So
unless people scream in the next few days it will go in and I will handle
the fallout when it happens.
--
:wq Claudio
- Forwarded message from Claudio Jeker clau...@openbsd.org -
Date: Mon, 9 Jul 2012 15:39:17 +0200
From: Claudio Jeker clau...@openbsd.org
To: tech@openbsd.org
Subject: graceful restart diff
Mail-Followup-To: tech@openbsd.org
OK, this is a fixed version of the graceful restart diff I have brewing
for a long long long time. It seems to behave in my bgpd test network but
I would like some wider testing (esp. against routers that do GR).
This implements only the Restarting Client bits of the RFC -- in other
words bgpd will keep the FIB when the client restarts but it will not do GR
when restarting itself. The capability is still off by default (you need
announce restart yes to enable it) and the best is to test first without
GR and if there are no regressions restest with GR enabled.
Make sure to run this on current -current since this needs some of the
recent bgpd commits.
--
:wq Claudio
Index: bgpctl/bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.164
diff -u -p -r1.164 bgpctl.c
--- bgpctl/bgpctl.c 27 May 2012 18:53:50 - 1.164
+++ bgpctl/bgpctl.c 8 Jul 2012 10:48:01 -
@@ -52,6 +52,7 @@ intshow_summary_terse_msg(struct imsg
int show_neighbor_terse(struct imsg *);
int show_neighbor_msg(struct imsg *, enum neighbor_views);
voidprint_neighbor_capa_mp(struct peer *);
+voidprint_neighbor_capa_restart(struct peer *);
voidprint_neighbor_msgstats(struct peer *);
voidprint_timer(const char *, time_t);
static char*fmt_timeframe(time_t t);
@@ -168,7 +169,7 @@ main(int argc, char *argv[])
case NONE:
case IRRFILTER:
usage();
- /* not reached */
+ /* NOTREACHED */
case SHOW:
case SHOW_SUMMARY:
imsg_compose(ibuf, IMSG_CTL_SHOW_NEIGHBOR, 0, 0, -1, NULL, 0);
@@ -648,7 +649,7 @@ show_neighbor_msg(struct imsg *imsg, enu
if (p-capa.peer.mp[i])
hascapamp = 1;
if (hascapamp || p-capa.peer.refresh ||
- p-capa.peer.restart || p-capa.peer.as4byte) {
+ p-capa.peer.grestart.restart || p-capa.peer.as4byte) {
printf( Neighbor capabilities:\n);
if (hascapamp) {
printf(Multiprotocol extensions: );
@@ -657,8 +658,11 @@ show_neighbor_msg(struct imsg *imsg, enu
}
if (p-capa.peer.refresh)
printf(Route Refresh\n);
- if (p-capa.peer.restart)
- printf(Graceful Restart\n);
+ if (p-capa.peer.grestart.restart) {
+ printf(Graceful Restart);
+ print_neighbor_capa_restart(p);
+ printf(\n);
+ }
if (p-capa.peer.as4byte)
printf(4-byte AS numbers\n);
}
@@ -726,6 +730,28 @@ print_neighbor_capa_mp(struct peer *p)
}
void
+print_neighbor_capa_restart(struct peer *p)
+{
+ int comma;
+ u_int8_ti;
+
+ if (p-capa.peer.grestart.timeout)
+ printf(: Timeout: %d, , p-capa.peer.grestart.timeout);
+ for (i = 0, comma = 0; i AID_MAX; i++)
+ if (p-capa.peer.grestart.flags[i] CAPA_GR_PRESENT) {
+ if (!comma
+ p-capa.peer.grestart.flags[i] CAPA_GR_RESTART)
+ printf(restarted, );
+ if (comma)
+ printf(, );
+ printf(%s, aid2str(i));
+ if (p-capa.peer.grestart.flags[i] CAPA_GR_FORWARD)
+ printf( (preserved));
+ comma = 1;
+ }
+}
+
+void
print_neighbor_msgstats(struct peer *p)
{
printf( Message statistics:\n);
@@ -753,6 +779,8 @@ print_neighbor_msgstats(struct peer *p)
p-stats.prefix_sent_update, p-stats.prefix_rcvd_update);
printf( %-15s %10llu %10llu\n, Withdraws,
p-stats.prefix_sent_withdraw, p-stats.prefix_rcvd_withdraw);
+ printf( %-15s %10llu %10llu\n, End-of-Rib,
+ p-stats.prefix_sent_eor, p-stats.prefix_rcvd_eor);
}
void
@@ -1107,8 +1135,8 @@ show_interface_msg(struct imsg *imsg)
void
show_rib_summary_head(void)
{
Re: Possible bug in timecounter code
On Sunday 02 September 2012, s...@sfritsch.de wrote: But it may still be a problem the other way round. If adjtimedelta would go to zero during the lost ticks, there will be some over-compensation that is not detected. After some more hints from Mark (thanks), I think this is very unlikely to cause a problem in practice, possibly except if running on a virtualization host that is overloaded/swapping.
Sync i386 NMI trap code with amd64
Include isa.h to avoid confusion while reading the code (code wrapped into #if NISA 0 is thrown out by cpp atm). No behaviour change, except for additional printf() before entering the debugger (which I find helpful). Ignore second chunk if you don't care about i386 and amd64 being the same. Btw, amd64/x86_nmi() reads ports which are called historic garbage by i386/isa_nmi(). Index: trap.c === RCS file: /cvs/src/sys/arch/i386/i386/trap.c,v retrieving revision 1.103 diff -u -r1.103 trap.c --- trap.c 7 Aug 2012 05:16:53 - 1.103 +++ trap.c 3 Sep 2012 21:49:26 - @@ -80,6 +80,7 @@ #endif #include npx.h +#include isa.h void trap(struct trapframe *); void syscall(struct trapframe *); @@ -509,13 +510,12 @@ if (kdb_trap(type, 0, frame)) return; #endif - return; #endif /* DDB || KGDB */ /* machine/parity/power fail/kitchen sink faults */ - if (isa_nmi() == 0) - return; - else + if (isa_nmi() != 0) goto we_re_toast; + else + return; #endif }
Re: inet6 autoconf spl fix
yes. On 02/09/2012, at 8:20 PM, Stefan Sperling s...@openbsd.org wrote: prelist_update() runs at IPL_SOFTNET. Code moved out of it into a workq task for adding new addresses from process context should run at IPL_SOFTNET, too, shouldn't it? Index: netinet6/nd6_rtr.c === RCS file: /cvs/src/sys/netinet6/nd6_rtr.c,v retrieving revision 1.62 diff -u -p -r1.62 nd6_rtr.c --- netinet6/nd6_rtr.c28 Aug 2012 20:32:02 - 1.62 +++ netinet6/nd6_rtr.c2 Sep 2012 10:01:34 - @@ -1298,7 +1298,9 @@ nd6_addr_add(void *prptr, void *arg2) struct nd_prefix *pr = (struct nd_prefix *)prptr; struct in6_ifaddr *ia6 = NULL; struct ifaddr *ifa; - int ifa_plen, autoconf, privacy; + int ifa_plen, autoconf, privacy, s; + + s = splsoftnet(); autoconf = 1; privacy = (pr-ndpr_ifp-if_xflags IFXF_INET6_NOPRIVACY) == 0; @@ -1362,6 +1364,8 @@ nd6_addr_add(void *prptr, void *arg2) pfxlist_onlink_check(); pr-ndpr_refcnt--; + + splx(s); } /*
