Remove unused count parameter for em_rxeof()
The em(4) driver does not actually utilize the loop count
paramter for em_rxeof() so just remove it.
Index: if_em.c
===
RCS file: /home/cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.264
diff -u -p -r1.264 if_em.c
--- if_em.c 17 May 2012 10:45:17 - 1.264
+++ if_em.c 12 Aug 2012 22:38:02 -
@@ -208,7 +208,7 @@ void em_realign(struct em_softc *, struc
#define em_realign(a, b, c) /* a, b, c */
#endif
int em_rxfill(struct em_softc *);
-void em_rxeof(struct em_softc *, int);
+void em_rxeof(struct em_softc *);
void em_receive_checksum(struct em_softc *, struct em_rx_desc *,
struct mbuf *);
#ifdef EM_CSUM_OFFLOAD
@@ -881,7 +881,7 @@ em_intr(void *arg)
return (0);
if (ifp-if_flags IFF_RUNNING) {
- em_rxeof(sc, -1);
+ em_rxeof(sc);
em_txeof(sc);
refill = 1;
}
@@ -2807,12 +2807,9 @@ em_rxfill(struct em_softc *sc)
* the mbufs in the descriptor and sends data which has been
* dma'ed into host memory to upper layer.
*
- * We loop at most count times if count is 0, or until done if
- * count 0.
- *
*/
void
-em_rxeof(struct em_softc *sc, int count)
+em_rxeof(struct em_softc *sc)
{
struct ifnet*ifp = sc-interface_data.ac_if;
struct mbuf *m;
@@ -2833,7 +2830,7 @@ em_rxeof(struct em_softc *sc, int count)
i = sc-next_rx_desc_to_check;
- while (count != 0 sc-rx_ndescs 0) {
+ while (sc-rx_ndescs 0) {
m = NULL;
desc = sc-rx_desc_base[i];
@@ -2872,7 +2869,6 @@ em_rxeof(struct em_softc *sc, int count)
desc_len = letoh16(desc-length);
if (status E1000_RXD_STAT_EOP) {
- count--;
eop = 1;
if (desc_len ETHER_CRC_LEN) {
len = 0;
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Fix clang warning in x86emu code
../../../../dev/x86emu/x86emu.c:291:1: error: function declared 'noreturn' should not return [-Werror,-Winvalid-noreturn] x86emu_halt_sys: add an (unreached) panic after longjmp To convince clang that we won't return. From oga@Bitrig Index: x86emu.c === RCS file: /home/cvs/src/sys/dev/x86emu/x86emu.c,v retrieving revision 1.5 diff -u -p -r1.5 x86emu.c --- x86emu.c17 Feb 2010 15:09:47 - 1.5 +++ x86emu.c14 Aug 2012 07:33:52 - @@ -288,6 +288,7 @@ x86emu_halt_sys(struct x86emu *emu) #else longjmp(emu-exec_state, 1); #endif + panic(%s: longjmp returned, __func__); } /* -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Fix clang warning in x86emu code
Date: Tue, 14 Aug 2012 04:12:47 -0400 From: Brad Smith b...@comstyle.com ../../../../dev/x86emu/x86emu.c:291:1: error: function declared 'noreturn' should not return [-Werror,-Winvalid-noreturn] x86emu_halt_sys: add an (unreached) panic after longjmp To convince clang that we won't return. Perhaps sys/systm.h should mark longjmp(9) as __dead?
Re: Fix clang warning in x86emu code
On Tue, Aug 14, 2012 at 10:33:00AM +0200, Mark Kettenis wrote: Date: Tue, 14 Aug 2012 04:12:47 -0400 From: Brad Smith b...@comstyle.com ../../../../dev/x86emu/x86emu.c:291:1: error: function declared 'noreturn' should not return [-Werror,-Winvalid-noreturn] x86emu_halt_sys: add an (unreached) panic after longjmp To convince clang that we won't return. Perhaps sys/systm.h should mark longjmp(9) as __dead? That also works. I see FreeBSD/NetBSD have done so for longjmp() for both the kernel and userland headers. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Fix clang warning in radeon_cs
../../../../dev/pci/drm/radeon_cs.c:746:34: error: passing 'int *' to parameter
of type 'uint32_t *' (aka 'unsigned int *') converts between pointers to
integer types with different sign
[-Werror,-Wpointer-sign]
ret = r600_cs_packet0(parser, count_dw);
^
../../../../dev/pci/drm/radeon_cs.c:322:82: note: passing argument to parameter
'offset_dw_p' here
static inline int r600_cs_packet0(struct drm_radeon_cs_parser *parser, uint32_t
*offset_dw_p)
^
../../../../dev/pci/drm/radeon_cs.c:756:34: error: passing 'int *' to parameter
of type 'uint32_t *' (aka 'unsigned int *') converts between pointers to
integer types with different sign
[-Werror,-Wpointer-sign]
ret = r600_cs_packet3(parser, count_dw);
^
../../../../dev/pci/drm/radeon_cs.c:353:82: note: passing argument to parameter
'offset_dw_p' here
static inline int r600_cs_packet3(struct drm_radeon_cs_parser *parser, uint32_t
*offset_dw_p)
Looking at how count_dw is used, as well as size_dw, within r600_cs_parse() I
think
it makes sense to change these to uint32_t.
Comments?
Index: radeon_cs.c
===
RCS file: /home/cvs/src/sys/dev/pci/drm/radeon_cs.c,v
retrieving revision 1.2
diff -u -p -r1.2 radeon_cs.c
--- radeon_cs.c 2 Jun 2011 18:22:00 - 1.2
+++ radeon_cs.c 14 Aug 2012 10:29:44 -
@@ -731,7 +731,7 @@ static int r600_cs_parse(struct drm_rade
{
struct drm_radeon_kernel_chunk *ib_chunk;
/* scan the packet for various things */
- int count_dw = 0, size_dw;
+ uint32_t count_dw = 0, size_dw;
int ret = 0;
ib_chunk = parser-chunks[parser-ib_index];
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Esto Es Para Vos -tech- No Te Lo Pierdas
tech, si no podes visualizar este correo, podes hacerlo clickeando en este enlace. 1800 Modelos De Contratos | Documentos Legales Pre-Diseñados 1800 Modelos De Contratos Pre Diseñados Listos Para Usar UNICA OPORTUNIDAD A PRECIO PROMOCIONAL Para visitar la web y ver mas detalles haga CLIC ACA Este email tiene como unico destinatario tech Para ser eliminado de nuestras listas envienos un email y en asunto aclarar REMOVER ofmgslbvqhdhkcyipbjf
Re: warn that security(8) is not an IDS
On Sun, Aug 12, 2012 at 11:56:09AM +0200, Ingo Schwarze wrote: Hi, a recent inquiry by a user reminded me that the security(8) manual is trying to explain the tool's limitations, but rather muddling the point. So here is an attempt to better explain what's wrong with it. OK? Ingo personally i think that if intrusion detection is beyond the scope of this script, then its man page should not be trying to describe it. it just means we have an unrelated text block that we need to try and remember to update. isn;t it enough to say security(8) doesn;t do x, y, or z, so look elsewhere if that's what you want? beyond that, the comment you remove was the author's prerogative, and should remain, i feel. jmc Index: security.8 === RCS file: /cvs/src/share/man/man8/security.8,v retrieving revision 1.21 diff -u -r1.21 security.8 --- security.88 Jul 2012 21:48:38 - 1.21 +++ security.812 Aug 2012 09:49:09 - @@ -14,7 +14,9 @@ .Nm is a command script that examines the system for some signs of security weaknesses. -It is only a security aid and does not offer complete protection. +It cannot be used for intrusion detection; see the +.Sx BUGS +section for details. .Nm is run by .Xr daily 8 , @@ -112,10 +114,6 @@ .Xr hostname.if 5 file permissions. .El -.Pp -The intent of the -.Nm -script is to point out some obvious holes to the system administrator. .Sh ENVIRONMENT The following variables can be set in .Pa /etc/daily.local : @@ -156,7 +154,26 @@ .Sh BUGS The name of this script may provide a false sense of .Nm security . -.\ Well, I thought it was amusing. .Pp There are perhaps an infinite number of ways the system can be compromised without this script noticing. +.Pp +Intrusion detection and file integrity checking require that both +the file checksums and the tools for comparing the checksums +are stored on a storage medium that is +.Em physically +separate from the machine to be checked +and only mounted by the administrator, with +.Em physical +write protection, while performing the routine comparisons. +Otherwise, an intruder obtaining root permissions is able +to manipulate the checksums and/or the comparison tools +to render the checking ineffective and maintain his illicit access. +.Pp +The +.Nm +script stores both the checksums and the checking tools +on the system itself, without sufficient write protection, +so it doesn't provide intrusion detection. +It is merely a security aid to draw the administrator's attention +to some obvious administration mistakes.
Re: CoDel
On Tue, Aug 14, 2012 at 09:42, Simon Perreault wrote: - CoDel needs to timestamp each packet when it gets queued. - I added a new member in struct pkthdr for this. Is this ok? - I end up calling microuptime() for each packet. Is this ok? You want to use getmicrouptime, it's faster. See the man page.
Re: CoDel
Le 2012-08-14 11:03, Ted Unangst a écrit : On Tue, Aug 14, 2012 at 09:42, Simon Perreault wrote: - CoDel needs to timestamp each packet when it gets queued. - I added a new member in struct pkthdr for this. Is this ok? - I end up calling microuptime() for each packet. Is this ok? You want to use getmicrouptime, it's faster. See the man page. Will it have good enough precision? I need to check if packets have been in the queue for less than 5ms. The man page talks about a precision of 10ms, which would not be good enough I'm afraid. Thanks, Simon
Re: [Patch] Virtio drivers for OpenBSD V5
On Monday 13 August 2012 17:00:56 Mike Belopuhov wrote: you're calling MCLGETI and provide an interface pointer but you forget to set watermarks via m_clsetwms. OK. The MCLGETI man page should probably get a pointer to m_clsetwms(). -- genua Gesellschaft fuer Netzwerk- und Unix-Administration mbH Domagkstrasse 7, 85551 Kirchheim bei Muenchen tel +49 89 991950-0, fax -999, www.genua.de Geschaeftsfuehrer: Dr. Magnus Harlander, Dr. Michaela Harlander, Bernhard Schneck. Amtsgericht Muenchen HRB 98238
Re: CoDel
Le 2012-08-14 12:12, Ted Unangst a écrit : Five years ago I removed a once per packet microuptime call which led to something like a 33% improvement in throughput. I don't want to have to do that again. :) Hey I just realized that hfsc calls microuptime() for every single packet at dequeue time. altq_hfsc_dequeue() -- read_machclk() -- microuptime() Looks like codel won't be slowing hfsc down at least. :) Simon
Re: ral rt2661 tx interrupt race fix
On Fri, Aug 03, 2012 at 01:31:18PM +0200, Stefan Sperling wrote: I haven't received any test reports so far, apart from my own testing and edd@'s testing. It's been working splendid for me so far but I would like to get more testing if possible. I've Bcc'd some people who were involved in testing earlier ral diffs or complained about ral not working for them. It would be great if some of you could try this diff on access points and clients. Cheers! Finally got around to dig out the card and put it in a Blade 1500. With -current, I get around 10Mb using tcpbench. With your diff, freelist corruption messages pop up rather quickly, speed is the same. I guess the panic at the end is just an effect of the modify after free. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2012 OpenBSD. All rights reserved. http://www.OpenBSD.org : Tue Aug 14 19:57:29 CEST 2012 tobi...@blade.tmux.org:/usr/src/sys/arch/sparc64/compile/GENERIC real mem = 2147483648 (2048MB) avail mem = 2100854784 (2003MB) mainbus0 at root: Sun Blade 1500 (Silver) cpu0 at mainbus0: SUNW,UltraSPARC-IIIi (rev 3.4) @ 1503 MHz cpu0: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K external (64 b/l) memory-controller at mainbus0 not configured schizo0 at mainbus0: Tomatillo, version 4, ign 780, bus A 0 to 1 schizo0: dvma map c000-dfff pci0 at schizo0 ebus0 at pci0 dev 7 function 0 Acer Labs M1533 ISA rev 0x00 flashprom at ebus0 addr 0-f not configured rtc0 at ebus0 addr 70-71: m5823 pcfiic0 at ebus0 addr 320-321 ivec 0x2e iic0 at pcfiic0 admtt0 at iic0 addr 0x2e spdmem0 at iic0 addr 0x50: 512MB DDR SDRAM registered ECC PC2300CL2.5 spdmem1 at iic0 addr 0x51: 512MB DDR SDRAM registered ECC PC2300CL2.5 spdmem2 at iic0 addr 0x52: 512MB DDR SDRAM registered ECC PC2300CL2.5 spdmem3 at iic0 addr 0x53: 512MB DDR SDRAM registered ECC PC2300CL2.5 ics951601 at iic0 addr 0x69 not configured power0 at ebus0 addr 800-82f ivec 0x20 com0 at ebus0 addr 3f8-3ff ivec 0x2c: ns16550a, 16 byte fifo com0: console com1 at ebus0 addr 2e8-2ef ivec 0x2c: ns16550a, 16 byte fifo dma at ebus0 addr 0- not configured alipm0 at pci0 dev 6 function 0 Acer Labs M7101 Power rev 0x00: 223KHz clock iic1 at alipm0 scm001 at alipm0 addr 0x20 skipped due to alipm0 bugs autri0 at pci0 dev 8 function 0 Acer Labs M5451 Audio rev 0x02: ivec 0x7a4 ac97: codec id 0x41445348 (Analog Devices AD1881A) ac97: codec features headphone, Analog Devices Phat Stereo audio0 at autri0 midi0 at autri0: 4DWAVE MIDI UART ohci0 at pci0 dev 10 function 0 Acer Labs M5237 USB rev 0x03: ivec 0x7a7, version 1.0, legacy support ohci1 at pci0 dev 11 function 0 Acer Labs M5237 USB rev 0x03: ivec 0x7a6, version 1.0, legacy support pciide0 at pci0 dev 13 function 0 Acer Labs M5229 UDMA IDE rev 0xc4: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using ivec 0x798 for native-PCI interrupt wd0 at pciide0 channel 0 drive 0: ST3120026A wd0: 16-sector PIO, LBA48, 114473MB, 234441648 sectors wd1 at pciide0 channel 0 drive 1: ST3250620A wd1: 16-sector PIO, LBA48, 238474MB, 488395055 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) ral0 at pci0 dev 2 function 0 Ralink RT2561 rev 0x00: ivec 0x790, address 00:80:5a:38:c4:0b ral0: MAC/BBP RT2661B, RF RT2527 ppb0 at pci0 dev 3 function 0 TI PCI2250 PCI-PCI rev 0x02 pci1 at ppb0 bus 1 ohci2 at pci1 dev 8 function 0 NEC USB rev 0x43: ivec 0x78c, version 1.0 ohci3 at pci1 dev 8 function 1 NEC USB rev 0x43: ivec 0x78d, version 1.0 ehci0 at pci1 dev 8 function 2 NEC USB rev 0x04: ivec 0x78e usb0 at ehci0: USB revision 2.0 uhub0 at usb0 NEC EHCI root hub rev 2.00/1.00 addr 1 TI TSB43AB23 FireWire rev 0x00 at pci1 dev 11 function 0 not configured usb1 at ohci2: USB revision 1.0 uhub1 at usb1 NEC OHCI root hub rev 1.00/1.00 addr 1 usb2 at ohci3: USB revision 1.0 uhub2 at usb2 NEC OHCI root hub rev 1.00/1.00 addr 1 usb3 at ohci0: USB revision 1.0 uhub3 at usb3 Acer Labs OHCI root hub rev 1.00/1.00 addr 1 usb4 at ohci1: USB revision 1.0 uhub4 at usb4 Acer Labs OHCI root hub rev 1.00/1.00 addr 1 ppm at mainbus0 not configured schizo1 at mainbus0: Tomatillo, version 4, ign 7c0, bus B 0 to 0 schizo1: dvma map c000-dfff pci2 at schizo1 bge0 at pci2 dev 2 function 0 Broadcom BCM5703 rev 0x00, BCM5702/5703 A2 (0x1002): ivec 0x7dc, address 00:14:4f:23:72:a2 brgphy0 at bge0 phy 1: BCM5703 10/100/1000baseT PHY, rev. 2 ifb0 at pci2 dev 3 function 0 3D Labs Wildcat 5110 rev 0x01 ifb0: XVR-1200 (SUNW,375-3101), 1152x900 wsdisplay0 at ifb0 mux 1 wsdisplay0: screen 0 added (std, sun emulation) 3D Labs Wildcat 5110 rev 0x01 at pci2 dev 3 function 1 not configured i2c at mainbus0 not configured vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets bootpath:
Re: add WARNINGS infrastructure to ftp
Lets make it a bit cleaner, while here also fix some whitespaces.
Index: bsd.own.mk
===
RCS file: /cvs/src/share/mk/bsd.own.mk,v
retrieving revision 1.116
diff -d -u -p -r1.116 bsd.own.mk
--- bsd.own.mk 12 Apr 2012 11:22:14 - 1.116
+++ bsd.own.mk 13 Aug 2012 20:14:07 -
@@ -79,10 +79,10 @@ LIBGRP?=${BINGRP}
LIBOWN?= ${BINOWN}
LIBMODE?= ${NONBINMODE}
-DOCDIR?=/usr/share/doc
+DOCDIR?= /usr/share/doc
DOCGRP?= bin
DOCOWN?= root
-DOCMODE?= ${NONBINMODE}
+DOCMODE?= ${NONBINMODE}
LKMDIR?= /usr/lkm
LKMGRP?= ${BINGRP}
@@ -98,6 +98,12 @@ LOCALEDIR?= /usr/share/locale
LOCALEGRP?=wheel
LOCALEOWN?=root
LOCALEMODE?= ${NONBINMODE}
+
+.if !defined(CDIAGFLAGS)
+CDIAGFLAGS=-Wall -Wpointer-arith -Wuninitialized -Wstrict-prototypes
+CDIAGFLAGS+= -Wmissing-prototypes -Wunused -Wsign-compare -Wbounded
+CDIAGFLAGS+= -Wshadow
+.endif
# Shared files for system gnu configure, not used yet
GNUSYSTEM_AUX_DIR?=${BSDSRCDIR}/share/gnu
ftp(1) usage/man page HTTP Basic authentication tweaks
This is a small follow-up diff to haesbaert@'s recent commit that enables HTTP Basic authentication in ftp(1): * In the AUTO-FETCHING FILES section of the ftp(1) man page, describe what [user:password@] does when used with HTTP and HTTPS URLs. * Fix usage formatting to match man page SYNOPSIS exactly. * Fix usage to hide [user:password@] for http/https when compiled with -DSMALL. Thoughts? OK? Index: ftp.1 === RCS file: /cvs/src/usr.bin/ftp/ftp.1,v retrieving revision 1.83 diff -u -p -r1.83 ftp.1 --- ftp.1 14 Aug 2012 20:47:08 - 1.83 +++ ftp.1 15 Aug 2012 02:07:33 - @@ -1285,12 +1285,32 @@ An HTTP URL, retrieved using the HTTP pr If .Ev http_proxy is defined, it is used as a URL to an HTTP proxy server. +If +.Ar user : Ns Ar password Ns @ +is given and +.Ev http_proxy +isn't defined, authenticate as +.Ar user +with a password of +.Ar password +to retrieve the URL using Basic authentication as defined in +RFC 2617. .It https://[user:password@]host[:port]/file An HTTPS URL, retrieved using the HTTPS protocol. If .Ev http_proxy is defined, this HTTPS proxy server will be used to fetch the file using the CONNECT method. +If +.Ar user : Ns Ar password Ns @ +is given and +.Ev http_proxy +isn't defined, authenticate as +.Ar user +with a password of +.Ar password +to retrieve the URL using Basic authentication as defined in +RFC 2617. .It file:file .Ar file is retrieved from a mounted file system. Index: main.c === RCS file: /cvs/src/usr.bin/ftp/main.c,v retrieving revision 1.84 diff -u -p -r1.84 main.c --- main.c 14 Aug 2012 20:47:08 - 1.84 +++ main.c 15 Aug 2012 01:51:07 - @@ -778,12 +778,15 @@ usage(void) [-s srcaddr]\n #endif /* !SMALL */ - http://[user:password@]host[:port]/file ...\n + http://; +#ifndef SMALL + [user:password@] +#endif + host[:port]/file ...\n #ifndef SMALL %s [-C] [-c cookie] [-o output] [-s srcaddr]\n - https://[user:password@]host[:port]/file\n; - ...\n + https://[user:password@]host[:port]/file ...\n #endif /* !SMALL */ %s #ifndef SMALL
Re: [Patch] Virtio drivers for OpenBSD V5
Hi, - Original Message - From: Mark Kettenis mark.kette...@xs4all.nl To: Stefan Fritsch stefan_frit...@genua.de Cc: tech@openbsd.org Sent: Monday, August 13, 2012 2:20:50 PM Subject: Re: [Patch] Virtio drivers for OpenBSD V5 From: Stefan Fritsch stefan_frit...@genua.de Date: Mon, 13 Aug 2012 16:24:15 +0200 Hi, here is the next iteration of my patch. Changes from V4 include: - virtio: support RING_EVENT_IDX - virtio: use lfence/sfence because __sync_synchronize() is broken on gcc 4.4 Broken how? +/* + * The mutexes are not necessary with OpenBSD's big kernel lock. + */ +#define mutex_enter(x) +#define mutex_destroy(x) +#define mutex_exit(x) +#define mutex_init(x,y,z) Then remove them completely. We don't need more simple_lock()-like pollution in the tree. +/* + * XXX: This is not optimal: + * XXX: We need remory barriers are also with UP kernels, What are you trying to say here? I think what he's getting it is that even in the UP kernel, memory ordering for some operations must be enforced. + * XXX: because the host system may be SMP. However, OpenBSD does not seem to + * XXX: provide suitable functions. + * XXX: On x86/amd64, membar_producer() could probably be a no-op because + * XXX: writes are always ordered. + * XXX: Also, gcc does not have __sync_synchronize() for all architectures. + * XXX: Also, for gcc 4.4, __sync_synchronize() is broken + */ + +#if defined(__i386__) || defined(__amd64__) +#include machine/cpufunc.h +#define membar_consumer() lfence() +#define membar_producer() sfence() +#else +#define membar_consumer() __sync_synchronize() +#define membar_producer() __sync_synchronize() +#endif Introducing these macros here would be a mistake. If we really need them, they should be added to appropriate MD header files and implemented for all supported architectures. That said, it is not obvious to me what problem is being solved by adding these memory barriers to the code. The use of barriers suggests there is some lock-less algorithm in the code, but I failed to spot it. The other side of the lockless queue is happening from the host, i.e. in Qemu. The virtqueue (aka VirtIO ring) is in shared memory between guest and host. A virtqueue descriptor (denoting, say, an ethernet frame for transmit) must be fully set up before the corresponding counter is incremented to inform the host of the newly available frame.
Re: ftp(1) usage/man page HTTP Basic authentication tweaks
On Tue, Aug 14, 2012 at 10:38:21PM -0400, Lawrence Teo wrote: This is a small follow-up diff to haesbaert@'s recent commit that enables HTTP Basic authentication in ftp(1): * In the AUTO-FETCHING FILES section of the ftp(1) man page, describe what [user:password@] does when used with HTTP and HTTPS URLs. * Fix usage formatting to match man page SYNOPSIS exactly. * Fix usage to hide [user:password@] for http/https when compiled with -DSMALL. Thoughts? OK? i'm ok with this, but i wonder if we couldn;t make things less verbose: - combine the http and https lines, at least in SYNOPSIS/usage(), into one http[s] line. - there is some scope at the beginning of the AUTO-FETCHING FILES section to describe user and password, and avoid having to repeat the text three times. i know it combines withstuff about proxys (proxies?). what do you think? jmc Index: ftp.1 === RCS file: /cvs/src/usr.bin/ftp/ftp.1,v retrieving revision 1.83 diff -u -p -r1.83 ftp.1 --- ftp.1 14 Aug 2012 20:47:08 - 1.83 +++ ftp.1 15 Aug 2012 02:07:33 - @@ -1285,12 +1285,32 @@ An HTTP URL, retrieved using the HTTP pr If .Ev http_proxy is defined, it is used as a URL to an HTTP proxy server. +If +.Ar user : Ns Ar password Ns @ +is given and +.Ev http_proxy +isn't defined, authenticate as +.Ar user +with a password of +.Ar password +to retrieve the URL using Basic authentication as defined in +RFC 2617. .It https://[user:password@]host[:port]/file An HTTPS URL, retrieved using the HTTPS protocol. If .Ev http_proxy is defined, this HTTPS proxy server will be used to fetch the file using the CONNECT method. +If +.Ar user : Ns Ar password Ns @ +is given and +.Ev http_proxy +isn't defined, authenticate as +.Ar user +with a password of +.Ar password +to retrieve the URL using Basic authentication as defined in +RFC 2617. .It file:file .Ar file is retrieved from a mounted file system. Index: main.c === RCS file: /cvs/src/usr.bin/ftp/main.c,v retrieving revision 1.84 diff -u -p -r1.84 main.c --- main.c14 Aug 2012 20:47:08 - 1.84 +++ main.c15 Aug 2012 01:51:07 - @@ -778,12 +778,15 @@ usage(void) [-s srcaddr]\n #endif /* !SMALL */ - http://[user:password@]host[:port]/file ...\n + http://; +#ifndef SMALL + [user:password@] +#endif + host[:port]/file ...\n #ifndef SMALL %s [-C] [-c cookie] [-o output] [-s srcaddr]\n - https://[user:password@]host[:port]/file\n; -...\n + https://[user:password@]host[:port]/file ...\n #endif /* !SMALL */ %s #ifndef SMALL
Re: Dell Latitude E6420 issues - not working...
On Tue, Aug 14, 2012 at 4:24 PM, Jiri B ji...@devio.us wrote: Hi all, I have in my hands Dell Latitude E6420 so I tried to boot OpenBSD snapshot and booting got stucked on these lines... (I retyped from a photos I made.) The last line was one with 'scsibus1 at umass0' below, then I touched a key and console was full of pbkbcintr lines... I had exactly same model and issues even in 5.0 or 5.1. Can't remember exactly now (maybe it's in misc@ as well), but some option in BIOS changed that behavior. Was quite hard to do eg. upgrades via bsd.rd How can I help to troubleshoot this? jirib ... uhidev1 at uhub5 port 1 configuration 1 in rev 2.00/54.00 addr 3 uhidev1: iclass 3/1 uhid at uhidev1 not configured uhidev2 at uhub5 port 2 configuration 1 in dio 400 DSP rev 2.00/1.32 addr 4 uhidev2: iclass 3/0, 9 report ids uhid at uhidev2 reportid 1 not configured uhid at uhidev2 reportid 2 not configured uhid at uhidev2 reportid 8 not configured uhid at uhidev2 reportid 9 not configured Plantronics Plantronics .Audio 180 DSP re nfiguration 1 not configured umass0 at uhub5 port 6 configuration 3 inter ddr 5 umass0: using SCSI over Bulk-Only scsibus1 at umass0: 2 targets, initiator 0 _ pckbcintr: no eki for slot 1 pckbcintr: no dev for slot 1 pckbcintr: no dev for slot 1 pckbcintr: no dev for slot 1 pckbcintr: no dev for slot 1 pckbcintr: no dev for slot 1 pckbcintr: no dev for slot 1 pckbcintr: no dev for slot 1 pckbcintr: no dev for slot 1 pckbcintr: no dev for slot 1 pckbcintr: no dev for slot 1 pckbcintr: no dev for slot 1 pckbcintr: no dev for slot 1
Re: pdksh wrong strips quotes in shell substs
On Sun, Aug 12, 2012 at 12:43 PM, Alexander Polakov p...@sdf.org wrote:
Ok, second attempt
Nice. One fix;
@@ -342,7 +346,10 @@
PUSH_STATE(STBRACE);
} else {
ungetsc(c);
- PUSH_STATE(SBRACE);
+ if (state == SDQUOTE)
+ PUSH_STATE(SBRACEQ);
+ else
+ PUSH_STATE(SBRACE);
That should be
if (state == SDQUOTE ||
state == SBRACEQ)
...
so that doubly nested forms like
foo=1; echo ${foo:+${foo:+'blah $foo'}}
give
'blah 1'
...and yes, I now have a still bigger diff to unclass2.t that includes
that test. :-)
I think the lex.h diff is nicer if the new SBRACEQ state is stuck at
the end of the existing list instead of renumbering additional states,
but I can be argued into renumbering them...
Philip Guenther
