Re: pdksh wrong strips quotes in shell substs
On Sun, Aug 12, 2012 at 12:43 PM, Alexander Polakov 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
Re: Dell Latitude E6420 issues - not working...
On Tue, Aug 14, 2012 at 4:24 PM, Jiri B 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: 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: [Patch] Virtio drivers for OpenBSD V5
Hi, - Original Message - > From: "Mark Kettenis" > To: "Stefan Fritsch" > Cc: tech@openbsd.org > Sent: Monday, August 13, 2012 2:20:50 PM > Subject: Re: [Patch] Virtio drivers for OpenBSD V5 > > > From: Stefan Fritsch > > 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 > > +#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.
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: CoDel
ill have to fix that. On 15/08/2012, at 3:31 AM, Simon Perreault wrote: > 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: 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
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: wd0: 16-sector PIO, LBA48, 114473MB, 234441648 sectors wd1 at pciide0 channel 0 drive 1: 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
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: CoDel
On Tue, Aug 14, 2012 at 11:13, Simon Perreault wrote: > 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. 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. :)
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 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: 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.
Dell Latitude E6420 issues - not working...
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... 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
CoDel
Hi tech@,
I started implementing CoDel[1] in altq, as an alternative to RED. It's based on
the Linux implementation, which is dual-licensed GPL/BSD. I'm looking for early
feedback (design, big issues, etc.). Work-in-progress diff is below.
The big issues I see are:
- 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?
- CoDel drops packets at dequeue time, contrary to RED. This means that for ECN
we need to have the header available, but it is long gone. Altq makes the
header available to red_enqueue() then forgets about it. I'll figure out a way
to do this I'm sure (either copy or recompute), but suggestions are
appreciated.
Any other suggestions/comments/questions very much appreciated.
Thanks,
Simon
[1] http://www.bufferbloat.net/projects/codel/wiki
THIS DIFF DOESN'T WORK. I NEVER TESTED IT. IT'S A WORK IN PROGRESS.
diff --git a/sys/altq/altq_classq.h b/sys/altq/altq_classq.h
index a9ac674..43863b6 100644
--- a/sys/altq/altq_classq.h
+++ b/sys/altq/altq_classq.h
@@ -44,10 +44,11 @@ extern "C" {
#endif
/*
- * Packet Queue types: RED or DROPHEAD.
+ * Packet Queue types
*/
#defineQ_DROPHEAD 0x00
#defineQ_RED 0x01
+#defineQ_CODEL 0x02
#defineQ_DROPTAIL 0x03
#ifdef _KERNEL
@@ -58,6 +59,7 @@ extern "C" {
struct _class_queue_ {
struct mbuf *tail_; /* Tail of packet queue */
int qlen_; /* Queue length (in number of packets) */
+ int qsize_; /* Queue size (in bytes) */
int qlim_; /* Queue limit (in number of packets*) */
int qtype_; /* Queue type */
};
@@ -67,11 +69,13 @@ typedef struct _class_queue_class_queue_t;
#defineqtype(q)(q)->qtype_ /* Get queue type */
#defineqlimit(q) (q)->qlim_ /* Max packets to be
queued */
#defineqlen(q) (q)->qlen_ /* Current queue
length. */
+#defineqsize(q)(q)->qsize_ /* Current queue size.
*/
#defineqtail(q)(q)->tail_ /* Tail of the queue */
#defineqhead(q)((q)->tail_ ? (q)->tail_->m_nextpkt : NULL)
#defineqempty(q) ((q)->qlen_ == 0) /* Is the queue empty??
*/
#defineq_is_red(q) ((q)->qtype_ == Q_RED) /* Is the queue a red
queue */
+#defineq_is_codel(q) ((q)->qtype_ == Q_CODEL)/* Is the queue a CoDel
queue */
#if !defined(__GNUC__) || defined(ALTQ_DEBUG)
@@ -98,6 +102,7 @@ _addq(class_queue_t *q, struct mbuf *m)
m0->m_nextpkt = m;
qtail(q) = m;
qlen(q)++;
+ qsize(q) += m_pktlen(m);
}
static __inline struct mbuf *
@@ -112,6 +117,7 @@ _getq(class_queue_t *q)
else
qtail(q) = NULL;
qlen(q)--;
+ qsize(q) -= m_pktlen(m0);
m0->m_nextpkt = NULL;
return (m0);
}
diff --git a/sys/altq/altq_codel.c b/sys/altq/altq_codel.c
new file mode 100644
index 000..7a6c186
--- /dev/null
+++ b/sys/altq/altq_codel.c
@@ -0,0 +1,241 @@
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+
+/**
+ * struct codel_params - contains codel parameters
+ * @target:target queue size (in time units)
+ * @interval: width of moving time window
+ * @ecn: is Explicit Congestion Notification enabled
+ */
+struct codel_params {
+ u_int64_t target;
+ u_int64_t interval;
+ int ecn;
+};
+
+/**
+ * struct codel_vars - contains codel variables
+ * @count: how many drops we've done since the last time we
+ * entered dropping state
+ * @lastcount: count at entry to dropping state
+ * @dropping: set to true if in dropping state
+ * @rec_inv_sqrt: reciprocal value of sqrt(count) >> 1
+ * @first_above_time: when we went (or will go) continuously above target
+ * for interval
+ * @drop_next: time to drop next packet, or when we dropped last
+ * @ldelay:sojourn time of last dequeued packet
+ */
+struct codel_vars {
+ u_int32_t count;
+ u_int32_t lastcount;
+ int dropping;
+ u_int16_t rec_inv_sqrt;
+ u_int64_t first_above_time;
+ u_int64_t drop_next;
+ u_int64_t ldelay;
+};
+
+struct codel {
+ struct codel_params params;
+ struct codel_varsvars;
+ struct codel_stats stats;
+ u_int32_tdrop_overlimit;
+};
+
+static int codel_should_drop(struct codel *, class_queue_t *,
+ struct mbuf *, u_int64_t);
+static void codel_Newton_step(struct codel_vars *);
+static u_int64_tcodel_control_law(u_int64_t t, u_int64_t, u_int32_t);
+
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.
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
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.
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 > > > > ../../../../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 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.
Re: Fix clang warning in x86emu code
> Date: Tue, 14 Aug 2012 04:12:47 -0400 > From: Brad Smith > > ../../../../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 should mark longjmp(9) as __dead?
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.
