Re: sigaction.2 consistency
On Sun, Sep 14, 2014 at 9:33 PM, Jean-Philippe Ouellet jean-phili...@ouellet.biz wrote: We use async-signal-safe (not async-signal safe) elsewhere, and so does POSIX. Yep. Committed to there and signal(3). Thanks!
Re: ATI SB400 PCI bridge fallback to substractive decode
On Mon, Sep 15, 2014 at 12:25:19AM +0200, Mark Kettenis wrote:
Date: Sun, 14 Sep 2014 23:57:09 +0200
From: Thierry Deval thierry+openbsd.t...@deval.be
Hi,
When I put a CF to PCCard adapter (not CardBus) in my laptop to work on a CF
boot image, I was surprised by this kernel message :
** wdc2 at pcmcia0 function 0 SanDisk, SDP, 5/3 0.6: can't handle card info
And the card was not working at all, as weren't any other PCCard I tried
afterwards.
After digging and enabling as much debugging as I could, I found that the
cardbus bridge (TI PCI7xx1 CardBus) couldn't allocate any IO or mem range
for the cards.
Digging deeper to understand how the allocation should work, I noticed
a comment in dev/pci/ppb.c talking about handling substractive (or is it
really 'subtractive' as in the comment ? ) decode scheme for more than the
Intel 82801 PCI bridge.
So, as a test, I included the ATI SB400 PCI bridge (behind which the TI
PCI7xx1 CardBus bridge was lying) to the substractive decode treatment.
I was rewarded by a working CF card.
** ppb2 at pci0 dev 20 function 4 ATI SB400 PCI rev 0x00
** pci3 at ppb2 bus 6
** cbb0 at pci3 dev 9 function 0 TI PCI7XX1 CardBus rev 0x00: apic 1 int 23
** cardslot0 at cbb0 slot 0 flags 0
** cardbus0 at cardslot0: bus 7 device 0 cacheline 0x8, lattimer 0x20
** pcmcia0 at cardslot0
** wdc2 at pcmcia0 function 0 SanDisk, SDP, 5/3 0.6 port 0xa000/16
** wd1 at wdc2 channel 0 drive 0: SanDisk SDCFB-64
** wd1: 1-sector PIO, LBA, 61MB, 125440 sectors
** wd1(wdc2:0:0): using BIOS timings
** wd1 detached
** wdc2 detached
I don't know if anybody else have seen the same problem but I would be glad
to have a confirmation of the fix.
Here's the diff:
Index: ppb.c
===
RCS file: /cvs/src/sys/dev/pci/ppb.c,v
retrieving revision 1.58
diff -u -p -u -p -r1.58 ppb.c
--- ppb.c 12 Jul 2014 18:48:52 - 1.58
+++ ppb.c 14 Sep 2014 17:00:40 -
@@ -286,9 +286,11 @@ ppbattach(struct device *parent, struct
* XXX We probably should handle subtractive decode bridges
* in general.
*/
- if (PCI_VENDOR(pa-pa_id) == PCI_VENDOR_INTEL
+ if ((PCI_VENDOR(pa-pa_id) == PCI_VENDOR_INTEL
(PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_INTEL_82801BA_HPB ||
- PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_INTEL_82801BAM_HPB)) {
+PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_INTEL_82801BAM_HPB)) ||
+ (PCI_VENDOR(pa-pa_id) == PCI_VENDOR_ATI
+PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_ATI_SB400_PCI)){
if (sc-sc_ioex == NULL)
sc-sc_ioex = pa-pa_ioex;
if (sc-sc_memex == NULL)
I hope this could go in, at least as a first step.
I plan on looking further about what this substractive decode means, and
if there could be a generic way of enabling it where supported...
Can you send pcidump -vxxx output for that machine?
Sure Mark, here it is.
(I compressed it to save mail real estate : 280k - 14k)
pcidump.gz
Description: application/gunzip
Re: ATI SB400 PCI bridge fallback to substractive decode
Date: Mon, 15 Sep 2014 09:37:56 +0200
From: Thierry Deval thierry+openbsd.t...@deval.be
On Mon, Sep 15, 2014 at 12:25:19AM +0200, Mark Kettenis wrote:
Date: Sun, 14 Sep 2014 23:57:09 +0200
From: Thierry Deval thierry+openbsd.t...@deval.be
Hi,
When I put a CF to PCCard adapter (not CardBus) in my laptop to work on a
CF
boot image, I was surprised by this kernel message :
** wdc2 at pcmcia0 function 0 SanDisk, SDP, 5/3 0.6: can't handle card
info
And the card was not working at all, as weren't any other PCCard I tried
afterwards.
After digging and enabling as much debugging as I could, I found that the
cardbus bridge (TI PCI7xx1 CardBus) couldn't allocate any IO or mem range
for the cards.
Digging deeper to understand how the allocation should work, I noticed
a comment in dev/pci/ppb.c talking about handling substractive (or is it
really 'subtractive' as in the comment ? ) decode scheme for more than the
Intel 82801 PCI bridge.
So, as a test, I included the ATI SB400 PCI bridge (behind which the TI
PCI7xx1 CardBus bridge was lying) to the substractive decode treatment.
I was rewarded by a working CF card.
** ppb2 at pci0 dev 20 function 4 ATI SB400 PCI rev 0x00
** pci3 at ppb2 bus 6
** cbb0 at pci3 dev 9 function 0 TI PCI7XX1 CardBus rev 0x00: apic 1 int
23
** cardslot0 at cbb0 slot 0 flags 0
** cardbus0 at cardslot0: bus 7 device 0 cacheline 0x8, lattimer 0x20
** pcmcia0 at cardslot0
** wdc2 at pcmcia0 function 0 SanDisk, SDP, 5/3 0.6 port 0xa000/16
** wd1 at wdc2 channel 0 drive 0: SanDisk SDCFB-64
** wd1: 1-sector PIO, LBA, 61MB, 125440 sectors
** wd1(wdc2:0:0): using BIOS timings
** wd1 detached
** wdc2 detached
I don't know if anybody else have seen the same problem but I would be glad
to have a confirmation of the fix.
Here's the diff:
Index: ppb.c
===
RCS file: /cvs/src/sys/dev/pci/ppb.c,v
retrieving revision 1.58
diff -u -p -u -p -r1.58 ppb.c
--- ppb.c 12 Jul 2014 18:48:52 - 1.58
+++ ppb.c 14 Sep 2014 17:00:40 -
@@ -286,9 +286,11 @@ ppbattach(struct device *parent, struct
* XXX We probably should handle subtractive decode bridges
* in general.
*/
- if (PCI_VENDOR(pa-pa_id) == PCI_VENDOR_INTEL
+ if ((PCI_VENDOR(pa-pa_id) == PCI_VENDOR_INTEL
(PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_INTEL_82801BA_HPB ||
- PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_INTEL_82801BAM_HPB)) {
+ PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_INTEL_82801BAM_HPB)) ||
+ (PCI_VENDOR(pa-pa_id) == PCI_VENDOR_ATI
+ PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_ATI_SB400_PCI)){
if (sc-sc_ioex == NULL)
sc-sc_ioex = pa-pa_ioex;
if (sc-sc_memex == NULL)
I hope this could go in, at least as a first step.
I plan on looking further about what this substractive decode means, and
if there could be a generic way of enabling it where supported...
Can you send pcidump -vxxx output for that machine?
Sure Mark, here it is.
Thanks. So your PCI bridge properly advertises itself as subtractive
decode. Can you try the diff below?
Thanks,
Mark
Index: ppbreg.h
===
RCS file: /cvs/src/sys/dev/pci/ppbreg.h,v
retrieving revision 1.4
diff -u -p -r1.4 ppbreg.h
--- ppbreg.h19 Nov 2009 20:43:32 - 1.4
+++ ppbreg.h15 Sep 2014 09:14:53 -
@@ -40,6 +40,11 @@
*/
/*
+ * PCI Programming Interface register.
+ */
+#definePPB_INTERFACE_SUBTRACTIVE 0x01
+
+/*
* Register offsets
*/
#definePPB_REG_BASE0 0x10/* Base Addr Reg. 0 */
Index: ppb.c
===
RCS file: /cvs/src/sys/dev/pci/ppb.c,v
retrieving revision 1.58
diff -u -p -r1.58 ppb.c
--- ppb.c 12 Jul 2014 18:48:52 - 1.58
+++ ppb.c 15 Sep 2014 09:14:53 -
@@ -146,6 +146,7 @@ ppbattach(struct device *parent, struct
struct pci_attach_args *pa = aux;
pci_chipset_tag_t pc = pa-pa_pc;
struct pcibus_attach_args pba;
+ pci_interface_t interface;
pci_intr_handle_t ih;
pcireg_t busdata, reg, blr;
char *name;
@@ -206,9 +207,18 @@ ppbattach(struct device *parent, struct
printf(\n);
- if (PCI_VENDOR(pa-pa_id) != PCI_VENDOR_INTEL ||
- (PCI_PRODUCT(pa-pa_id) != PCI_PRODUCT_INTEL_82801BA_HPB
- PCI_PRODUCT(pa-pa_id) != PCI_PRODUCT_INTEL_82801BAM_HPB))
+ interface = PCI_INTERFACE(pa-pa_class);
+
+ /*
+* The Intel 82801BAM Hub-to-PCI can decode subtractively but
+* doesn't advertise itself as such.
+*/
+ if (PCI_VENDOR(pa-pa_id) == PCI_VENDOR_INTEL
+ (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_INTEL_82801BA_HPB ||
+
Re: ATI SB400 PCI bridge fallback to substractive decode
On Mon, Sep 15, 2014 at 11:15:48AM +0200, Mark Kettenis wrote: Date: Mon, 15 Sep 2014 09:37:56 +0200 From: Thierry Deval thierry+openbsd.t...@deval.be On Mon, Sep 15, 2014 at 12:25:19AM +0200, Mark Kettenis wrote: Date: Sun, 14 Sep 2014 23:57:09 +0200 From: Thierry Deval thierry+openbsd.t...@deval.be Hi, When I put a CF to PCCard adapter (not CardBus) in my laptop to work on a CF boot image, I was surprised by this kernel message : ** wdc2 at pcmcia0 function 0 SanDisk, SDP, 5/3 0.6: can't handle card info . Can you send pcidump -vxxx output for that machine? Sure Mark, here it is. Thanks. So your PCI bridge properly advertises itself as subtractive decode. Can you try the diff below? Thanks, Mark diff snipped Thanks Mark, the patch works like a charm. As expected: ** ppb2 at pci0 dev 20 function 4 ATI SB400 PCI rev 0x00 ** pci3 at ppb2 bus 6 ** cbb0 at pci3 dev 9 function 0 TI PCI7XX1 CardBus rev 0x00: apic 1 int 23 ** cardslot0 at cbb0 slot 0 flags 0 ** cardbus0 at cardslot0: bus 7 device 0 cacheline 0x8, lattimer 0x20 ** pcmcia0 at cardslot0 ** wdc2 at pcmcia0 function 0 SanDisk, SDP, 5/3 0.6 port 0xa000/16 ** wd1 at wdc2 channel 0 drive 0: SanDisk SDCFB-64 ** wd1: 1-sector PIO, LBA, 61MB, 125440 sectors ** wd1(wdc2:0:0): using BIOS timings ** wd1 detached ** wdc2 detached I'm all for it ! Thanks, Thierry
Re: patch: acpitz: active cooling and notify 0x81
ping ?
Tihs patch is very conservative: it just allow to switch fan OFF if
state is unknown.
Thanks.
--
Sébastien Marie
On Wed, Aug 27, 2014 at 02:51:20PM +0200, Sébastien Marie wrote:
Hi Jonathan,
First, thanks for your feedback and for your patch.
On Wed, Aug 27, 2014 at 02:42:43AM +1000, Jonathan Gray wrote:
Rather than calling acpi_setfan() again would it make
sense to remove the cached state value and move
the state reading to just before the method is called?
That said I'm not familiar with the acpitz code and
haven't gone off to look at the spec.
At first reading I am quite disappointed to remove caching.
So I have:
- checked in others acpi termal-zone implementation to see if caching
is using or not for active cooling.
- try to measure some values on my host.
Others implementations checked:
- netbsd : caching used (sys/dev/acpi/acpi_tz.c, l.368)
- freebsd : caching used (head/sys/dev/acpica/acpi_thermal.c, l.564)
- linux : caching seems not be used (but not 100% sure)
(please note I am not expert in theses kernels implementations, so I
could be wrong).
Some measures:
I first try to measure the cost of acpi_setfan in term of time:
something between 9998432ns et 14574920ns (0.0099 and 0.015 s). It
seems not being a heavy operation (too my eyes).
Secondly, the number of call of acpi_setfan, with and without caching.
The test kernel is build with caching enable. The without-caching
counter is incremented every time acpi_setfan would be call without
caching, and with-caching counter incremented only when acpi_setfan is
called (the patch below was applied: an unknown state would result
acpi_setfan calling).
During 1h09 :
- without caching: 3388 calls
- with caching: 742 calls
The cache is used at 78% of time.
So, even if your patch resolve the initial problem (the fan don't keep
running whereas state is unknown), I would prefer to keep the cache in
place. But if you think the impact of not use this cache is negligible,
it is ok for me.
I join a very conservative patch which just allow calling
acpi_setfan(sc,i,_OFF) if cache is unknown.
Thanks.
--
Sébastien Marie
Index: dev/acpi/acpitz.c
===
RCS file: /cvs/src/sys/dev/acpi/acpitz.c,v
retrieving revision 1.47
diff -u -p -r1.47 acpitz.c
--- dev/acpi/acpitz.c 12 Jul 2014 02:44:49 - 1.47
+++ dev/acpi/acpitz.c 27 Aug 2014 12:38:36 -
@@ -424,7 +424,7 @@ acpitz_refresh(void *arg)
acpitz_setfan(sc, i, _ON_);
} else if (sc-sc_ac[i] != -1) {
/* turn off fan i */
- if (sc-sc_ac_stat[i] 0)
+ if (sc-sc_ac_stat[i] == -1 || sc-sc_ac_stat[i] 0)
acpitz_setfan(sc, i, _OFF);
}
}
Re: LibreSSL: Extending EC_KEY or adding GOST_KEY?
Currently there are three instances of ASN methods
and pmethods structures, because there three
different OIDs related to GOST public keys
(-2001, -2012, 256 bit, -2012 512 bit).
I think I can merge all of them. However I need
to store an additional NID (digest NID, which
is a part of public key parameters) together
with a _KEY instance. I see two possibilities.
First is to add a digest_nid field to EC_KEY
structure. Second is to add a
typedef struct {
EC_KEY *ec;
int digest_nid;
} GOST_KEY;
First way is a bit hackish. Second is clean but clumsy.
What would you prefer?
The second way will lead us to subtle bugs with code allocating an
EC_KEY and other code expecting the pointer to be a GOST_KEY.
I see nothing wrong with an extra field within struct ec_key_st, and a
libcrypto major bump due to the ABI change.
Miod
[diff] Comments in sys/dev/rnd.c: RC4 - ChaCha20
Not really an important issue, but here's a diff to bring the comments
in rnd.c more up to date. In particular:
- The PRNG uses ChaCha20 instead of RC4
- The first few bytes are not thrown away anymore
- The comments list ways to access the generated randomness; add
getentropy() to that list
Index: sys/dev/rnd.c
===
RCS file: /cvs/src/sys/dev/rnd.c,v
retrieving revision 1.159
diff -u -p -r1.159 rnd.c
--- sys/dev/rnd.c 17 Jul 2014 13:38:22 - 1.159
+++ sys/dev/rnd.c 14 Sep 2014 22:50:55 -
@@ -76,17 +76,18 @@
* If this estimate goes to zero, the MD5 hash will continue to generate
* output since there is no true risk because the MD5 output is not
* exported outside this subsystem. It is next used as input to seed a
- * RC4 stream cipher. Attempts are made to follow best practice
- * regarding this stream cipher - the first chunk of output is discarded
- * and the cipher is re-seeded from time to time. This design provides
- * very high amounts of output data from a potentially small entropy
- * base, at high enough speeds to encourage use of random numbers in
- * nearly any situation.
+ * ChaCha20 stream cipher, which is re-seeded from time to time. This
+ * design provides very high amounts of output data from a potentially
+ * small entropy base, at high enough speeds to encourage use of random
+ * numbers in nearly any situation. Before OpenBSD 5.5, the RC4 stream
+ * cipher (also known as ARC4) was used instead of ChaCha20.
*
- * The output of this single RC4 engine is then shared amongst many
+ * The output of this single ChaCha20 engine is then shared amongst many
* consumers in the kernel and userland via a few interfaces:
* arc4random_buf(), arc4random(), arc4random_uniform(), randomread()
- * for the set of /dev/random nodes, and the sysctl kern.arandom.
+ * for the set of /dev/random nodes, the sysctl kern.arandom, and the
+ * system call getentropy(), which provides seeds for process-context
+ * pseudorandom generators.
*
* Acknowledgements:
* =
@@ -666,7 +667,7 @@ _rs_random_u32(u_int32_t *val)
return;
}
-/* Return one word of randomness from an RC4 generator */
+/* Return one word of randomness from a ChaCha20 generator */
u_int32_t
arc4random(void)
{
@@ -680,7 +681,7 @@ arc4random(void)
}
/*
- * Fill a buffer of arbitrary length with RC4-derived randomness.
+ * Fill a buffer of arbitrary length with ChaCha20-derived randomness.
*/
void
arc4random_buf(void *buf, size_t n)
Re: [diff] Comments in sys/dev/rnd.c: RC4 - ChaCha20
On Mon, Sep 15, 2014 at 20:17, Max Fillinger wrote: Not really an important issue, but here's a diff to bring the comments in rnd.c more up to date. In particular: - The PRNG uses ChaCha20 instead of RC4 - The first few bytes are not thrown away anymore - The comments list ways to access the generated randomness; add getentropy() to that list Yes. Thank you.
Re: Speeding up openbsd on amd64 MP
On Sun, Sep 14, 2014 at 02:54:54PM +0200, Stefan Fritsch wrote: Hi, Apart from testing, I would of course also appreciate reviews. Compared to art's patch from 2005 which tried to use the direct mapping for everything, the current patch is much less intrusive. Therefore I hope that it is easier to review/debug than his patch, which unfortunately never got integrated. Some forktest tests: -current: 0m52.83s real 0m2.07s user 0m58.54s system 0m51.94s real 0m1.65s user 0m58.02s system 0m52.36s real 0m1.86s user 0m57.89s system 0m51.34s real 0m1.80s user 0m56.72s system 0m53.59s real 0m2.21s user 0m59.99s system w/ speedup patchs: 0m45.32s real 0m1.02s user 0m52.17s system 0m45.23s real 0m1.22s user 0m51.87s system 0m47.40s real 0m1.56s user 0m54.54s system 0m45.95s real 0m1.51s user 0m53.04s system 0m47.95s real 0m1.32s user 0m55.55s system dmesg: OpenBSD 5.6-current (GENERIC.MP) #366: Mon Sep 8 17:13:38 MDT 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1687691264 (1609MB) avail mem = 1634091008 (1558MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xea9a0 (45 entries) bios0: vendor American Megatrends Inc. version X401U.313 date 05/14/2013 bios0: ASUSTeK COMPUTER INC. X401U acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG ECDT HPET SSDT SSDT MSDM acpi0: wakeup devices SBAZ(S4) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4) OHC4(S4) XHC0(S4) XHC1(S4) PE20(S4) PE21(S4) GLAN(S4) PE22(S4) PE23(S4) SLPB(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD C-70 APU with Radeon(tm) HD Graphics, 998.33 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD C-70 APU with Radeon(tm) HD Graphics, 998.19 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 3 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiec0 at acpi0 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (PE20) acpiprt2 at acpi0: bus 6 (PE21) acpiprt3 at acpi0: bus -1 (PE22) acpiprt4 at acpi0: bus 7 (PE23) acpiprt5 at acpi0: bus -1 (BR15) acpiprt6 at acpi0: bus -1 (PCE7) acpiprt7 at acpi0: bus -1 (PCE8) acpiprt8 at acpi0: bus 1 (BR14) acpicpu0 at acpi0: C2, PSS acpicpu1 at acpi0: C2, PSS acpitz0 at acpi0: critical temperature is 95 degC acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 model X401-44 serial type LIon oem ASUSTek acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: LID_ acpibtn2 at acpi0: SLPB acpivideo0 at acpi0: VGA_ cpu0: 998 MHz: speeds: 1000 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 AMD AMD64 14h Host rev 0x00 radeondrm0 at pci0 dev 1 function 0 ATI Radeon HD 7290 rev 0x00 drm0 at radeondrm0 radeondrm0: msi azalia0 at pci0 dev 1 function 1 ATI Radeon HD 6310 HD Audio rev 0x00: msi azalia0: no supported codecs ppb0 at pci0 dev 4 function 0 AMD AMD64 14h PCIE rev 0x00: msi pci1 at ppb0 bus 1 AMD Hudson-2 xHCI rev 0x03 at pci0 dev 16 function 0 not configured ahci0 at pci0 dev 17 function 0 AMD Hudson-2 SATA rev 0x40: apic 3 int 19, AHCI 1.3 scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: ATA, Hitachi HTS54505, GG2O SCSI3 0/direct fixed naa.5000cca700c3196d sd0: 476940MB, 512 bytes/sector, 976773168 sectors ohci0 at pci0 dev 18 function 0 AMD Hudson-2 USB rev 0x11: apic 3 int 18, version 1.0, legacy support ehci0 at pci0 dev 18 function 2 AMD Hudson-2 USB2 rev 0x11: apic 3 int 17 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 ohci1 at pci0 dev 19 function 0 AMD Hudson-2 USB rev 0x11: apic 3 int 18, version 1.0, legacy support ehci1 at pci0 dev 19
[PATCH] Add -d flag to du(1)
Hey,
This diff adds a flag to du(1) to limit the depth of results that are displayed
to the user.
The semantics are equivalent to FreeBSD's, where it is mutually exclusive with
-a and -s, and du -d 0 is equivalent to du -s.
Thoughts?
William Orr
Index: usr.bin/du/du.1
===
RCS file: /cvs/src/usr.bin/du/du.1,v
retrieving revision 1.31
diff -u -b -w -p -r1.31 du.1
--- usr.bin/du/du.1 14 Feb 2014 18:17:50 - 1.31
+++ usr.bin/du/du.1 16 Sep 2014 05:39:39 -
@@ -38,7 +38,7 @@
.Nd display disk usage statistics
.Sh SYNOPSIS
.Nm du
-.Op Fl a | s
+.Op Fl a | s | d Ar depth
.Op Fl chkrx
.Op Fl H | L | P
.Op Ar
@@ -61,6 +61,10 @@ The options are as follows:
Display an entry for each file in the file hierarchy.
.It Fl c
Display the grand total after all the arguments have been processed.
+.It Fl d Ar depth
+Display an entry for each file and directory up to
+.Ar depth
+levels
.It Fl H
Symbolic links on the command line are followed.
Symbolic links encountered in the tree traversal are not followed.
Index: usr.bin/du/du.c
===
RCS file: /cvs/src/usr.bin/du/du.c,v
retrieving revision 1.25
diff -u -b -w -p -r1.25 du.c
--- usr.bin/du/du.c 20 May 2014 01:25:23 - 1.25
+++ usr.bin/du/du.c 16 Sep 2014 05:39:39 -
@@ -40,6 +40,7 @@
#include err.h
#include errno.h
#include fts.h
+#include limits.h
#include stdio.h
#include stdlib.h
#include string.h
@@ -60,15 +61,17 @@ main(int argc, char *argv[])
long blocksize;
quad_t totalblocks;
int ftsoptions, listdirs, listfiles;
- int Hflag, Lflag, aflag, cflag, hflag, kflag, sflag;
+ int Hflag, Lflag, aflag, cflag, hflag, kflag, sflag, dflag;
int ch, notused, rval;
+ int maxdepth = -1;
char **save;
+ const char *errstr = NULL;
save = argv;
- Hflag = Lflag = aflag = cflag = hflag = kflag = sflag = 0;
+ Hflag = Lflag = aflag = cflag = hflag = kflag = sflag = dflag = 0;
totalblocks = 0;
ftsoptions = FTS_PHYSICAL;
- while ((ch = getopt(argc, argv, HLPachksxr)) != -1)
+ while ((ch = getopt(argc, argv, HLPachksxrd:)) != -1)
switch (ch) {
case 'H':
Hflag = 1;
@@ -103,6 +106,14 @@ main(int argc, char *argv[])
case 'x':
ftsoptions |= FTS_XDEV;
break;
+ case 'd':
+ maxdepth = (int)strtonum(optarg, 0, INT_MAX, errstr);
+ if (errstr) {
+ warnx(max depth %s invalid: %s, optarg,
errstr);
+ usage();
+ }
+ dflag = 1;
+ break;
case '?':
default:
usage();
@@ -129,11 +140,12 @@ main(int argc, char *argv[])
ftsoptions |= FTS_LOGICAL;
}
- if (aflag) {
- if (sflag)
+ if (aflag + sflag + dflag 1)
usage();
+
+ if (aflag)
listdirs = listfiles = 1;
- } else if (sflag)
+ else if (sflag || dflag)
listdirs = listfiles = 0;
else {
listfiles = 0;
@@ -172,7 +184,8 @@ main(int argc, char *argv[])
* root of a traversal, display the total.
*/
if (listdirs ||
- (!listfiles p-fts_level == FTS_ROOTLEVEL)) {
+ (!listfiles p-fts_level == FTS_ROOTLEVEL) ||
+ p-fts_level = maxdepth) {
prtout((quad_t)howmany(p-fts_number,
(unsigned long)blocksize), p-fts_path,
hflag);
@@ -193,7 +206,7 @@ main(int argc, char *argv[])
* If listing each file, or a non-directory file was
* the root of a traversal, display the total.
*/
- if (listfiles || p-fts_level == FTS_ROOTLEVEL)
+ if (listfiles || p-fts_level == FTS_ROOTLEVEL ||
p-fts_level = maxdepth)
prtout(howmany(p-fts_statp-st_blocks,
blocksize), p-fts_path, hflag);
p-fts_parent-fts_number += p-fts_statp-st_blocks;
