Re: LLVM license change

[lists]

Hi Benjamin,

The point of interest is which compiler offers technological advantage
without limitations and dependency.  It is not the trendy product that
retains users base, it's the more accessible, reliable and permissive.
Theo said it: the moral values have been double (corporate) mortgaged.

Kind regards,
Anton

FDE on BeagleBone Black

[L.R. D.S.]

Hi,
I'm thinking of buying a new toy board like BeagleBone Black to test the armv7 
port.
It's already possible to do full disk encryption on these boards?
Also, as a side question, I remember some discussion here on misc or tech, 
about no 
support for binary packages on armv7 port. Is it still right, I'll have to 
compile 
all by myself? I'm already feeling the pain to compile ffmpeg by myself...
Thanks in advance.

Re: LLVM license change

[Theo de Raadt]

> And that is because corporate "contributor-wannabes" put pressure on the
> LLVM foundation.
> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html
> 
> It does say "this is an RFC" but that was last year. We are now in this
> year:
> http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html
> 
> What I particularly do not like is the "IANAL but let's do it anyway"
> drift emanating from a lot of high profile developers there.

Well, I hope they do it.

And then -- I hope a year or two later, some author of a component
(especially one from Europe where the moral rights of an author still
carries substantial weight) submarines the new licence, surfacing to
indicate that they never signed off on the additional terms applied to
them as a significant author, and will accept no cash to solve the
problem.

Then they are dead in the water.

A cataclysm like CSRG went through.

Then a fork of code on the original license can flourish.  A fork
based upon the last free version -- but let's remember that is the
history of another piece of important software...

So this problem could be fixed, if enough people care.

In this situation, I suspect a few people are being paid a lot of
wages to act as agents permitting theft from their co-contributors.
They worked with others but now they are ready to steal from them.  A
list of all contributers (and every single one of them must agree) has
not been published, so it is really likely this is a well-financed
effort being performed by paralegals.  Meanwhile day by day that list
of contributors operating under the existing model is growing..

Someone is hoping they can get away with copyright theft.

Want to have fun?  Submit a major diff, which (seperately) in the
submission says you'll never agree.  Eventually most large projects
find their inner Xfree86, I'm afraid to say.

Re: LLVM license change

[bytevolcano]

On Tue, 27 Sep 2016 20:29:56 -0500
Amit Kulkarni  wrote:

> On Tue, Sep 27, 2016 at 8:06 PM, Chris Cappuccio 
> wrote:
> 
> > Ingo Schwarze [schwa...@usta.de] wrote:  
> > > Hi Benjamin,
> > >
> > > kbenjamin Coplon wrote on Mon, Sep 26, 2016 at 01:23:43PM -0400:
> > >  
> > > > What does the OpenBSD community think about the LLVM proposal
> > > > to move to the Apache license?
> > > >
> > > > http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html  
> > >
> > > If LLVM would move to the Apache 2 license, we would become unable
> > > to use versions released after that change, and would be stuck
> > > with version released before the change, just like we are stuck
> > > with pre-GPLv3 gcc now.  So it would be very bad for us.
> > >
> > > See http://www.openbsd.org/policy.html :
> > >
> > >   Apache
> > > The original Apache license was similar to the Berkeley
> > > license, but source code published under version 2 of the Apache
> > > license is subject to additional restrictions and cannot be
> > > included into OpenBSD.
> > >
> > > In a nutshell, OpenBSD does not consider software released under
> > > Apache 2 to be free software.  At least not free enough for us.
> > >  
> >
> > One major problem with the Apache 2.0 license is the fact that it
> > is not merely a software license, but extends out into contract law.
> > This has been a concern with many licenses, not just Apache.
> >
> > If you use Apache 2.0 license code, you lose rights that you
> > otherwise retain under the MIT or BSD license.
> >
> > Just review sections 3 and 4. The patent clause in section 3 is an
> > issue.
> >
> > https://www.apache.org/licenses/LICENSE-2.0.txt
> >
> > Chris
> >
> >  
> Ironically, LLVM wants protection against patents.
> 

And that is because corporate "contributor-wannabes" put pressure on the
LLVM foundation.
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html

It does say "this is an RFC" but that was last year. We are now in this
year:
http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html

What I particularly do not like is the "IANAL but let's do it anyway"
drift emanating from a lot of high profile developers there.

Re: LLVM license change

[Amit Kulkarni]

On Tue, Sep 27, 2016 at 8:06 PM, Chris Cappuccio  wrote:

> Ingo Schwarze [schwa...@usta.de] wrote:
> > Hi Benjamin,
> >
> > kbenjamin Coplon wrote on Mon, Sep 26, 2016 at 01:23:43PM -0400:
> >
> > > What does the OpenBSD community think about the LLVM proposal to move
> > > to the Apache license?
> > >
> > > http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html
> >
> > If LLVM would move to the Apache 2 license, we would become unable
> > to use versions released after that change, and would be stuck with
> > version released before the change, just like we are stuck with
> > pre-GPLv3 gcc now.  So it would be very bad for us.
> >
> > See http://www.openbsd.org/policy.html :
> >
> >   Apache
> > The original Apache license was similar to the Berkeley license,
> > but source code published under version 2 of the Apache license
> > is subject to additional restrictions and cannot be included
> > into OpenBSD.
> >
> > In a nutshell, OpenBSD does not consider software released under
> > Apache 2 to be free software.  At least not free enough for us.
> >
>
> One major problem with the Apache 2.0 license is the fact that it
> is not merely a software license, but extends out into contract law.
> This has been a concern with many licenses, not just Apache.
>
> If you use Apache 2.0 license code, you lose rights that you otherwise
> retain under the MIT or BSD license.
>
> Just review sections 3 and 4. The patent clause in section 3 is an issue.
>
> https://www.apache.org/licenses/LICENSE-2.0.txt
>
> Chris
>
>
Ironically, LLVM wants protection against patents.

Re: LLVM license change

[Chris Cappuccio]

Ingo Schwarze [schwa...@usta.de] wrote:
> Hi Benjamin,
> 
> kbenjamin Coplon wrote on Mon, Sep 26, 2016 at 01:23:43PM -0400:
> 
> > What does the OpenBSD community think about the LLVM proposal to move
> > to the Apache license?
> > 
> > http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html
> 
> If LLVM would move to the Apache 2 license, we would become unable
> to use versions released after that change, and would be stuck with
> version released before the change, just like we are stuck with
> pre-GPLv3 gcc now.  So it would be very bad for us.
> 
> See http://www.openbsd.org/policy.html :
> 
>   Apache
> The original Apache license was similar to the Berkeley license,
> but source code published under version 2 of the Apache license
> is subject to additional restrictions and cannot be included
> into OpenBSD.
> 
> In a nutshell, OpenBSD does not consider software released under
> Apache 2 to be free software.  At least not free enough for us.
> 

One major problem with the Apache 2.0 license is the fact that it
is not merely a software license, but extends out into contract law.
This has been a concern with many licenses, not just Apache.

If you use Apache 2.0 license code, you lose rights that you otherwise
retain under the MIT or BSD license.

Just review sections 3 and 4. The patent clause in section 3 is an issue.

https://www.apache.org/licenses/LICENSE-2.0.txt

Chris

Re: No free discspace after deleting files

[Alexander Hall]

On September 27, 2016 10:06:24 PM GMT+02:00, Marco Prause
 wrote:
>Re,
>
>well as mentioned fstat didn't show any open filehandles or inodes, but
>fsck was a bit more chatty :
>
># fsck /dev/sd0a
>
>
>** /dev/rsd0a (NO WRITE)
>** Last Mounted on /flash
>** Phase 1 - Check Blocks and Sizes
>** Phase 2 - Check Pathnames
>** Phase 3 - Check Connectivity
>** Phase 4 - Check Reference Counts
>UNREF FILE I=9  OWNER=root MODE=100644
>SIZE=1317309440 MTIME=Sep 27 13:48 2016
>CLEAR? no
>
>** Phase 5 - Check Cyl groups
>15 files, 892592 used, 993071 free (31 frags, 124130 blocks, 0.0%
>fragmentation)

I'm not a filsystem expert, but I'd say this looks as expected for an active
mounted filsystem with an unlinked file still in use by some process.

What was your fstat command?
This wasn't the underlying file for the vnd?

/Alexander

>#
>
>a simple umount and mount of the partition did fix it and released the
>discspace.
>
>Because it happened the second time, I'm going to try to reproduce the
>issue.
>
>
>But until then cheers,
>Marco
>
>Am 27.09.2016 um 08:29 schrieb Raul Miller:
>> Do any processes have those files open? Did you have any hard links
>to
>> those files from other names?
>>
>> The disk space cannot be removed until all references to those files
>> are removed.

Re: dmesg for Lenovo Thinkpad x200 w/Libreboot

[Andrew Gwozdziewycz]

Yes. Yes it is, and he's trying to get OpenBSD running on top of
Libreboot, which makes it very much relevant. PAY ATTENTION!

On Tue, Sep 27, 2016 at 11:03 AM, Mihai Popescu  wrote:
> Dude, this is OpenBSD's mailing list not libreboot's. Pay attention, please!
>



-- 
http://apgwoz.com

Re: No free discspace after deleting files

[Marco Prause]

Re,

well as mentioned fstat didn't show any open filehandles or inodes, but
fsck was a bit more chatty :

# fsck /dev/sd0a


** /dev/rsd0a (NO WRITE)
** Last Mounted on /flash
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=9  OWNER=root MODE=100644
SIZE=1317309440 MTIME=Sep 27 13:48 2016
CLEAR? no

** Phase 5 - Check Cyl groups
15 files, 892592 used, 993071 free (31 frags, 124130 blocks, 0.0%
fragmentation)
#

a simple umount and mount of the partition did fix it and released the
discspace.

Because it happened the second time, I'm going to try to reproduce the
issue.


But until then cheers,
Marco

Am 27.09.2016 um 08:29 schrieb Raul Miller:
> Do any processes have those files open? Did you have any hard links to
> those files from other names?
> 
> The disk space cannot be removed until all references to those files
> are removed.

Re: LLVM license change

[Ingo Schwarze]

Hi Benjamin,

kbenjamin Coplon wrote on Mon, Sep 26, 2016 at 01:23:43PM -0400:

> What does the OpenBSD community think about the LLVM proposal to move
> to the Apache license?
> 
> http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html

If LLVM would move to the Apache 2 license, we would become unable
to use versions released after that change, and would be stuck with
version released before the change, just like we are stuck with
pre-GPLv3 gcc now.  So it would be very bad for us.

See http://www.openbsd.org/policy.html :

  Apache
The original Apache license was similar to the Berkeley license,
but source code published under version 2 of the Apache license
is subject to additional restrictions and cannot be included
into OpenBSD.

In a nutshell, OpenBSD does not consider software released under
Apache 2 to be free software.  At least not free enough for us.

Yours,
  Ingo

Re: dmesg for Lenovo Thinkpad x200 w/Libreboot

[Mihai Popescu]

Dude, this is OpenBSD's mailing list not libreboot's. Pay attention, please!

Re: missing punctuation in hifn.4 and hardclock.9

[Ingo Schwarze]

Hi Rob,

Rob Pierce wrote on Tue, Sep 27, 2016 at 12:31:41AM -0400:

> Stumbled across these in my travels.

Committed, thanks.
  Ingo


> Index: man4/hifn.4
> ===
> RCS file: /cvs/src/share/man/man4/hifn.4,v
> retrieving revision 1.50
> diff -u -p -r1.50 hifn.4
> --- man4/hifn.4   10 Dec 2015 21:00:51 -  1.50
> +++ man4/hifn.4   27 Sep 2016 04:27:25 -
> @@ -36,7 +36,7 @@
>  The
>  .Nm
>  driver supports various cards containing the Hifn 7751, Hifn 7811, Hifn 7951,
> -Hifn 7955, Hifn 7956, or Hifn 9751 chipsets, such as
> +Hifn 7955, Hifn 7956, or Hifn 9751 chipsets, such as:
>  .Bl -tag -width namenamenamena -offset indent
>  .It Invertex AEON
>  Comes as 128KB SRAM model, or 2MB DRAM model.
> 
> Index: man9/hardclock.9
> ===
> RCS file: /cvs/src/share/man/man9/hardclock.9,v
> retrieving revision 1.11
> diff -u -p -r1.11 hardclock.9
> --- man9/hardclock.9  3 Apr 2016 06:43:59 -   1.11
> +++ man9/hardclock.9  27 Sep 2016 04:27:39 -
> @@ -47,7 +47,7 @@ is an opaque, machine dependent structur
>  previous machine state.
>  .Pp
>  .Fn hardclock
> -performs a variety of time related housekeeping tasks, such as
> +performs a variety of time related housekeeping tasks, such as:
>  .Bl -bullet -offset indent
>  .It
>  If the current process has virtual or profiling interval

Re: recommended crypto transforms?

[Stuart Henderson]

On 2016-09-27, Marko Cupać  wrote:
> Hi,
>
> what would be the 'industry standard' for ipsec crypto transforms today?
> Should I consider my tunnel safe with hmac-sha1 / aes-128 / group 2? Or
> should I bump it all the way to hmac-sha-512 / aes-256 / group 18?
> Something in between?

I don't know about "industry standard" but for machines with AES-NI I've
been using defaults for phase 1 and "quick enc aes-128-gcm group modpo3072"
for phase 2 recently.

recommended crypto transforms?

[Marko Cupać]

Hi,

what would be the 'industry standard' for ipsec crypto transforms today?
Should I consider my tunnel safe with hmac-sha1 / aes-128 / group 2? Or
should I bump it all the way to hmac-sha-512 / aes-256 / group 18?
Something in between?

Thank you in advance.
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: Displaying System Uptime via CGI script: not displayed when script is run under chroot.

[Kihaguru Gathura]

And finally,

Conclusion.

(A: Section 6 below: Why is the system uptime string not displayed when the
cgi script is run under chroot?)

/bin/sh is needed at chroot for command interpretation.


(B: Section 4 below: Why does running uptime program under chroot yield
time
that is not accurate? 6:54PM while the actual time was 9:54PM produced by
running uptime as root immediately after.)

/etc/localtime is needed at chroot for correct local time. (by Alexander)

//
# chroot -u www /var/www /cgi-bin/myuptimer.cgi
Content-Type: text/plain;charset=us-ascii

 1:31PM   up   3:24, 1 user, load averages: 0.06, 0.08, 0.08
//

However, the cron script workaround (by Raul) should be adopted for
security reasons as suggested unanimously.

Thanks to all.

Kihaguru


On Mon, Sep 26, 2016 at 7:19 PM, Stuart Henderson 
wrote:

> On 2016-09-25, Kihaguru Gathura  wrote:
> > Thank you for ongoing suggestions, The web server in use is OpenBSD httpd
> > and on a private network environment in perspective of security concerns.
>
> Raul's suggestion, "A simple workaround might be to create a cron script
> which writes uptime to a file once a minute", seems far saner from a
> security point of view than letting anyone who can hit port 80 execute
> a program.

Re: No free discspace after deleting files

[Marco Prause]

No, there are no links and process that have the files opened.
Or better : I do not see any with fstat.

Maybe there's any other programs for this purpose I do not know at the
moment ?


Am 27. September 2016 08:29:06 MESZ, schrieb Raul Miller
:

Do any processes have those files open? Did you have any hard links to
those files from other names?

The disk space cannot be removed until all references to those files
are removed.

Re: No free discspace after deleting files

[Raul Miller]

Do any processes have those files open? Did you have any hard links to
those files from other names?

The disk space cannot be removed until all references to those files
are removed.

-- 
Raul

On Tue, Sep 27, 2016 at 2:24 AM, Marco Prause  wrote:
> Hi all,
>
> I met an interesting problem while deleting files that makes me curious.
>
> After deleting two files for preparing an update in a flashrd-setup
> (openbsd.vnd + bsd) I would have expected the ~1,2 GB beeing freed.
>
> The files are gone - so far so good, but the disc space is not free.
>
> I know this behaviour, if a process is still sitting on the file, but
> with fstat I can't see any process or open file handler.
>
> Now I'm just curious if I miss something and probably I just need a bit
> more coffee ;-)
>
>
> # df -h
> Filesystem SizeUsed   Avail Capacity  Mounted on
> /dev/rd0a  1.8M1.4M419K77%/
> /dev/sd0a  1.8G872M878M50%/flash
> /dev/vnd0e15.4M5.0M   10.3M32%/etc
> /dev/vnd0f42.1M   14.6M   27.0M35%/sbin
> /dev/vnd0a48.3M6.0K   47.8M 0%/root
> /dev/vnd0d16.4M5.8M   10.4M36%/bin
> /dev/vnd0g 1.1G735M347M68%/usr
> tmpfs 64.0M   61.5M2.5M96%/var
> tmpfs 50.0M4.0K   50.0M 0%/home
> tmpfs 16.0M4.0K   16.0M 0%/tmp
> /dev/sd0d 10.9G616M9.7G 6%/data
> #
> # du -hs /flash/
> 68.9M   /flash/
> #
> # mount
> /dev/rd0a on / type ffs (local)
> /dev/sd0a on /flash type ffs (local, noatime, nodev, nosuid)
> /dev/vnd0e on /etc type ffs (local, noatime, nodev, nosuid, read-only)
> /dev/vnd0f on /sbin type ffs (local, noatime, nodev, read-only)
> /dev/vnd0a on /root type ffs (local, noatime, nodev, nosuid, read-only)
> /dev/vnd0d on /bin type ffs (local, noatime, nodev, nosuid, read-only)
> /dev/vnd0g on /usr type ffs (local, noatime, nodev, read-only)
> tmpfs on /var type tmpfs (local, noatime, nodev, nosuid)
> tmpfs on /home type tmpfs (local, noatime, nodev, nosuid)
> tmpfs on /tmp type tmpfs (local, noatime, nodev, nosuid)
> /dev/sd0d on /data type ffs (local)
> #
> # iostat 1 10
>   tty  sd0   rd0   sd1
> sd2 cpu
>  tin tout  KB/t  t/s  MB/s   KB/t  t/s  MB/s   KB/t  t/s  MB/s   KB/t
> t/s  MB/s  us ni sy in id
>01 15.280  0.00   0.000  0.00   6.090  0.00   0.00
> 0  0.00   0  0  1  1 98
>0  294  0.000  0.00   0.000  0.00   0.000  0.00   0.00
> 0  0.00   0  0  1  3 96
>0   97  0.000  0.00   0.000  0.00   0.000  0.00   0.00
> 0  0.00   0  0  2  3 95
>0   97  0.000  0.00   0.000  0.00   0.000  0.00   0.00
> 0  0.00   0  0  1  1 98
>0   98  0.000  0.00   0.000  0.00   0.000  0.00   0.00
> 0  0.00   0  0  0  0100
>0   96  0.000  0.00   0.000  0.00   0.000  0.00   0.00
> 0  0.00   1  0  1  2 96
>0   98  0.000  0.00   0.000  0.00   0.000  0.00   0.00
> 0  0.00   0  0  0  1 99
>0   97  0.000  0.00   0.000  0.00   0.000  0.00   0.00
> 0  0.00   0  0  2  1 97
>0   97  0.000  0.00   0.000  0.00   0.000  0.00   0.00
> 0  0.00   0  0  0  1 99
>0   96  0.000  0.00   0.000  0.00   0.000  0.00   0.00
> 0  0.00   2  0  0  3 95
> #
> # uname -a
>
> OpenBSD gw.idst 5.9 FLASHRD.MP#2 amd64
> #
> # dmesg
>
> OpenBSD 5.9-stable (FLASHRD.MP) #2: Wed Aug 17 17:48:07 CEST 2016
>
> r...@openbsd-59-amd64-build.my.domain:/usr/src/sys/arch/amd64/compile/FLASHRD.MP
> real mem = 2098520064 (2001MB)
> avail mem = 2028883968 (1934MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (6 entries)
> bios0: vendor coreboot version "SageBios_PCEngines_APU-45" date 04/05/2014
> bios0: PC Engines APU
> acpi0 at bios0: rev 0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
> acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4)
> PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3)
> UOH3(S3) UOH4(S3) UOH5(S3) [...]
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpihpet0 at acpi0: 14318180 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD G-T40E Processor, 1000.13 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 

No free discspace after deleting files

[Marco Prause]

Hi all,

I met an interesting problem while deleting files that makes me curious.

After deleting two files for preparing an update in a flashrd-setup
(openbsd.vnd + bsd) I would have expected the ~1,2 GB beeing freed.

The files are gone - so far so good, but the disc space is not free.

I know this behaviour, if a process is still sitting on the file, but
with fstat I can't see any process or open file handler.

Now I'm just curious if I miss something and probably I just need a bit
more coffee ;-)


# df -h
Filesystem SizeUsed   Avail Capacity  Mounted on
/dev/rd0a  1.8M1.4M419K77%/
/dev/sd0a  1.8G872M878M50%/flash
/dev/vnd0e15.4M5.0M   10.3M32%/etc
/dev/vnd0f42.1M   14.6M   27.0M35%/sbin
/dev/vnd0a48.3M6.0K   47.8M 0%/root
/dev/vnd0d16.4M5.8M   10.4M36%/bin
/dev/vnd0g 1.1G735M347M68%/usr
tmpfs 64.0M   61.5M2.5M96%/var
tmpfs 50.0M4.0K   50.0M 0%/home
tmpfs 16.0M4.0K   16.0M 0%/tmp
/dev/sd0d 10.9G616M9.7G 6%/data
#
# du -hs /flash/
68.9M   /flash/
#
# mount
/dev/rd0a on / type ffs (local)
/dev/sd0a on /flash type ffs (local, noatime, nodev, nosuid)
/dev/vnd0e on /etc type ffs (local, noatime, nodev, nosuid, read-only)
/dev/vnd0f on /sbin type ffs (local, noatime, nodev, read-only)
/dev/vnd0a on /root type ffs (local, noatime, nodev, nosuid, read-only)
/dev/vnd0d on /bin type ffs (local, noatime, nodev, nosuid, read-only)
/dev/vnd0g on /usr type ffs (local, noatime, nodev, read-only)
tmpfs on /var type tmpfs (local, noatime, nodev, nosuid)
tmpfs on /home type tmpfs (local, noatime, nodev, nosuid)
tmpfs on /tmp type tmpfs (local, noatime, nodev, nosuid)
/dev/sd0d on /data type ffs (local)
#
# iostat 1 10
  tty  sd0   rd0   sd1
sd2 cpu
 tin tout  KB/t  t/s  MB/s   KB/t  t/s  MB/s   KB/t  t/s  MB/s   KB/t
t/s  MB/s  us ni sy in id
   01 15.280  0.00   0.000  0.00   6.090  0.00   0.00
0  0.00   0  0  1  1 98
   0  294  0.000  0.00   0.000  0.00   0.000  0.00   0.00
0  0.00   0  0  1  3 96
   0   97  0.000  0.00   0.000  0.00   0.000  0.00   0.00
0  0.00   0  0  2  3 95
   0   97  0.000  0.00   0.000  0.00   0.000  0.00   0.00
0  0.00   0  0  1  1 98
   0   98  0.000  0.00   0.000  0.00   0.000  0.00   0.00
0  0.00   0  0  0  0100
   0   96  0.000  0.00   0.000  0.00   0.000  0.00   0.00
0  0.00   1  0  1  2 96
   0   98  0.000  0.00   0.000  0.00   0.000  0.00   0.00
0  0.00   0  0  0  1 99
   0   97  0.000  0.00   0.000  0.00   0.000  0.00   0.00
0  0.00   0  0  2  1 97
   0   97  0.000  0.00   0.000  0.00   0.000  0.00   0.00
0  0.00   0  0  0  1 99
   0   96  0.000  0.00   0.000  0.00   0.000  0.00   0.00
0  0.00   2  0  0  3 95
#
# uname -a

OpenBSD gw.idst 5.9 FLASHRD.MP#2 amd64
#
# dmesg

OpenBSD 5.9-stable (FLASHRD.MP) #2: Wed Aug 17 17:48:07 CEST 2016

r...@openbsd-59-amd64-build.my.domain:/usr/src/sys/arch/amd64/compile/FLASHRD.MP
real mem = 2098520064 (2001MB)
avail mem = 2028883968 (1934MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (6 entries)
bios0: vendor coreboot version "SageBios_PCEngines_APU-45" date 04/05/2014
bios0: PC Engines APU
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4)
PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3)
UOH3(S3) UOH4(S3) UOH5(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD G-T40E Processor, 1000.13 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, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD G-T40E Processor, 1000.00 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