BUG: Loosing carrier with the axen driver and kernel panic
Hi,
I don't have OpenBSD on the box any longer, but I did manage to get a
dmesg and some relevant information (I hope).
Three Startech USB 3.0 to Gigabit Ethernet NIC networking adapters,
with the ASIX AX88179 chipset, was attached to the same box. A HP t5740
Thin Client with an Intel Atom N280 CPU.
I believe this is the correct adapter:
http://www.startech.com/Networking-IO/Adapter-Cards/USB-3-to-Gigabit-Ethernet-NIC-Network-Adapter~USB31000S
OpenBSD current #522 was initially installed on the box.
Each device was setup using the following:
# cat /etc/hostname.axen*
inet 192.168.1.1 255.255.255.0 NONE media 1000baseTX mediaopt
full-duplex
inet 192.168.2.1 255.255.255.0 NONE media 1000baseTX
mediaopt full-duplex
inet 192.168.3.1 255.255.255.0 NONE media 1000baseTX mediaopt
full-duplex
The axen0 device got a carrier and was working well, but axen1 and
axen2 kept loosing carrier, right after initialization.
Different switches was attached to the different USB adapters, and they
got rotated as well in order to determine if that had any role to play,
but that didn't solve the problem.
Only axen0, not matter which USB dongle was used for that, would stay
up, the other two would get up, then about 5 seconds afterwards loose
their carrier and the lights in the dongle would turn off.
I tried connecting the adapters to different ports on the HP box, but
that didn't resolve the problem.
At one point setting the IP address manually with ifconfig made the
kernel panic and the box froze. I was *unable* to reproduce the kernel
panic, but was also limited on time so I only tried once and didn't
manage to retain any specific data from the panic.
Below is a copy of the dmesg. Please notice "axen1: usb errors on rx:
IOERROR".
FreeBSD eventually got installed on the box and the axge driver was
used without any similar problems - if this can also be helpful.
Kind regards.
Kim
OpenBSD 5.6-current (GENERIC.MP) #552: Fri Nov 21 15:38:54 MST 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class)
1.67 GHz cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF
real mem = 2076340224 (1980MB) avail mem = 2030084096 (1936MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 08/04/10, BIOS32 rev. 0 @
0xf0010, SMBIOS rev. 2.6 @ 0xfd100 (43 entries) bios0: vendor American
Megatrends Inc. version "786R8 v1.03" date 08/03/2010 bios0:
Hewlett-Packard HP t5740e Thin Client acpi0 at bios0: rev 0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC MCFG OEMB GSCI SSDT
acpi0: wakeup devices P0P2(S0) P0P1(S0) USB0(S0) USB1(S0) USB2(S0)
USB5(S0) EUSB(S0) USB3(S0) USB4(S0) USB6(S0) USBE(S0) GBE_(S0) P0P4(S0)
P0P5(S0) P0P6(S0) P0P7(S0) [...] acpitimer0 at acpi0: 3579545 Hz, 24
bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0:
apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges,
88 fixed ranges cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class)
1.67 GHz cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0
(PCI0) acpiprt1 at acpi0: bus -1 (P0P2)
acpiprt2 at acpi0: bus 1 (P0P1)
acpiprt3 at acpi0: bus 2 (P0P4)
acpiprt4 at acpi0: bus -1 (P0P5)
acpiprt5 at acpi0: bus -1 (P0P6)
acpiprt6 at acpi0: bus -1 (P0P7)
acpiprt7 at acpi0: bus 3 (P0P8)
acpiprt8 at acpi0: bus 4 (P0P9)
acpicpu0 at acpi0: C2, C1, PSS
acpicpu1 at acpi0: C2, C1, PSS
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
bios0: ROM list: 0xc/0xfc00!
cpu0: Enhanced SpeedStep 1663 MHz: speeds: 1667, 1333, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x09
vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x09
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1024x768
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel GM45 Video" rev 0x09 at pci0 dev 2 function 1 not configured
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 2 int
16 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 2
int 21 uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03:
apic 2 int 19 ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev
0x03: apic 2 int 18 usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "I
Re: Suspend/Resume broken, doesn't re-attach video.
> On Dec 4, 2014, at 9:00 PM, Jonathan Gray wrote:
>
> On Thu, Dec 04, 2014 at 08:47:34PM -0600, Sean Cody wrote:
>>>
>>> Fix:
>>
>
> We should probably repost all known powervr devices given there
> is otherwise no kernel support.
>
> For now try this:
>
> Index: sys/dev/pci/vga_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/vga_pci.c,v
> retrieving revision 1.81
> diff -u -p -r1.81 vga_pci.c
> --- sys/dev/pci/vga_pci.c 28 Jul 2014 15:00:27 - 1.81
> +++ sys/dev/pci/vga_pci.c 5 Dec 2014 02:55:20 -
> @@ -167,6 +167,11 @@ static const struct vga_device_descripti
> 0x, 0x },
> { 0x, 0x, 0x, 0x }, 1
> },
> + { /* All machines with Intel D2000/N2000 (until more evidence) */
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_D2000_IGD,
> + 0x, 0x },
> + { 0x, 0x, 0x, 0x }, 1
> + },
> };
> #endif
That did the trick.
zzz and resume works, as well in X.
Lid close suspends but opening doesn't resume (not a big deal) requires some
key mashing to wake up.
--
Sean
Re: Suspend/Resume broken, doesn't re-attach video.
On Thu, Dec 04, 2014 at 08:47:34PM -0600, Sean Cody wrote:
> >Synopsis:Suspend/Resume broken, doesn't re-attached video.
> >Category:amd64
> >Environment:
> System : OpenBSD 5.6
> Details : OpenBSD 5.6-current (GENERIC.MP) #648: Thu Dec 4
> 14:23:47 MST 2014
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
>
> Suspend/Resume doesn't quite work out on this laptop (Acer Aspire One
> D27-1375). Hibernate _does_ work (ZZZ and power button to resume). When
> using lid or 'zzz' to suspend you can see all the devices detach and it shuts
> down but when you attempt to start it back up (lid open OR keyboard mash) the
> screen doesn't activate. It is partially resuming as I can make the system
> beep with bad keys and was able to use the reboot command and ZZZ (which
> worked but the resume didn't attach the display). Using the function keys to
> swap interfaces or kill the backlight doesn't seem to do much (though screen
> does dim so it does something).
>
> Tried i386 and amd64 kernels with a November current snapshot and a
> snapshot from today with the same behavior.
>
> Consistently repeatable, just need to 'zzz' and it will sleep, wake up
> and the screen doesn't engage/attach/activate.
>
> >How-To-Repeat:
>
> zzz or close lid on device. Attempt to wake up with keyboard or
> lid-open.
> >Fix:
>
We should probably repost all known powervr devices given there
is otherwise no kernel support.
For now try this:
Index: sys/dev/pci/vga_pci.c
===
RCS file: /cvs/src/sys/dev/pci/vga_pci.c,v
retrieving revision 1.81
diff -u -p -r1.81 vga_pci.c
--- sys/dev/pci/vga_pci.c 28 Jul 2014 15:00:27 - 1.81
+++ sys/dev/pci/vga_pci.c 5 Dec 2014 02:55:20 -
@@ -167,6 +167,11 @@ static const struct vga_device_descripti
0x, 0x },
{ 0x, 0x, 0x, 0x }, 1
},
+ { /* All machines with Intel D2000/N2000 (until more evidence) */
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_D2000_IGD,
+ 0x, 0x },
+ { 0x, 0x, 0x, 0x }, 1
+ },
};
#endif
Suspend/Resume broken, doesn't re-attach video.
>Synopsis: Suspend/Resume broken, doesn't re-attached video. >Category: amd64 >Environment: System : OpenBSD 5.6 Details : OpenBSD 5.6-current (GENERIC.MP) #648: Thu Dec 4 14:23:47 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: Suspend/Resume doesn't quite work out on this laptop (Acer Aspire One D27-1375). Hibernate _does_ work (ZZZ and power button to resume). When using lid or 'zzz' to suspend you can see all the devices detach and it shuts down but when you attempt to start it back up (lid open OR keyboard mash) the screen doesn't activate. It is partially resuming as I can make the system beep with bad keys and was able to use the reboot command and ZZZ (which worked but the resume didn't attach the display). Using the function keys to swap interfaces or kill the backlight doesn't seem to do much (though screen does dim so it does something). Tried i386 and amd64 kernels with a November current snapshot and a snapshot from today with the same behavior. Consistently repeatable, just need to 'zzz' and it will sleep, wake up and the screen doesn't engage/attach/activate. >How-To-Repeat: zzz or close lid on device. Attempt to wake up with keyboard or lid-open. >Fix: dmesg: OpenBSD 5.6-current (GENERIC.MP) #648: Thu Dec 4 14:23:47 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1045098496 (996MB) avail mem = 1013481472 (966MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe3e00 (47 entries) bios0: vendor Insyde Corp. version "V1.10" date 07/23/2013 bios0: Acer AOD270 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC MCFG WDRT SLIC BOOT MSDM FPDT SSDT SSDT SSDT WDAT acpi0: wakeup devices USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU N2600 @ 1.60GHz, 1596.28 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC cpu0: 512KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Atom(TM) CPU N2600 @ 1.60GHz, 1596.01 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC cpu1: 512KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Atom(TM) CPU N2600 @ 1.60GHz, 1596.01 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC cpu2: 512KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Atom(TM) CPU N2600 @ 1.60GHz, 1596.01 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC cpu3: 512KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 4 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 3 (RP03) acpiprt4 at acpi0: bus -1 (RP04) acpiec0 at acpi0 acpicpu0 at acpi0: C2, C1, PSS acpicpu1 at acpi0: C2, C1, PSS acpicpu2 at acpi0: C2, C1, PSS acpicpu3 at acpi0: C2, C1, PSS acpitz0 at acpi0: critical temperature is 98 degC acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB acpibtn2 at acpi0: LID_ acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT1 model "AL10B31" serial 3967 type LION oem "SANYO" acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD02 cpu0: Enhanced SpeedStep 1596 MHz: speeds: 1600, 1400, 1200, 1000, 800, 600 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Atom D2000/N2000 Host" rev 0x03 vga1 at pci0 dev 2 function 0 "Intel Atom D2000/N2000 Video" rev 0x09 intagp at vga1 not configured wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) azalia0 at pci0 dev 27 functi
pf reset connection for ssh user when authpf user resets ssh connection
I am trying to set up pf along with authpf on my bastion host.
Requirements for bastion hosts are as below:
1. Admin users – have access to all resources on internal network when
they ssh using port 22
2. Other users — have access to limited resources in internal network
through ssh port after they have authpf themselves to port 22
To achieve above, I have pf rules set as below:
ext_if = "em1"
int_if = "em2"
dns_servers = “{some_ip_here}"
set skip on lo
block return log all
# Allow everyone to ssh in
pass in log quick on $ext_if inet proto tcp from any to $ext_if port ssh
modulate state
# Track all authpf users in a table
table persist
# Allow ICMP for debugging
pass in quick inet proto icmp from any to any
# Let me have basic connections
pass in quick log (all) inet proto udp from any to $dns_servers port 53
keep state
pass in quick inet proto tcp from $int_if to $int_if:network port {ssh http
https 3306} modulate state
pass quick on $int_if inet proto udp
# Load authpf anchor
anchor "authpf/*”
Authpf has 2 files
1. /etc/authpf/authpf.conf is empty
2. /etc/authpf/users/$user/authpf.rules is as below
ext_if="em1"
int_if="em2"
table file "/etc/pf/table/limited_resources"
pass log (all) inet proto tcp from to $ext_if port
modulate state
pass log (all) inet proto tcp from $int_if to port 22
modulate state
With above configuration in place, here’s symptoms for the problem.
1. admin user is logged in to bastion host on port 22 and has a working
shell(ksh,bash), has a source ip of 1.2.3.4
2. Other user logs in to port 22 and gets authpf shell has a source ip
of 1.2.3.4
3. Other user disconnects its port 22 connection using ctrl+c, he is
released from authpf and his entries get cleared in pf table.
4. Admin user who is logged in from another terminal from source ip
1.2.3.4 also receives a disconnect with message "Write failed: Broken pipe”
on his ssh working shell.
If I remove ‘block return log all’’ from pf.conf then admin user is not
getting the disconnect as noted in step 4. But that is not desirable as we
need default block.
Has anyone tried to implement anything like above?
Is there some caveats between pf and authpf which I do not know and is
causing this behavior?
Re: your mail
On Thu, 4 Dec 2014, misch...@thx1138.mindlock.us wrote: > the mount(2) manual is missing the definition of struct fusefs_args and > tmpfs_args. mount.h isn't hard to reach for but it should be consistent. Hmm, mount(2) doesn't actually seem to say anything about the structures that isn't in , so maybe deleting the existing descriptions and pointing there makes more sense. Philip
Re: error in man page find(1)
On Thu, Dec 04, 2014 at 03:19:41PM +0001, Jason McIntyre wrote: > On Thu, Dec 04, 2014 at 03:55:08AM -0500, Ted Unangst wrote: > > On Thu, Dec 04, 2014 at 07:40, Jason McIntyre wrote: > > > On Thu, Dec 04, 2014 at 12:03:01AM +0100, Ingo Schwarze wrote: > > >> Hi Ted, > > >> > > >> Ted Unangst wrote on Wed, Dec 03, 2014 at 05:41:41PM -0500: > > >> > > >> > Here's a revised diff against current. It just notes that the > > >> > extension spellings are such. > > >> > > >> I'm OK with that, discouraging gratuitiously non-standard syntax > > >> makes a lot of sense. > > >> > > > > > > when find(1) was imported into openbsd (or when openbsd itself was > > > imported), it came with the syntax "-and" and "-or". that was in > > > 1995, some 19 years ago. beyond that, well you'd be much better > > > qualified to tell me the history of it. > > > > > > so how have you gone from that to "gratuitiously non-standard syntax"? > > > if it has existed for 19 years (and before that), in this context it is > > > completely standard syntax. > > > > I'll note that the -a and -o syntax was also supported since the > > initial import. It merely wasn't documented. All we're doing here is > > fixing a bug. > > > > the bug is fixed. we're now really discussing whether the man page for > find(1) should sideline -and and -or in favour of -a and -o. > just for the record, free/net/dragon do not document -a and -o, so maybe we can pass diffs upstream after deciding what we're doing. freebsd does mention that -o and -a were implemented as posix compliances, but only in STANDARDS. i've no idea really if there is a reference linux page, but the first one i found online documents both notations, more or less in the way i have (though they've listed them as separate items, not as one). jmc
Re: error in man page find(1)
On Thu, Dec 04, 2014 at 03:55:08AM -0500, Ted Unangst wrote: > On Thu, Dec 04, 2014 at 07:40, Jason McIntyre wrote: > > On Thu, Dec 04, 2014 at 12:03:01AM +0100, Ingo Schwarze wrote: > >> Hi Ted, > >> > >> Ted Unangst wrote on Wed, Dec 03, 2014 at 05:41:41PM -0500: > >> > >> > Here's a revised diff against current. It just notes that the > >> > extension spellings are such. > >> > >> I'm OK with that, discouraging gratuitiously non-standard syntax > >> makes a lot of sense. > >> > > > > when find(1) was imported into openbsd (or when openbsd itself was > > imported), it came with the syntax "-and" and "-or". that was in > > 1995, some 19 years ago. beyond that, well you'd be much better > > qualified to tell me the history of it. > > > > so how have you gone from that to "gratuitiously non-standard syntax"? > > if it has existed for 19 years (and before that), in this context it is > > completely standard syntax. > > I'll note that the -a and -o syntax was also supported since the > initial import. It merely wasn't documented. All we're doing here is > fixing a bug. > the bug is fixed. we're now really discussing whether the man page for find(1) should sideline -and and -or in favour of -a and -o. > In this case there is a real standard (as opposed to just > historic practice) describing the utility. > > http://pubs.opengroup.org/onlinepubs/009695399/utilities/find.html > really. > > i'll ask again: are we deprecating this syntax to such an extent that we > > are actively asking people not to use it and, if so, why? > > I think so. I like the following rules. > > 1. Prefer the better alternative. > > 2. When alternatives are equal, prefer the officially standardized > alternative. > right. so our examples use the portable format. > The BSD syntax under discussion here is certainly traditional, but > it's also gratuitous. It's not better. It doesn't let me do > something new and different, like the -print0 extension, that's actually > useful. > > >From the perspective of an implementor, I find it very annoying trying > to deal with all the de facto standards and variations that arise > when people do not write their code and scripts to conform to the > standard. This is like all those shell scripts that start with > #!/bin/bash even though they run under plain sh just fine. I would not > wish to further inflict that on others. > none of that really has any bearing on the man page. it just means you, tedu, would like people to write portable code. for people wishing to use find(1) portably, they should read the notes in STANDARDS and/or the relevant standards, and decide whether to use non-portable extensions or not. for people who don;t care, they can use whatever components of find they want. so i think we should document it normally (i.e. no change required) or we mark it as deprecated. but not say "oh by the way, we support this too". and i honestly don;t see the gain in doing that. jmc
[no subject]
the mount(2) manual is missing the definition of struct fusefs_args and tmpfs_args. mount.h isn't hard to reach for but it should be consistent.
Re: error in man page find(1)
On Thu, Dec 04, 2014 at 07:40, Jason McIntyre wrote: > On Thu, Dec 04, 2014 at 12:03:01AM +0100, Ingo Schwarze wrote: >> Hi Ted, >> >> Ted Unangst wrote on Wed, Dec 03, 2014 at 05:41:41PM -0500: >> >> > Here's a revised diff against current. It just notes that the >> > extension spellings are such. >> >> I'm OK with that, discouraging gratuitiously non-standard syntax >> makes a lot of sense. >> > > when find(1) was imported into openbsd (or when openbsd itself was > imported), it came with the syntax "-and" and "-or". that was in > 1995, some 19 years ago. beyond that, well you'd be much better > qualified to tell me the history of it. > > so how have you gone from that to "gratuitiously non-standard syntax"? > if it has existed for 19 years (and before that), in this context it is > completely standard syntax. I'll note that the -a and -o syntax was also supported since the initial import. It merely wasn't documented. All we're doing here is fixing a bug. In this case there is a real standard (as opposed to just historic practice) describing the utility. http://pubs.opengroup.org/onlinepubs/009695399/utilities/find.html > i'll ask again: are we deprecating this syntax to such an extent that we > are actively asking people not to use it and, if so, why? I think so. I like the following rules. 1. Prefer the better alternative. 2. When alternatives are equal, prefer the officially standardized alternative. The BSD syntax under discussion here is certainly traditional, but it's also gratuitous. It's not better. It doesn't let me do something new and different, like the -print0 extension, that's actually useful. >From the perspective of an implementor, I find it very annoying trying to deal with all the de facto standards and variations that arise when people do not write their code and scripts to conform to the standard. This is like all those shell scripts that start with #!/bin/bash even though they run under plain sh just fine. I would not wish to further inflict that on others.
Re: error in man page find(1)
On Wed, Dec 3, 2014 at 5:41 PM, Ted Unangst wrote: > On Wed, Dec 03, 2014 at 15:12, Theo de Raadt wrote: > >>> >>>If you think my diff is too wordy, we could move the text around a >>>bit, perhaps later in the section and say "-and and -or are >>>alternatives to -a and -o" or such. >> >> For scripting stuff, we have tended to lean towards the "portable approach", >> since such code gets used on other systems very often. > > Here's a revised diff against current. It just notes that the > extension spellings are such. > > Index: find.1 > === > RCS file: /cvs/src/usr.bin/find/find.1,v > retrieving revision 1.89 > diff -u -p -r1.89 find.1 > --- find.1 3 Dec 2014 19:39:57 - 1.89 > +++ find.1 3 Dec 2014 22:40:18 - > @@ -509,7 +509,6 @@ operator. > It evaluates to true if the expression is false. > .Pp > .It Ar expression Cm -a Ar expression > -.It Ar expression Cm -and Ar expression > .It Ar expression expression > The logical AND operator. > As it is implied by the juxtaposition of two expressions it does not > @@ -518,7 +517,6 @@ The expression evaluates to true if both > The second expression is not evaluated if the first expression is false. > .Pp > .It Ar expression Cm -o Ar expression > -.It Ar expression Cm -or Ar expression > The logical OR operator. > The expression evaluates to true if either the first or the second expression > is true. > @@ -529,6 +527,11 @@ Operators, primaries, and arguments to p > arguments to > .Nm find , > i.e. they should be separated by whitespace. > +.Pp > +As an extension, the AND and OR operators may also be spelled > +.Cm -and > +and > +.Cm -or . > .Sh EXIT STATUS > The > .Nm > I personally like jmc's existing version better. I feel like we typically document the whole command as implemented on .Ox, and note any extensions in the STANDARDS section as he's done. Deleting -and and -or from the OPERATORS sections feels a bit inconsistent/incomplete to me compared to other pages.
