Re: Correct DPADD for iked' Makefile
On Sun, Sep 02, 2012 at 01:08:58AM -0400, Brad Smith wrote:
Whateve code that used to be within iked that used SSL was removed
but DPADD was not updated so its still looking for an unused libssl.
Index: Makefile
===
RCS file: /home/cvs/src/sbin/iked/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile 22 Dec 2010 17:43:10 - 1.6
+++ Makefile 28 Jul 2012 06:34:43 -
@@ -11,7 +11,7 @@ MAN=iked.conf.5 iked.8
#NOMAN= yes
LDADD= -lutil -levent -lcrypto
-DPADD= ${LIBUTIL} ${LIBEVENT} ${LIBSSL} ${LIBCRYPTO}
+DPADD= ${LIBUTIL} ${LIBEVENT} ${LIBCRYPTO}
CFLAGS+= -Wall -I${.CURDIR}
CFLAGS+= -Wstrict-prototypes -Wmissing-prototypes
CFLAGS+= -Wmissing-declarations
Well, I have a LIBRARIES patch that would make this easier to keep in
synch eventually...
whenever people are not so busy with -pie and basically thinking I'm
wasting time with useless stuff...
Basically, add this to bsd.prog.mk
.if defined(LIBRARIES) !empty(LIBRARIES)
. for l in ${LIBRARIES}
LDADD += -l$l
DPADD += ${LIB${l:U}}
. endfor
.endif
then replace the above with:
LIBRARIES = util event crypto
and have LDADD and DPADD magically stay in synch !
naming subject to discussion...
Re: [Patch] Virtio drivers for OpenBSD V8
On Saturday 01 September 2012, LEVAI Daniel wrote: I've just started to test this with an OpenBSD guest on a Linux host. vio0 NIC and the virtio disk work like a charm. I have a slightly (~10%) better performance with the ide emulation than with virtio, but nevertheless it works. Thanks for testing. How did you test the performance? Well, weird thing is that some time after I've sent this mail, a few messages appeared in the logs while updating /usr/ports on the guest: virtio timeout vioblk0: sc_queued 5 vq_num 128 vq_avail_idx: 27965 vq_avail-idx: 27965 vq_avail-flags: 1 vq_used_idx: 27960 vq_used-idx: 27960 vq_used-flags: 0 Are these errors or just some debug information for the devs? These are just debugging leftovers. I will remove them in the next version.
inet6 autoconf spl fix
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.c 28 Aug 2012 20:32:02 - 1.62 +++ netinet6/nd6_rtr.c 2 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); } /*
Reduce false cache line sharing in page tables
Since the Pentium 4, cachelines are 64 byte on x86, not 32 byte. The pmap optimization should be adjusted accordingly: --- sys/arch/i386/i386/pmapae.c +++ sys/arch/i386/i386/pmapae.c @@ -516,10 +516,10 @@ typedef u_int64_t pd_entry_t; /* PDE */ typedef u_int64_t pt_entry_t; /* PTE */ /* - * Number of PTE's per cache line. 8 byte pte, 32-byte cache line + * Number of PTE's per cache line. 8 byte pte, 64-byte cache line * Used to avoid false sharing of cache lines. */ -#defineNPTECL 4 +#defineNPTECL 8 /* * other data structures --- sys/arch/i386/include/pmap.h +++ sys/arch/i386/include/pmap.h @@ -229,10 +229,10 @@ #definePG_XPG_AVAIL3 /* executable mapping */ /* - * Number of PTE's per cache line. 4 byte pte, 32-byte cache line + * Number of PTE's per cache line. 4 byte pte, 64-byte cache line * Used to avoid false sharing of cache lines. */ -#define NPTECL 8 +#define NPTECL 16 #ifdef _KERNEL /*
Possible bug in timecounter code
tc_windup() calls ntp_update_second() up to 200 times:
/*
* A large step happens on boot. This constant detects such steps.
* It is relatively small so that ntp_update_second gets called enough
* in the typical 'missed a couple of seconds' case, but doesn't loop
* forever when the time step is large.
*/
#define LARGE_STEP 200
ntp_update_second() subtracts some amount of time from adjtimedelta and
sets th-th_adjustment accordingly. However, if ntp_update_second is
called more than once in a row, only the last value of th-th_adjustment
is actually applied. Shouldn't the adjustments from all ntp_update_second
calls be added instead? I don't know how often this is actually hit in
practice, the normal case is that ntp_update_second is called only once.
diff --git sys/kern/kern_tc.c sys/kern/kern_tc.c
index 59b31dc..60ea119 100644
--- sys/kern/kern_tc.c
+++ sys/kern/kern_tc.c
@@ -425,8 +426,12 @@ tc_windup(void)
i = bt.sec - tho-th_microtime.tv_sec;
if (i LARGE_STEP)
i = 2;
- for (; i 0; i--)
- ntp_update_second(th-th_adjustment, bt.sec);
+ th-th_adjustment = 0;
+ for (; i 0; i--) {
+ uint64_t adj;
+ ntp_update_second(adj, bt.sec);
+ th-th_adjustment += adj;
+ }
/* Update the UTC timestamps used by the get*() functions. */
/* XXX shouldn't do this here. Should force non-`get' versions. */
allow v6 privacy and static addresses to co-exist again
Simon's recent commit to prevent SLAAC address formation when
a static address is already configured has a side-effect for
autoconfprivacy users.
With the following in /etc/hostname.if:
dhcp
rtsol
inet6 some-address 64
the netstart script will run rtsol after assigning the static address,
hence preventing privacy addresses from being formed. The only effect
of 'rtsol' in this case is an auto-configured default route.
If a privacy address is manually configured first and a static address
second, the interface initially has both. But the static address prevents
creation of new addresses during RA reception. When the privacy address
becomes deprecated a fresh address is not added, breaking autoconfprivacy.
So using privacy addresses for outgoing connections and static addresses
for incoming connections is no longer possible. Do we want to support
this use case? It used to work ever since privacy addresses were introduced.
The diff below makes static addresses prevent SLAAC addresses in the
no-privacy case but allows static and privacy addresses to co-exist.
Because we create SLAAC addresses alongside privacy addresses, this
effectively reverts the default behaviour to what it was before
Simon's change. With the hostname.if snippet above we get:
- auto-configured default route
- SLAAC address
- privacy addresses (rotating over time)
- a static address
Those who prefer traditional inet6 behaviour can use:
dhcp
-autoconfprivacy
rtsol
This results in:
- auto-configured default route
- SLAAC address
Or:
dhcp
-autoconfprivacy
rtsol
inet6 some-address 64
This results in:
- auto-configured default route
- a static address
ok?
Index: 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
--- nd6_rtr.c 28 Aug 2012 20:32:02 - 1.62
+++ nd6_rtr.c 2 Sep 2012 11:33:44 -
@@ -1275,7 +1275,8 @@ prelist_update(struct nd_prefix *new, st
}
if ((!autoconf || ((ifp-if_xflags IFXF_INET6_NOPRIVACY) == 0
- !tempaddr_preferred)) new-ndpr_vltime != 0 !statique) {
+ !tempaddr_preferred)) new-ndpr_vltime != 0
+ !((ifp-if_xflags IFXF_INET6_NOPRIVACY) statique)) {
/*
* There is no SLAAC address and/or there is no preferred RFC
* 4941 temporary address. And the valid prefix lifetime is
Re: Possible bug in timecounter code
Date: Sun, 2 Sep 2012 13:18:03 +0200 (CEST)
From: Stefan Fritsch s...@sfritsch.de
tc_windup() calls ntp_update_second() up to 200 times:
/*
* A large step happens on boot. This constant detects such steps.
* It is relatively small so that ntp_update_second gets called enough
* in the typical 'missed a couple of seconds' case, but doesn't loop
* forever when the time step is large.
*/
#define LARGE_STEP 200
ntp_update_second() subtracts some amount of time from adjtimedelta and
sets th-th_adjustment accordingly. However, if ntp_update_second is
called more than once in a row, only the last value of th-th_adjustment
is actually applied. Shouldn't the adjustments from all ntp_update_second
calls be added instead? I don't know how often this is actually hit in
practice, the normal case is that ntp_update_second is called only once.
No, this isn't right th_adjustment is the rate at which we speed up or
slow down the clock. We shouldn't suddenly increase that rate just
because we lost a few clock ticks.
diff --git sys/kern/kern_tc.c sys/kern/kern_tc.c
index 59b31dc..60ea119 100644
--- sys/kern/kern_tc.c
+++ sys/kern/kern_tc.c
@@ -425,8 +426,12 @@ tc_windup(void)
i = bt.sec - tho-th_microtime.tv_sec;
if (i LARGE_STEP)
i = 2;
- for (; i 0; i--)
- ntp_update_second(th-th_adjustment, bt.sec);
+ th-th_adjustment = 0;
+ for (; i 0; i--) {
+ uint64_t adj;
+ ntp_update_second(adj, bt.sec);
+ th-th_adjustment += adj;
+ }
/* Update the UTC timestamps used by the get*() functions. */
/* XXX shouldn't do this here. Should force non-`get' versions. */
Re: Possible bug in timecounter code
On Sun, 2 Sep 2012, Mark Kettenis wrote: ntp_update_second() subtracts some amount of time from adjtimedelta and sets th-th_adjustment accordingly. However, if ntp_update_second is called more than once in a row, only the last value of th-th_adjustment is actually applied. Shouldn't the adjustments from all ntp_update_second calls be added instead? I don't know how often this is actually hit in practice, the normal case is that ntp_update_second is called only once. No, this isn't right th_adjustment is the rate at which we speed up or slow down the clock. We shouldn't suddenly increase that rate just because we lost a few clock ticks. But then subtracting the amount from adjtimedelta seems wrong. I expect that it may confuse the ntp daemon, because adjtime() may not give the expected effect. Maybe it would be better to count the times th_adjustment is applied and subtract the actual adjusted amount from adjtimedelta after it is done, instead of subtracting the amount from adjtimedelta that hopefully will be applied if everything goes well?
Re: Possible bug in timecounter code
Date: Sun, 2 Sep 2012 17:22:28 +0200 (CEST) From: s...@sfritsch.de On Sun, 2 Sep 2012, Mark Kettenis wrote: ntp_update_second() subtracts some amount of time from adjtimedelta and sets th-th_adjustment accordingly. However, if ntp_update_second is called more than once in a row, only the last value of th-th_adjustment is actually applied. Shouldn't the adjustments from all ntp_update_second calls be added instead? I don't know how often this is actually hit in practice, the normal case is that ntp_update_second is called only once. No, this isn't right th_adjustment is the rate at which we speed up or slow down the clock. We shouldn't suddenly increase that rate just because we lost a few clock ticks. But then subtracting the amount from adjtimedelta seems wrong. I expect that it may confuse the ntp daemon, because adjtime() may not give the expected effect. Maybe it would be better to count the times th_adjustment is applied and subtract the actual adjusted amount from adjtimedelta after it is done, instead of subtracting the amount from adjtimedelta that hopefully will be applied if everything goes well? No, that code is correct as well. We have been running the clock at the adjusted rate during the missed ticks as well, so we need to adjust adjtimedelta for each missed tick.
Re: ThinkPad T60 x86emu panic on resume (w/patch)
With the diff below it resumes ok to X, but when I try to switch
to text console or do a shutdown, I get this panic:
/etc/rc.shutdown in progress...
/etc/rc.shutdown complete.
Stopped at cpu_idle_cycle+0xf: ret
ddb{1} bt
No such command
ddb{1} trace
cpu_idle_cycle(d406ac00) at cpu_idle_cycle+0xf
Bad frame pointer: 0xf546ef5c
ddb{1} machine ddbcpu 0
Stopped at Debugger+0x4: popl%ebp
ddb{0} bt
No such command
ddb{0} trace
Debugger(d0b035e0,f54c2f08,0,14,6b) at Debugger+0x4
i386_ipi_handler(0,20,0,f54c0010,d0510010) at i386_ipi_handler+0x5f
Xintripi() at Xintripi+0x49
--- interrupt ---
kputchar(6b,14,0,1,0) at kputchar+0x1a
kprintf(d08f3d1a,14,0,0,f54c2ef8) at kprintf+0x254
db_printf(d08f3d1a,1b88d72e,b,d03db6c2,0) at db_printf+0x3e
kdbprinttrap(109,0,d9ddae24,1000,d0a47d44) at kdbprinttrap+0x1e
kdb_trap(109,0,f54c2fa8,3,ffee3bd) at kdb_trap+0x1fc
trap() at trap+0x2e7
--- trap (number 0) ---
0:
ddb{0}
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
* Alexander Polakov p...@sdf.org [120902 21:40]:
Suspending system...
# Stopped at x86emu_halt_sys+0x47f7: movl0x40(%edi),%ecx
x86emu_halt_sys(d408804c,3,f5470d6c,d0725f1c,d4088000) at
x86emu_halt_sys+0x47f
7
x86emu_exec(d4088000,c000,3,d05b0887,0) at x86emu_exec+0x41
vga_post_call(d4088000,c0,f5470dbc,f5470d8c,d4016400) at vga_post_call+0x6c
vga_pci_activate(d4016400,3,f5470dbc,d05b2208,d3f29180) at
vga_pci_activate+0x9
8
config_activate_children(d3f29180,3,f5470dec,d05b019c,0) at
config_activate_chi
ldren+0x45
config_activate_children(d4016600,3,4,100107,f5470e1c) at
config_activate_child
ren+0x45
ppbactivate(d4016600,3,f5470e5c,d05b2208,d3f29380) at ppbactivate+0x345
config_activate_children(d3f29380,3,f5470e8c,d0840914,c0) at
config_activate_ch
ildren+0x45
config_activate_children(d4015fc0,3,1,f5470ebc,0) at
config_activate_children+0
x45
acpi_resume(d4013c00,3,0,d409a560,d4013c00) at acpi_resume+0x134
ddb{0} trace
x86emu_halt_sys(d408804c,3,f5470d6c,d0725f1c,d4088000) at
x86emu_halt_sys+0x47f
7
x86emu_exec(d4088000,c000,3,d05b0887,0) at x86emu_exec+0x41
vga_post_call(d4088000,c0,f5470dbc,f5470d8c,d4016400) at vga_post_call+0x6c
vga_pci_activate(d4016400,3,f5470dbc,d05b2208,d3f29180) at
vga_pci_activate+0x9
8
config_activate_children(d3f29180,3,f5470dec,d05b019c,0) at
config_activate_chi
ldren+0x45
config_activate_children(d4016600,3,4,100107,f5470e1c) at
config_activate_child
ren+0x45
ppbactivate(d4016600,3,f5470e5c,d05b2208,d3f29380) at ppbactivate+0x345
config_activate_children(d3f29380,3,f5470e8c,d0840914,c0) at
config_activate_ch
ildren+0x45
config_activate_children(d4015fc0,3,1,f5470ebc,0) at
config_activate_children+0
x45
acpi_resume(d4013c00,3,0,d409a560,d4013c00) at acpi_resume+0x134
acpi_sleep_state(d4013c00,3,0,d0840d41,d409a560) at acpi_sleep_state+0x7a
acpi_sleep_task(d4013c00,3,d9fd0744,1,d4013c00) at acpi_sleep_task+0x1a
acpi_dotask(d4013c00,20,d09ccf9d,0,d03db6c2) at acpi_dotask+0x42
acpi_thread(d3f27770) at acpi_thread+0x123
Bad frame pointer: 0xd0bbbe28
ddb{0} boot reboot
cbb0: bad Vcc request. sock_ctrl 0xff88, sock_status 0x
rebooting...
Re: Possible bug in timecounter code
On Sun, 2 Sep 2012, Mark Kettenis wrote: On Sun, 2 Sep 2012, Mark Kettenis wrote: ntp_update_second() subtracts some amount of time from adjtimedelta and sets th-th_adjustment accordingly. However, if ntp_update_second is called more than once in a row, only the last value of th-th_adjustment is actually applied. Shouldn't the adjustments from all ntp_update_second calls be added instead? I don't know how often this is actually hit in practice, the normal case is that ntp_update_second is called only once. No, this isn't right th_adjustment is the rate at which we speed up or slow down the clock. We shouldn't suddenly increase that rate just because we lost a few clock ticks. But then subtracting the amount from adjtimedelta seems wrong. I expect that it may confuse the ntp daemon, because adjtime() may not give the expected effect. Maybe it would be better to count the times th_adjustment is applied and subtract the actual adjusted amount from adjtimedelta after it is done, instead of subtracting the amount from adjtimedelta that hopefully will be applied if everything goes well? No, that code is correct as well. We have been running the clock at the adjusted rate during the missed ticks as well, so we need to adjust adjtimedelta for each missed tick. OK, it probably cannot happen that adjtimedelta is changed while the ticks are missed. 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. How likely is it that ticks are lost? Will timer interrupts be routed to the cpu that has the kernel lock? Or can the timer interrupt run without the kernel lock? Cheers, Stefan
Re: ThinkPad T60 x86emu panic on resume (w/patch)
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.
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?
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.
/sarcasm
Re: ThinkPad T60 x86emu panic on resume (w/patch)
On 2 September 2012 21:13, Theo de Raadt dera...@cvs.openbsd.org wrote:
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.
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?
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.
/sarcasm
This is as unfair as it gets. Did i somehow miss the bit where Alexander
asks for OKs? I think this diff merely shows that he nailed it down to
specific piece of code. He gets a panic so how is his problem even 'fixed'?
Do not assume everyone around you is silly and ill-intended.
Re: ThinkPad T60 x86emu panic on resume (w/patch)
On 2 September 2012 21:13, Theo de Raadt dera...@cvs.openbsd.org wrote:
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.
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?
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.
/sarcasm
This is as unfair as it gets. Did i somehow miss the bit where Alexander
asks for OKs?
Here, you are confused. ok's are given to developers with accounts.
He not a developer with an account.
I think this diff merely shows that he nailed it down to
specific piece of code. He gets a panic so how is his problem even 'fixed'?
He nailed it down to the variable (that 1 vs 0) that controls the if
statement that enters the code that explodes.
It has a comment, which he deletes:
/* All ATI video until further notice */
Quote a curious comment. So curious, one might want to go looking at
the commit logs. Then the story becomes more clear -- we've had tons
of problems in this area and don't have a solution yet. Tweaking the
table further doesn't change shit.
Do not assume everyone around you is silly and ill-intended.
I don't assume he's ill-intended.
That diff says he's only thinking of solutions for himself.
My point is people shouldn't hand out bad advice. That diff is bad
advice. It is a diff created with very shallow consideration of what
has been found.
It's like those acpi tz diffs that help a few broken HP machines by
solving a real problem in the wrong way -- and that wrong way hurts
all the other machines. Yes, apply that diff, and go bravo, it fixes
my machine.
That is not a part of a good cooperative development process.
quiet ftp
Does anyone else find it weird that -V doesn't turn off the progress bar? Index: main.c === RCS file: /cvs/src/usr.bin/ftp/main.c,v retrieving revision 1.85 diff -u -p -r1.85 main.c --- main.c 26 Aug 2012 02:16:02 - 1.85 +++ main.c 3 Sep 2012 02:10:20 - @@ -292,6 +292,7 @@ main(volatile int argc, char *argv[]) case 'V': verbose = 0; + progress = 0; break; default:
Re: quiet ftp
This is intentional. Look in distrib/miniroot: install.sub:FTPOPTS=-V We want the progress bar -- we just don't want any of the other noise. I suppose with this change, and then using -Vm it could work. But that would need testing. Especially since ftp(1) is compiled with -DSMALL. grep SMALL /usr/src/*/ftp/*.[ch] | wc -l 265 Does anyone else find it weird that -V doesn't turn off the progress bar? Index: main.c === RCS file: /cvs/src/usr.bin/ftp/main.c,v retrieving revision 1.85 diff -u -p -r1.85 main.c --- main.c26 Aug 2012 02:16:02 - 1.85 +++ main.c3 Sep 2012 02:10:20 - @@ -292,6 +292,7 @@ main(volatile int argc, char *argv[]) case 'V': verbose = 0; + progress = 0; break; default:
