Re: check KTRPOINT() before calling ktrpledge()

[Philip Guenther]

On Mon, Jun 20, 2016 at 11:34 PM, Michal Mazurek  wrote:
> Don't ktrace pledge if it is not enabled.

Committed...through the real reason to do this is that KTRPOINT() is
what guarantees that writing of ktrace records can't loop back into
ktrace.

Philip Guenther

Re: cat.1 forward refs

[Ted Unangst]

Jason McIntyre wrote:
> therefore the pattern is currently to say it explicitly. we could
> do both, but that adds verbosity. it's a trade off, no? i wouldn;t
> be against documenting both bits of information, but i'm not sure
> it's really worth it.
> 
> i think it'd be wrong to lose the info about options implying other
> options though. and i note where you now effectively do both (-e and -t)
> you are at least as verbose as before, if not more. and "as according
> to" is much less clear than "implies".

Thanks, I attempted to keep a mix of old and new.

Re: acpiec: handle burst mode failure

[Philip Guenther]

On Sat, Jul 9, 2016 at 6:08 AM, joshua stein  wrote:
> On Fri, 08 Jul 2016 at 22:34:34 -0700, Philip Guenther wrote:
>> On Fri, Jul 8, 2016 at 4:51 PM, joshua stein  wrote:
>> > If the EC fails to go into burst mode for whatever reason, the Burst
>> > Acknowledge byte will not be there to read, which means the status
>> > won't have EC_STAT_OBF, which means acpiec_wait will spin forever,
>> > hanging the machine.
>> >
>> > This at least gets us moving again, ignoring the failure to enter
>> > burst mode.
>>
>> Is it truly failing to enter burst mode, or are we just not doing the
>> dance to enter correctly?  Looks like we should be waiting for an SCI
>> and checking for a burst acknowledge byte?
>
> All subsequent status fetches show that burst is not on.

No newer bios for this thing?  :-(


...
>> So if it doesn't immediately set either the burst or OBF flag then
>> we'll continue on without reading the data?  That's going to break
>> systems where EC isn't always fast to respond, no?
>
> That's why the diff also includes the change to acpiec_write_cmd to
> wait until IBF is 0, so it won't get to that new status check until
> the controller has processed the EC_CMD_BE fully.

I don't think the spec guarantees that implication, though it may be
true in practice.



Wonder what Windows and Linux do on this thing.

Anyway, this diff would need to be tested broadly on *unaffected*
hardware to gain confidence it doesn't hurt some box that doesn't have
this brokeness.


Philip Guenther

Re: smu-pulsar node delays G5 boot

[Marcus Glocker]

On Sat, Jul 09, 2016 at 10:24:59PM +0200, Mark Kettenis wrote:

> > Date: Sat, 9 Jul 2016 22:07:16 +0200
> > From: Marcus Glocker 
> > 
> > On every boot on my G5 the 'smu-pulsar' node hangs for around 66 seconds
> > in autoconfs config_search() it seems before the boot process continues:
> > 
> > "smu-pulsar" at iic2 addr 0x6a not configured
> > 
> > I don't know why.
> > 
> > Anyone else seeing this with a 'smu-pulsar' node in his FDT?
> > Anything speaking against it to skip it from autoconf for now, similar
> > as we already do for 'deq' and 'tas3004'?
> 
> That makes no sense.  The delay is in no way related to this
> "smu-pulsar" device.  As the "not configured" message indicates, we
> don't have a driver for this device.  All your diff does is eliminate
> that message.  The delay will still be there.

With this diff the delay is gone.

But as said, I don't understand yet where it exactly happens.
 
> In all likelyhood, the delay will be caused by the device that comes next.
>
> 
> > Index: maci2c.c
> > ===
> > RCS file: /cvs/src/sys/arch/macppc/dev/maci2c.c,v
> > retrieving revision 1.11
> > diff -u -p -u -p -r1.11 maci2c.c
> > --- maci2c.c23 May 2016 15:23:20 -  1.11
> > +++ maci2c.c9 Jul 2016 19:55:04 -
> > @@ -59,6 +59,9 @@ maciic_scan(struct device *self, struct 
> >the i2s port.  For now hide them.  */
> > if (strcmp(name, "deq") == 0 || strcmp(name, "tas3004") == 0)
> > continue;
> > +   /* Skip the smu-pulsar node which delays the boot process. */
> > +   if (strcmp(name, "smu-pulsar") == 0)
> > +   continue;
> > if (ia.ia_name)
> > config_found(self, , iic_print);
> > }
> > 
> > 

Re: calendar(1) handling of Weekday+5 and 31st events

[Ted Unangst]

Andy Bradford wrote:
> And here is the patch:
> 
> Index: calendar/day.c
> ===
> RCS file: /home/cvs/src/usr.bin/calendar/day.c,v
> retrieving revision 1.32
> diff -u -p -r1.32 day.c
> --- calendar/day.c8 Dec 2015 19:04:50 -   1.32
> +++ calendar/day.c9 Jul 2016 20:53:13 -
> @@ -543,8 +543,9 @@ isnow(char *endp, int bodun)
>   tdiff = difftime(ttmp, f_time)/ SECSPERDAY;
>   if (tdiff <= offset + f_dayAfter ||
>   (bodun && tdiff == -1)) {
> - if (tdiff >=  0 ||
> - (bodun && tdiff == -1)) {
> + if ((tmtmp.tm_mon == month) &&
> + (tdiff >=  0 ||
> + (bodun && tdiff == -1))) {
>   if ((tmp = malloc(sizeof(struct 
> match))) == NULL)
>   err(1, NULL);
>   tmp->when = ttmp;
> 
> This works because when variable_weekday returns it places a value in v1
> that is larger  than a month's worth  of days. For example,  for July 1,
> 2016, Sunday+5  gets a  value of  33 in  tmtmp.tm_mday for  which mktime
> advances advances the month to account  for the extra days when creating
> the  timestamp. Now  the months  are different  and should  probably not
> count as a match.

That makes sense. I guess the failure to check month was an oversight, not
expecting it could change.

calendar(1) handling of Weekday+5 and 31st events

[Andy Bradford]

Hello,

The following patch  seems to allow calendar to better  handle the fifth
weekday  and 31st  events.  Currently,  both events  match  also at  the
beginning  of certain  months  which  doesn't seem  to  make sense.  For
example,  March  02 is  considered  a  31st this  year  and  July 03  is
considered a Fifth Sunday:

$ sh /tmp/calendar.sh   
calendar -f /tmp/calendar.We1Ga8 -t 20160101
Jan 03* Fifth Sunday.
calendar -f /tmp/calendar.We1Ga8 -t 20160130
Jan 31* Fifth Sunday.
Jan 31* 31st.
calendar -f /tmp/calendar.We1Ga8 -t 20160301
Mar 02* 31st.
calendar -f /tmp/calendar.We1Ga8 -t 20160701
Jul 01* 31st.
Jul 03* Fifth Sunday.
calendar -f /tmp/calendar.We1Ga8 -t 20160729
Jul 31* Fifth Sunday.
Jul 31* 31st.

Here is how it behaves with the patch:

$ sh /tmp/calendar.sh /usr/src/usr.bin/calendar/obj/calendar
/usr/src/usr.bin/calendar/obj/calendar -f /tmp/calendar.83O1qH -t 20160101
/usr/src/usr.bin/calendar/obj/calendar -f /tmp/calendar.83O1qH -t 20160130
Jan 31* Fifth Sunday.
Jan 31* 31st.
/usr/src/usr.bin/calendar/obj/calendar -f /tmp/calendar.83O1qH -t 20160301
/usr/src/usr.bin/calendar/obj/calendar -f /tmp/calendar.83O1qH -t 20160701
/usr/src/usr.bin/calendar/obj/calendar -f /tmp/calendar.83O1qH -t 20160729
Jul 31* Fifth Sunday.
Jul 31* 31st.

Here is calendar.sh:

$ cat /tmp/calendar.sh 
PROG=${1:-calendar}
CALENDAR=$(mktemp -t calendar.XX)
printf '
Sunday+5\tFifth Sunday.
31 *\t31st.
' >"$CALENDAR"
for date in 20160101 20160130 20160301 20160701 20160729
do
  set -- "$PROG" -f "$CALENDAR" -t "$date"
  echo "$@"
  eval "$@"
done
rm "$CALENDAR"

And here is the patch:

Index: calendar/day.c
===
RCS file: /home/cvs/src/usr.bin/calendar/day.c,v
retrieving revision 1.32
diff -u -p -r1.32 day.c
--- calendar/day.c  8 Dec 2015 19:04:50 -   1.32
+++ calendar/day.c  9 Jul 2016 20:53:13 -
@@ -543,8 +543,9 @@ isnow(char *endp, int bodun)
tdiff = difftime(ttmp, f_time)/ SECSPERDAY;
if (tdiff <= offset + f_dayAfter ||
(bodun && tdiff == -1)) {
-   if (tdiff >=  0 ||
-   (bodun && tdiff == -1)) {
+   if ((tmtmp.tm_mon == month) &&
+   (tdiff >=  0 ||
+   (bodun && tdiff == -1))) {
if ((tmp = malloc(sizeof(struct 
match))) == NULL)
err(1, NULL);
tmp->when = ttmp;

This works because when variable_weekday returns it places a value in v1
that is larger  than a month's worth  of days. For example,  for July 1,
2016, Sunday+5  gets a  value of  33 in  tmtmp.tm_mday for  which mktime
advances advances the month to account  for the extra days when creating
the  timestamp. Now  the months  are different  and should  probably not
count as a match.

Are there any bad side-effects in this approach?

Thanks,

Andy
-- 
TAI64 timestamp: 40005781686f

Re: smu-pulsar node delays G5 boot

[Mark Kettenis]

> Date: Sat, 9 Jul 2016 22:07:16 +0200
> From: Marcus Glocker 
> 
> On every boot on my G5 the 'smu-pulsar' node hangs for around 66 seconds
> in autoconfs config_search() it seems before the boot process continues:
> 
>   "smu-pulsar" at iic2 addr 0x6a not configured
> 
> I don't know why.
> 
> Anyone else seeing this with a 'smu-pulsar' node in his FDT?
> Anything speaking against it to skip it from autoconf for now, similar
> as we already do for 'deq' and 'tas3004'?

That makes no sense.  The delay is in no way related to this
"smu-pulsar" device.  As the "not configured" message indicates, we
don't have a driver for this device.  All your diff does is eliminate
that message.  The delay will still be there.

In all likelyhood, the delay will be caused by the device that comes next.


> Index: maci2c.c
> ===
> RCS file: /cvs/src/sys/arch/macppc/dev/maci2c.c,v
> retrieving revision 1.11
> diff -u -p -u -p -r1.11 maci2c.c
> --- maci2c.c  23 May 2016 15:23:20 -  1.11
> +++ maci2c.c  9 Jul 2016 19:55:04 -
> @@ -59,6 +59,9 @@ maciic_scan(struct device *self, struct 
>  the i2s port.  For now hide them.  */
>   if (strcmp(name, "deq") == 0 || strcmp(name, "tas3004") == 0)
>   continue;
> + /* Skip the smu-pulsar node which delays the boot process. */
> + if (strcmp(name, "smu-pulsar") == 0)
> + continue;
>   if (ia.ia_name)
>   config_found(self, , iic_print);
>   }
> 
> 

smu-pulsar node delays G5 boot

[Marcus Glocker]

On every boot on my G5 the 'smu-pulsar' node hangs for around 66 seconds
in autoconfs config_search() it seems before the boot process continues:

"smu-pulsar" at iic2 addr 0x6a not configured

I don't know why.

Anyone else seeing this with a 'smu-pulsar' node in his FDT?
Anything speaking against it to skip it from autoconf for now, similar
as we already do for 'deq' and 'tas3004'?


Index: maci2c.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/maci2c.c,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 maci2c.c
--- maci2c.c23 May 2016 15:23:20 -  1.11
+++ maci2c.c9 Jul 2016 19:55:04 -
@@ -59,6 +59,9 @@ maciic_scan(struct device *self, struct 
   the i2s port.  For now hide them.  */
if (strcmp(name, "deq") == 0 || strcmp(name, "tas3004") == 0)
continue;
+   /* Skip the smu-pulsar node which delays the boot process. */
+   if (strcmp(name, "smu-pulsar") == 0)
+   continue;
if (ia.ia_name)
config_found(self, , iic_print);
}

Re: [armv7] introducing tipru(4)

[Theo de Raadt]

I am pretty unhappy about drivers like this arriving in the tree.  I
just don't see any trustworthy way to use them, and lacking trust -- I
don't understand the worth.

Givings hugs to trustworthy designs is an OpenBSD agenda.  Giving
scowls to untrustworthy designs is another OpenBSD agenda.  Uplifting
ones that are semi-trustworthy to become more trustworthy... well you
get the idea.

So this can run some semi-proprietary code that is uploaded and runs
entirely unsafely.  Why bother.  How many people will use this, in
OpenBSD?  Besides you, I anticipate noone.

The right way to use a device is through deep careful integration
of the featureset it has, into natural functionality that can be
exposed as a sane driver interface in /dev/, or hidden even further
so that it does something which makes the kernel faster.

Exposing anything like this raw, is not the unix way.

I wonder what we'll see next, along this line.  Maybe a way to load
AML code from userland on an amd64, be interpreted by the AML
interpreter to control fan speeds by twiddling bits in ACPI register
spaces?  Or a way to load DRM code directly?

I think we can all agree those type of things are a much lesser
form of "progress".  Abstraction is a powerful uplift, raw is raw.

Re: route6d summer cleanup

[Jeremie Courreges-Anglas]

j...@wxcvbn.org (Jeremie Courreges-Anglas) writes:

> j...@wxcvbn.org (Jeremie Courreges-Anglas) writes:
>
>> j...@wxcvbn.org (Jeremie Courreges-Anglas) writes:
>>
>>> Nobody cares about route6d, and it shows: runas as root, not chrooted.
>>> Also it uses wide pledge(2) permissions.
>>>
>>> I have diffs to switch the logging to log.c and use it to support the -R
>>> option and /var/run/route6d_dump.  The end goal is to use a tighter
>>> pledge(2) call:
>>> +   if (pledge("stdio inet route mcast", NULL) == -1)
>
> So here's the diff.
>
> log.c and log.h come from rtadvd.  I have added a simple log queue
> mechanism so that the changes in route6d.c are minimal, and so that we
> stop sending crap (newlines) to syslog.  Due to log_enqueue() the
> conversion is mostly mechanical.  I did not add checks for cases where
> log_warn / fatal are called right after log_enqueue.
>
> This also introduces a -u option for people that may have previously
> used -R. route updates can be inconditionally logged and contain
> a distinctive marker.
>
> Tests / feedback / oks welcome.

Dunno how but I failed to remove the closelog(3) call.

It would be nice to get this in for 6.0, but this won't happen without
proper tests.  The only actual user I know is on holidays, so I'll have
to find some time for tests next week.  Meanwhile, reviews are still
welcome.

Index: Makefile
===
RCS file: /cvs/src/usr.sbin/route6d/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile25 Oct 2015 22:38:48 -  1.8
+++ Makefile9 Jul 2016 18:32:02 -
@@ -3,4 +3,6 @@
 PROG=  route6d
 MAN=   route6d.8
 
+SRCS=  route6d.c log.c
+
 .include 
Index: log.c
===
RCS file: log.c
diff -N log.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ log.c   9 Jul 2016 18:32:02 -
@@ -0,0 +1,184 @@
+/*
+ * Copyright (c) 2003, 2004 Henning Brauer 
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "log.h"
+
+static int debug;
+
+static char*logqueue;
+
+#define LOGQUEUE_SIZE 1024
+
+void   logit(int, const char *, ...);
+void   vlog(int pri, const char *fmt, va_list ap);
+
+void
+log_init(int n_debug)
+{
+   extern char *__progname;
+
+   if (logqueue == NULL) {
+   logqueue = calloc(LOGQUEUE_SIZE, 1);
+   if (logqueue == NULL)
+   err(1, NULL);
+   }
+
+   debug = n_debug;
+
+   if (!debug)
+   openlog(__progname, LOG_PID | LOG_NDELAY, LOG_DAEMON);
+
+   tzset();
+}
+
+void
+logit(int pri, const char *fmt, ...)
+{
+   va_list ap;
+
+   va_start(ap, fmt);
+   vlog(pri, fmt, ap);
+   va_end(ap);
+}
+
+void
+log_enqueue(const char *fmt, ...)
+{
+   char tmpbuf[LOGQUEUE_SIZE];
+   va_list ap;
+
+   va_start(ap, fmt);
+   (void)vsnprintf(tmpbuf, sizeof(tmpbuf), fmt, ap);
+   va_end(ap);
+   (void)strlcat(logqueue, tmpbuf, LOGQUEUE_SIZE);
+}
+
+
+void
+vlog(int pri, const char *fmt, va_list ap)
+{
+   chartmpbuf[1024];
+   charlogbuf[LOGQUEUE_SIZE + sizeof(tmpbuf)];
+
+   if (!debug) {
+   logqueue[0] = '\0';
+   return;
+   }
+
+   (void)vsnprintf(tmpbuf, sizeof(tmpbuf), fmt, ap);
+   (void)strlcpy(logbuf, logqueue, sizeof(logbuf));
+   (void)strlcat(logbuf, tmpbuf, sizeof(tmpbuf));
+
+   logqueue[0] = '\0';
+
+   if (debug) {
+   fprintf(stderr, "%s\n", logbuf);
+   fflush(stderr);
+   } else
+   syslog(pri, "%s", logbuf);
+}
+
+void
+log_warn(const char *emsg, ...)
+{
+   char*nfmt;
+   va_list  ap;
+
+   if (emsg == NULL)
+   logit(LOG_CRIT, "%s", strerror(errno));
+   else {
+   va_start(ap, emsg);
+
+   /* best effort to even work in out of memory situations */
+   if (asprintf(, "%s: %s", emsg, strerror(errno)) == -1) {
+   /* we tried it... */
+   vlog(LOG_CRIT, emsg, ap);
+   logit(LOG_CRIT, "%s", strerror(errno));

Re: Better for mount(2)

[Jason McIntyre]

On Sat, Jul 09, 2016 at 06:20:49PM +0300, Vadim Zhukov wrote:
> Hello all.
> 

evening.

> As found by some of my students, mount(2) lacks description of some
> flags used by userland. After trying to sync things out, I realized
> that this page is not well organized at all. For example, unmount
> syscall is mentioned closer to end, after description of flags that
> it could use.
> 
> I didn't document all of the flags involved in mount calls, since
> some of them are purely kernel internal. But I could easily miss
> something crucial...
> 
> So this is my first public draft of mount(2) patch. Looking for
> comments & thanks in advance!
> 
> --
> WBR,
>   Vadim Zhukov
> 

comments inline.

> 
> Index: mount.2
> ===
> RCS file: /cvs/src/lib/libc/sys/mount.2,v
> retrieving revision 1.46
> diff -u -p -r1.46 mount.2
> --- mount.2   27 May 2016 19:45:04 -  1.46
> +++ mount.2   9 Jul 2016 15:16:29 -
> @@ -70,31 +70,57 @@ at the time
>  of a successful mount are swept under the carpet, so to speak, and
>  are unavailable until the filesystem is unmounted.
>  .Pp
> +The
> +.Fn unmount
> +function call disassociates the filesystem from the specified
> +mount point
> +.Fa dir .
> +.Pp

i agree this is an improvement.

>  The following
>  .Fa flags
>  may be specified to
>  suppress default semantics which affect filesystem access.

note the sentence above. it makes adding some of these options tricky
since it will essentially contradict what is written there. so, assuming
there is a reason to document these other flags (that is, no reason not
to), you will have to change that sentence.

>  .Bl -tag -width MNT_SYNCHRONOUS
> -.It Dv MNT_RDONLY
> -The filesystem should be treated as read-only:
> -even the superuser may not write to it.
> +.It Dv MNT_ASYNC
> +All I/O to the filesystem should be done asynchronously.

ordering these alphabetically seems reasonable - i assume there's no
reason for the current order?

> +.It Dv MNT_FORCE
> +On unmount, specifies that the filesystem should be forcibly unmounted
> +even if files are still active.
> +Active special devices continue to work,
> +but any further accesses to any other active files result in errors

s/accesses/access/

> +even if the filesystem is later remounted.
> +On update, allows to forcibly change from read-write to read-only,

s/allows to forcibly change/forcibly changes/

> +even if there are files open for writing.
>  .It Dv MNT_NOATIME
>  Do not update the access time on files in the filesystem unless
>  the modification or status change times are also being updated.
> +.It Dv MNT_NODEV
> +Do not interpret special files on the filesystem.
>  .It Dv MNT_NOEXEC
>  Do not allow files to be executed from the filesystem.
>  .It Dv MNT_NOSUID
>  Do not honor setuid or setgid bits on files when executing them.
> -.It Dv MNT_NODEV
> -Do not interpret special files on the filesystem.
> -.It Dv MNT_SYNCHRONOUS
> -All I/O to the filesystem should be done synchronously.
> -.It Dv MNT_ASYNC
> -All I/O to the filesystem should be done asynchronously.
> +.It Dv MNT_RDONLY
> +The filesystem should be treated as read-only:
> +even the superuser may not write to it.
> +.It Dv MNT_RELOAD
> +Reload already mounted filesystem.

i think "reload" is a bit ambiguous. what does it actually do?

> +Used, e.g., by

i'd change the e.g. to "for example". or at least kill the comma after
the "g."

> +.Xr fsck 8 .
>  .It Dv MNT_SOFTDEP
>  Use soft dependencies.
>  Applies to FFS filesystems only (see 'softdep' in
>  .Xr mount 8 ) .
> +.It Dv MNT_SYNCHRONOUS
> +All I/O to the filesystem should be done synchronously.
> +.It Dv MNT_UPDATE
> +Indicates that the mount command is being applied to an already mounted
> +filesystem.
> +This allows the mount flags to be changed without requiring
> +that the filesystem be unmounted and remounted.
> +Some filesystems may not allow all flags to be changed.
> +For example,
> +most filesystems will not allow a change from read-write to read-only.
>  .It MNT_WXALLOWED
>  Processes that ask for memory to be made writeable plus executable
>  using the
> @@ -108,16 +134,6 @@ The option is typically used on the
>  filesystem.
>  .El
>  .Pp
> -The flag
> -.Dv MNT_UPDATE
> -indicates that the mount command is being applied
> -to an already mounted filesystem.
> -This allows the mount flags to be changed without requiring
> -that the filesystem be unmounted and remounted.
> -Some filesystems may not allow all flags to be changed.
> -For example,
> -most filesystems will not allow a change from read-write to read-only.
> -.Pp

i'm less sure here. i think this option makes sense outwith the option
list. but i guess if you change the first sentence, it might work. not
convinced, though.

>  The
>  .Fa type
>  argument defines the type of the filesystem.
> @@ -237,22 +253,6 @@ struct udf_args {
>   char*fspec; /* block special device to mount */
>  };
>  .Ed
> -.Pp
> -The
> -.Fn 

Better for mount(2)

[Vadim Zhukov]

Hello all.

As found by some of my students, mount(2) lacks description of some
flags used by userland. After trying to sync things out, I realized
that this page is not well organized at all. For example, unmount
syscall is mentioned closer to end, after description of flags that
it could use.

I didn't document all of the flags involved in mount calls, since
some of them are purely kernel internal. But I could easily miss
something crucial...

So this is my first public draft of mount(2) patch. Looking for
comments & thanks in advance!

--
WBR,
  Vadim Zhukov


Index: mount.2
===
RCS file: /cvs/src/lib/libc/sys/mount.2,v
retrieving revision 1.46
diff -u -p -r1.46 mount.2
--- mount.2 27 May 2016 19:45:04 -  1.46
+++ mount.2 9 Jul 2016 15:16:29 -
@@ -70,31 +70,57 @@ at the time
 of a successful mount are swept under the carpet, so to speak, and
 are unavailable until the filesystem is unmounted.
 .Pp
+The
+.Fn unmount
+function call disassociates the filesystem from the specified
+mount point
+.Fa dir .
+.Pp
 The following
 .Fa flags
 may be specified to
 suppress default semantics which affect filesystem access.
 .Bl -tag -width MNT_SYNCHRONOUS
-.It Dv MNT_RDONLY
-The filesystem should be treated as read-only:
-even the superuser may not write to it.
+.It Dv MNT_ASYNC
+All I/O to the filesystem should be done asynchronously.
+.It Dv MNT_FORCE
+On unmount, specifies that the filesystem should be forcibly unmounted
+even if files are still active.
+Active special devices continue to work,
+but any further accesses to any other active files result in errors
+even if the filesystem is later remounted.
+On update, allows to forcibly change from read-write to read-only,
+even if there are files open for writing.
 .It Dv MNT_NOATIME
 Do not update the access time on files in the filesystem unless
 the modification or status change times are also being updated.
+.It Dv MNT_NODEV
+Do not interpret special files on the filesystem.
 .It Dv MNT_NOEXEC
 Do not allow files to be executed from the filesystem.
 .It Dv MNT_NOSUID
 Do not honor setuid or setgid bits on files when executing them.
-.It Dv MNT_NODEV
-Do not interpret special files on the filesystem.
-.It Dv MNT_SYNCHRONOUS
-All I/O to the filesystem should be done synchronously.
-.It Dv MNT_ASYNC
-All I/O to the filesystem should be done asynchronously.
+.It Dv MNT_RDONLY
+The filesystem should be treated as read-only:
+even the superuser may not write to it.
+.It Dv MNT_RELOAD
+Reload already mounted filesystem.
+Used, e.g., by
+.Xr fsck 8 .
 .It Dv MNT_SOFTDEP
 Use soft dependencies.
 Applies to FFS filesystems only (see 'softdep' in
 .Xr mount 8 ) .
+.It Dv MNT_SYNCHRONOUS
+All I/O to the filesystem should be done synchronously.
+.It Dv MNT_UPDATE
+Indicates that the mount command is being applied to an already mounted
+filesystem.
+This allows the mount flags to be changed without requiring
+that the filesystem be unmounted and remounted.
+Some filesystems may not allow all flags to be changed.
+For example,
+most filesystems will not allow a change from read-write to read-only.
 .It MNT_WXALLOWED
 Processes that ask for memory to be made writeable plus executable
 using the
@@ -108,16 +134,6 @@ The option is typically used on the
 filesystem.
 .El
 .Pp
-The flag
-.Dv MNT_UPDATE
-indicates that the mount command is being applied
-to an already mounted filesystem.
-This allows the mount flags to be changed without requiring
-that the filesystem be unmounted and remounted.
-Some filesystems may not allow all flags to be changed.
-For example,
-most filesystems will not allow a change from read-write to read-only.
-.Pp
 The
 .Fa type
 argument defines the type of the filesystem.
@@ -237,22 +253,6 @@ struct udf_args {
char*fspec; /* block special device to mount */
 };
 .Ed
-.Pp
-The
-.Fn unmount
-function call disassociates the filesystem from the specified
-mount point
-.Fa dir .
-.Pp
-The
-.Fa flags
-argument may specify
-.Dv MNT_FORCE
-to specify that the filesystem should be forcibly unmounted even if files are
-still active.
-Active special devices continue to work,
-but any further accesses to any other active files result in errors
-even if the filesystem is later remounted.
 .Sh RETURN VALUES
 .Rv -std
 .Sh ERRORS

Re: acpiec: handle burst mode failure

[joshua stein]

On Fri, 08 Jul 2016 at 22:34:34 -0700, Philip Guenther wrote:
> On Fri, Jul 8, 2016 at 4:51 PM, joshua stein  wrote:
> > If the EC fails to go into burst mode for whatever reason, the Burst
> > Acknowledge byte will not be there to read, which means the status
> > won't have EC_STAT_OBF, which means acpiec_wait will spin forever,
> > hanging the machine.
> >
> > This at least gets us moving again, ignoring the failure to enter
> > burst mode.
> 
> Is it truly failing to enter burst mode, or are we just not doing the
> dance to enter correctly?  Looks like we should be waiting for an SCI
> and checking for a burst acknowledge byte?

All subsequent status fetches show that burst is not on.

> ...
> > @@ -196,7 +197,10 @@ void
> >  acpiec_burst_enable(struct acpiec_softc *sc)
> >  {
> > acpiec_write_cmd(sc, EC_CMD_BE);
> > -   acpiec_read_data(sc);
> > +   if (acpiec_status(sc) & (EC_STAT_BURST|EC_STAT_OBF))
> > +   acpiec_read_data(sc);
> > +   else
> > +   dnprintf(10, "%s: failed to enter burst mode\n", 
> > DEVNAME(sc));
> >  }
> 
> So if it doesn't immediately set either the burst or OBF flag then
> we'll continue on without reading the data?  That's going to break
> systems where EC isn't always fast to respond, no?

That's why the diff also includes the change to acpiec_write_cmd to
wait until IBF is 0, so it won't get to that new status check until
the controller has processed the EC_CMD_BE fully.

Re: [armv7] introducing tipru(4)

[Ian Sutton]

On Wed, Jul 6, 2016 at 5:41 AM, Damien Miller  wrote:
> That sounds like a reasonable compromise - it would let the admin load
> code to the PRUs in rc.securelevel for later use, or set
> kern.securelevel=0 in sysctl.conf if they wanted to do development
> on a multi-user system.

OK -- I have tested and fixed the previous design. It is now working
exactly as stated in the man page from my prior mail. Below patch is now
in a review-ready state.

On Wed, Jul 6, 2016 at 3:27 AM, Ian Sutton  wrote:
> mainbus -> fdt is next.

tipru(4) now attaches via flattened device tree. However, the dtb
included in miniroot-am335x-60.fs is erroneously devoid of a PRU node.
Here is a patch for the decompiled source file:

http://ce.gl/am335x-boneblack.dts.patch

And the resultant binary for convenience's sake:

http://ce.gl/am335x-boneblack.dtb

To replace it (on BBB, assuming root disk is sd0):

# mount /dev/sd0i /mnt
# curl http://ce.gl/am335x-boneblack.dtb > /mnt/am335x-boneblack.dtb
# umount /mnt
# reboot

Ian

Index: etc/etc.armv7/MAKEDEV
===
RCS file: /cvs/src/etc/etc.armv7/MAKEDEV,v
retrieving revision 1.19
diff -u -p -r1.19 MAKEDEV
--- etc/etc.armv7/MAKEDEV   21 May 2016 22:15:09 -  1.19
+++ etc/etc.armv7/MAKEDEV   9 Jul 2016 07:06:54 -
@@ -4,7 +4,7 @@
 # generated from:
 #
 #  OpenBSD: etc.armv7/MAKEDEV.md,v 1.12 2016/05/21 21:30:22 kettenis Exp 
-#  OpenBSD: MAKEDEV.common,v 1.88 2016/05/21 15:17:49 deraadt Exp 
+#  OpenBSD: MAKEDEV.common,v 1.89 2016/05/26 16:29:51 deraadt Exp 
 #  OpenBSD: MAKEDEV.mi,v 1.82 2016/03/12 17:58:59 espie Exp 
 #  OpenBSD: MAKEDEV.sub,v 1.14 2005/02/07 06:14:18 david Exp 
 #
@@ -59,6 +59,7 @@
 #  usb*Bus control devices used by usbd for attach/detach
 # Special purpose devices:
 #  apm Power management device
+#  tipru   Programmable realtime unit
 #  audio*  Audio devices
 #  bio ioctl tunnel pseudo-device
 #  bktr*   Video frame grabbers
@@ -328,6 +329,10 @@ audio*)
MKlist[${#MKlist[*]}]=";[ -e audioctl ] || ln -s audioctl$U audioctl"
;;
 
+tipru*)
+   M tipru c 29 0 200
+   ;;
+
 apm*)
M apm   c 34 0 644
M apmctlc 34 8 644
@@ -469,14 +474,14 @@ local)
;;
 
 all)
-   R gpio0 gpio1 gpio2 gpio3 gpio4 gpio5 gpio6 gpio7 gpio8 vnd0
-   R vnd1 vnd2 vnd3 sd0 sd1 sd2 sd3 sd4 sd5 sd6 sd7 sd8 sd9 cd0
-   R cd1 rd0 tap0 tap1 tap2 tap3 tun0 tun1 tun2 tun3 bio pty0
-   R diskmap vscsi0 ch0 bpf fuse pppx hotplug ptm local wscons
-   R pci0 pci1 pci2 pci3 uall rmidi0 rmidi1 rmidi2 rmidi3 rmidi4
-   R rmidi5 rmidi6 rmidi7 tuner0 radio0 video0 video1 uk0 random
-   R tty00 tty01 tty02 tty03 tty04 tty05 tty06 tty07 tty08 tty09
-   R tty0a tty0b apm pf wd0 wd1 wd2 wd3 std st0 st1 fd
+   R tipru0 gpio0 gpio1 gpio2 gpio3 gpio4 gpio5 gpio6 gpio7
+   R gpio8 vnd0 vnd1 vnd2 vnd3 sd0 sd1 sd2 sd3 sd4 sd5 sd6 sd7
+   R sd8 sd9 cd0 cd1 rd0 tap0 tap1 tap2 tap3 tun0 tun1 tun2 tun3
+   R bio pty0 diskmap vscsi0 ch0 bpf fuse pppx hotplug ptm local
+   R wscons pci0 pci1 pci2 pci3 uall rmidi0 rmidi1 rmidi2 rmidi3
+   R rmidi4 rmidi5 rmidi6 rmidi7 tuner0 radio0 video0 video1 uk0
+   R random tty00 tty01 tty02 tty03 tty04 tty05 tty06 tty07 tty08
+   R tty09 tty0a tty0b apm pf wd0 wd1 wd2 wd3 std st0 st1 fd
;;
 
 wd*|sd*)
Index: etc/etc.armv7/MAKEDEV.md
===
RCS file: /cvs/src/etc/etc.armv7/MAKEDEV.md,v
retrieving revision 1.12
diff -u -p -r1.12 MAKEDEV.md
--- etc/etc.armv7/MAKEDEV.md21 May 2016 21:30:22 -  1.12
+++ etc/etc.armv7/MAKEDEV.md9 Jul 2016 07:06:54 -
@@ -27,6 +27,8 @@ dnl ADVISED OF THE POSSIBILITY OF SUCH D
 dnl
 dnl
 __devitem(apm, apm, Power management device)dnl
+__devitem(tipru, tipru, Programmable realtime unit)dnl
+_mkdev(tipru, tipru*, {-M tipru c major_tipru_c 0 200-})dnl
 _TITLE(make)
 _DEV(all)
 _DEV(ramdisk)
@@ -64,6 +66,7 @@ _DEV(ulpt, 66)
 _DEV(usb, 64)
 _TITLE(spec)
 _DEV(apm, 34)
+_DEV(tipru, 29)
 _DEV(au, 36)
 _DEV(bio, 52)
 _DEV(bktr, 75)
@@ -114,3 +117,4 @@ target(all, cd, 0, 1)dnl
 target(all, sd, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9)dnl
 target(all, vnd, 0, 1, 2, 3)dnl
 target(all, gpio, 0, 1, 2, 3, 4, 5, 6, 7, 8)dnl
+target(all, tipru, 0)dnl
Index: share/man/man4/man4.armv7/tipru.4
===
RCS file: share/man/man4/man4.armv7/tipru.4
diff -N share/man/man4/man4.armv7/tipru.4
--- /dev/null   1 Jan 1970 00:00:00 -
+++ share/man/man4/man4.armv7/tipru.4   9 Jul 2016 07:07:02 -
@@ -0,0 +1,221 @@
+.\" Copyright (c) 2016 Ian Sutton 
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice