Re: svn commit: r368721 - head/stand/efi/loader

2020-12-17 Thread Warner Losh
On Thu, Dec 17, 2020 at 1:00 PM Andrew Gallatin 
wrote:

> On 12/17/20 2:49 PM, Kyle Evans wrote:
> > On Thu, Dec 17, 2020 at 1:47 PM Andrew Gallatin 
> wrote:
> >>
> >> On 12/17/20 12:02 PM, Warner Losh wrote:
> >>> Author: imp
> >>> Date: Thu Dec 17 17:02:09 2020
> >>> New Revision: 368721
> >>> URL:
> https://urldefense.com/v3/__https://svnweb.freebsd.org/changeset/base/368721__;!!OToaGQ!5c1mLnhtRtEV6Cv_MTWpzXWaGZEYYDp4TJ6wVDzjVZiehAItts7ZWC15uNnQYRa5Fg$
> >>>
> >>> Log:
> >>> Drop EFI_STAGING_SIZE back down to 64M
> >>>
> >>> vmware can't cope with anything larger than 64MB. Drop this back to
> >>> 64MB everywhere but arm.
> >>
> >> There were all kinds of booting problems before this was bumped up.
> >> In fact, I still have EFI_STAGING_SIZE=128 in src.conf because I needed
> >> it be be able to boot when using Nvidia graphics.  By reducing this, I
> >> feel like we're just playing whack-a-mole.
> >>
> >
> > IIRC those have long since become OBE as we'll now grow the staging
> > area to accommodate nvidia.
> >
>
> Ah, OK. cool!
>
> Thanks & sorry for the noise.
>

We added the 100 as a hack and then fixed the underlying problem. If 64
doesn't work for you, please let me know and I'll work with you to make it
right.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r368721 - head/stand/efi/loader

2020-12-17 Thread Warner Losh
Author: imp
Date: Thu Dec 17 17:02:09 2020
New Revision: 368721
URL: https://svnweb.freebsd.org/changeset/base/368721

Log:
  Drop EFI_STAGING_SIZE back down to 64M
  
  vmware can't cope with anything larger than 64MB. Drop this back to
  64MB everywhere but arm.
  
  PR: 251866
  MFC After: 1 week

Modified:
  head/stand/efi/loader/copy.c

Modified: head/stand/efi/loader/copy.c
==
--- head/stand/efi/loader/copy.cThu Dec 17 16:52:40 2020
(r368720)
+++ head/stand/efi/loader/copy.cThu Dec 17 17:02:09 2020
(r368721)
@@ -174,9 +174,7 @@ out:
 #endif /* __i386__ || __amd64__ */
 
 #ifndef EFI_STAGING_SIZE
-#if defined(__amd64__)
-#defineEFI_STAGING_SIZE100
-#elif defined(__arm__)
+#if defined(__arm__)
 #defineEFI_STAGING_SIZE32
 #else
 #defineEFI_STAGING_SIZE64
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r368585 - in head: sys/dev/gpio sys/sys tools/test tools/test/gpioevents usr.sbin/gpioctl

2020-12-12 Thread Warner Losh
FWIW I generally approved the code, but didn't have the time to review it
in detail. I got the impression people were at least generally happy from
the review.

Thanks so much for picking this up.

Warner

On Sat, Dec 12, 2020, 11:34 AM Ian Lepore  wrote:

> Author: ian
> Date: Sat Dec 12 18:34:15 2020
> New Revision: 368585
> URL: https://svnweb.freebsd.org/changeset/base/368585
>
> Log:
>   Provide userland notification of gpio pin changes ("userland gpio
> interrupts").
>
>   This is an import of the Google Summer of Code 2018 project completed by
>   Christian Kramer (and, sadly, ignored by us for two years now).  The
> goals
>   stated for that project were:
>
>   FreeBSD already has support for interrupts implemented in the GPIO
>   controller drivers of several SoCs, but there are no interfaces to
> take
>   advantage of them out of user space yet. The goal of this work is to
>   implement such an interface by providing descriptors which integrate
>   with the common I/O system calls and multiplexing mechanisms.
>
>   The initial imported code supports the following functionality:
>
>-  A kernel driver that provides an interface to the user space; the
>   existing gpioc(4) driver was enhanced with this functionality.
>-  Implement support for the most common I/O system calls / multiplexing
>   mechanisms:
>-  read() Places the pin number on which the interrupt occurred in
> the
>   buffer. Blocking and non-blocking behaviour supported.
>-poll()/select()
>-kqueue()
>-signal driven I/O. Posting SIGIO when the O_ASYNC was set.
>-  Many-to-many relationship between pins and file descriptors.
>-  A file descriptor can monitor several GPIO pins.
>-  A GPIO pin can be monitored by multiple file descriptors.
>-  Integration with gpioctl and libgpio.
>
>   I added some fixes (mostly to locking) and feature enhancements on top of
>   the original gsoc code.  The feature ehancements allow the user to choose
>   between detailed and summary event reporting.  Detailed reporting
> provides
>   a record describing each pin change event.  Summary reporting provides
> the
>   time of the first and last change of each pin, and a count of how many
> times
>   it changed state since the last read(2) call.  Another enhancement allows
>   the recording of multiple state change events on multiple pins between
> each
>   call to read(2) (the original code would track only a single event at a
> time).
>
>   The phabricator review for these changes timed out without approval, but
> I
>   cite it below anyway, because the review contains a series of diffs that
>   show how I evolved the code from its original state in Christian's github
>   repo for the gsoc project to what is being commited here.  (In effect,
>   the phab review extends the VC history back to the original code.)
>
>   Submitted by: Christian Kramer
>   Obtained from:https://github.com/ckraemer/freebsd/tree/gsoc2018
>   Differential Revision:https://reviews.freebsd.org/D27398
>
> Added:
>   head/tools/test/gpioevents/
>   head/tools/test/gpioevents/Makefile   (contents, props changed)
>   head/tools/test/gpioevents/gpioevents.c   (contents, props changed)
> Modified:
>   head/sys/dev/gpio/gpiobus.c
>   head/sys/dev/gpio/gpioc.c
>   head/sys/sys/gpio.h
>   head/tools/test/README
>   head/usr.sbin/gpioctl/gpioctl.c
>
> Modified: head/sys/dev/gpio/gpiobus.c
>
> ==
> --- head/sys/dev/gpio/gpiobus.c Sat Dec 12 17:11:22 2020(r368584)
> +++ head/sys/dev/gpio/gpiobus.c Sat Dec 12 18:34:15 2020(r368585)
> @@ -143,6 +143,15 @@ gpio_check_flags(uint32_t caps, uint32_t flags)
> /* Cannot mix pull-up/pull-down together. */
> if (flags & GPIO_PIN_PULLUP && flags & GPIO_PIN_PULLDOWN)
> return (EINVAL);
> +   /* Cannot mix output and interrupt flags together */
> +   if (flags & GPIO_PIN_OUTPUT && flags & GPIO_INTR_MASK)
> +   return (EINVAL);
> +   /* Only one interrupt flag can be defined at once */
> +   if ((flags & GPIO_INTR_MASK) & ((flags & GPIO_INTR_MASK) - 1))
> +   return (EINVAL);
> +   /* The interrupt attached flag cannot be set */
> +   if (flags & GPIO_INTR_ATTACHED)
> +   return (EINVAL);
>
> return (0);
>  }
>
> Modified: head/sys/dev/gpio/gpioc.c
>
> ==
> --- head/sys/dev/gpio/gpioc.c   Sat Dec 12 17:11:22 2020(r368584)
> +++ head/sys/dev/gpio/gpioc.c   Sat Dec 12 18:34:15 2020(r368585)
> @@ -35,8 +35,15 @@ __FBSDID("$FreeBSD$");
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>
>  #include 
> @@ -47,30 +54,510 @@ 

svn commit: r368352 - head/sys/dev/nvme

2020-12-04 Thread Warner Losh
Author: imp
Date: Fri Dec  4 21:34:48 2020
New Revision: 368352
URL: https://svnweb.freebsd.org/changeset/base/368352

Log:
  nvme: Remove a wmb() that's not necessary.
  
  bus_dmamap_sync() ensures that memory that's prepared for PREWRITE can
  be DMA'd immediately after it returns. The details differ, but this
  mirrors atomic thread release semantics, at least for the buffers
  synced.
  
  For non-x86 platforms, bus_dmamap_sync() has the right syncing and
  fences. So in the past, wmb() had been omitted for them.
  
  For x86 platforms, the memory ordering is already strong enough to
  ensure DMA to the device sees the current contents. As such, we don't
  need the wmb() here. It translates to an sfence which is only needed
  for writes to regions that have the write combining attribute set or
  when some exotic opcodes are used. The nvme driver does neither of
  these. Since bus_dmamap_sync() includes atomic_thread_fence_rel, we
  can be assured any optimizer won't reorder the bus_dmamap_sync and the
  bus_space_write operations. The wmb() was a vestiage of the pre-busdma
  version initially committed to the tree.
  
  Reviewed by: kib@, gallatin@, chuck@, mav@
  Differential Revision: https://reviews.freebsd.org/D27448

Modified:
  head/sys/dev/nvme/nvme_qpair.c

Modified: head/sys/dev/nvme/nvme_qpair.c
==
--- head/sys/dev/nvme/nvme_qpair.c  Fri Dec  4 21:34:04 2020
(r368351)
+++ head/sys/dev/nvme/nvme_qpair.c  Fri Dec  4 21:34:48 2020
(r368352)
@@ -982,14 +982,6 @@ nvme_qpair_submit_tracker(struct nvme_qpair *qpair, st
 
bus_dmamap_sync(qpair->dma_tag, qpair->queuemem_map,
BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE);
-#if !defined( __powerpc__) && !defined( __aarch64__)  && !defined( __arm__)
-   /*
-* powerpc's bus_dmamap_sync() already includes a heavyweight sync, but
-* no other archs do.
-*/
-   wmb();
-#endif
-
bus_space_write_4(qpair->ctrlr->bus_tag, qpair->ctrlr->bus_handle,
qpair->sq_tdbl_off, qpair->sq_tail);
qpair->num_cmds++;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r368351 - head/sys/x86/x86

2020-12-04 Thread Warner Losh
Author: imp
Date: Fri Dec  4 21:34:04 2020
New Revision: 368351
URL: https://svnweb.freebsd.org/changeset/base/368351

Log:
  busdma: Annotate bus_dmamap_sync() with fence
  
  Add an explicit thread fence release before returning from
  bus_dmamap_sync. This should be a no-op in practice, but makes
  explicit that all ordinary stores will be completed before subsequent
  reads/writes to ordinary device memory. On x86, normal memory ordering
  is strong enough to generally guarantee this. The fence keeps the
  optimizer (likely LTO) from reordering other calls around this.
  The other architectures already have calls, as appropriate, that
  are equivalent.
  
  Note: On x86, there is one exception to this rule. If you've mapped
  memory as write combining, then you will need to add a sfence or
  similar. Normally, though, busdma doesn't operate on such memory, and
  drivers that do already cope appropriately.
  
  Reviewed by: kib@, gallatin@, chuck@, mav@
  Differential Revision: https://reviews.freebsd.org/D27448

Modified:
  head/sys/x86/x86/busdma_bounce.c

Modified: head/sys/x86/x86/busdma_bounce.c
==
--- head/sys/x86/x86/busdma_bounce.cFri Dec  4 21:12:17 2020
(r368350)
+++ head/sys/x86/x86/busdma_bounce.cFri Dec  4 21:34:04 2020
(r368351)
@@ -969,7 +969,7 @@ bounce_bus_dmamap_sync(bus_dma_tag_t dmat, bus_dmamap_
bus_size_t datacount1, datacount2;
 
if (map == NULL || (bpage = STAILQ_FIRST(>bpages)) == NULL)
-   return;
+   goto out;
 
/*
 * Handle data bouncing.  We might also want to add support for
@@ -1059,6 +1059,8 @@ next_r:
}
dmat->bounce_zone->total_bounced++;
}
+out:
+   atomic_thread_fence_rel();
 }
 
 static void
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r368329 - head/stand/kshim

2020-12-04 Thread Warner Losh
On Fri, Dec 4, 2020 at 9:06 AM Hans Petter Selasky  wrote:

> On 12/4/20 4:59 PM, Alexander Richardson wrote:
> > On Fri, 4 Dec 2020 at 14:51, Hans Petter Selasky 
> wrote:
> >>
> >> Author: hselasky
> >> Date: Fri Dec  4 14:50:55 2020
> >> New Revision: 368329
> >> URL: https://svnweb.freebsd.org/changeset/base/368329
> >>
> >> Log:
> >>Fix definition of int64_t and uint64_t when long is 64-bit. This
> gets the kernel
> >>shim code in line with the rest of the kernel,
> sys/x86/include/_types.h.
> >>
> >>MFC after:1 week
> >>Sponsored by: Mellanox Technologies // NVIDIA Networking
> >>
> >> Modified:
> >>head/stand/kshim/bsd_kernel.h
> >>
> >> Modified: head/stand/kshim/bsd_kernel.h
> >>
> ==
> >> --- head/stand/kshim/bsd_kernel.h   Fri Dec  4 14:09:12 2020
> (r368328)
> >> +++ head/stand/kshim/bsd_kernel.h   Fri Dec  4 14:50:55 2020
> (r368329)
> >> @@ -208,9 +208,17 @@ typedef unsigned int uint32_t;
> >>   #define_INT32_T_DECLARED
> >>   typedef signed int int32_t;
> >>   #define_UINT64_T_DECLARED
> >> +#ifndef __LP64__
> >>   typedef unsigned long long uint64_t;
> >> +#else
> >> +typedef unsigned long uint64_t;
> >> +#endif
> >>   #define_INT16_T_DECLARED
> >> +#ifndef __LP64__
> >>   typedef signed long long int64_t;
> >> +#else
> >> +typedef signed long int64_t;
> >> +#endif
> >>
> >>   typedef uint16_t uid_t;
> >>   typedef uint16_t gid_t;
> >
> > Since we no longer support ancient compilers, could we simplify this
> > and just use
> > typedef __UINT64_TYPE__ uint64_t;
> > typedef __INT64_TYPE__ int64_t;
> > ?
> >
> > This will work across all architectures and ABIs, and appears to work
> > starting with GCC 4.5.3 and Clang 3.5:
> > https://godbolt.org/z/TWavfb
>
> Hi Alexander,
>
> I'm not sure how that definition will work together with existing code,
> mixing uint64_t, unsigned long, and unsigned long long. Will this cause
> more compiler warnings? This also will affect user-space and ports.
>

I think for the boot loader context, this suggestion will be completely
fine. Since this file is only used there, it should be identical to your
changes in that context.

Warner


> Maybe Konstantin, CC'ed, has some input on this?
>
> --HPS
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r368279 - head/sys/dev/nvme

2020-12-02 Thread Warner Losh
On Wed, Dec 2, 2020 at 10:48 AM Konstantin Belousov 
wrote:

> On Wed, Dec 02, 2020 at 04:54:24PM +, Michal Meloun wrote:
> > Author: mmel
> > Date: Wed Dec  2 16:54:24 2020
> > New Revision: 368279
> > URL: https://svnweb.freebsd.org/changeset/base/368279
> >
> > Log:
> >   NVME: Multiple busdma related fixes.
> ...
>
> >   - in nvme_qpair_submit_tracker(), don't do explicit wmb() also for arm
> > and arm64. Bus_dmamap_sync() on these architectures is sufficient to
> ensure
> > that all CPU stores are visible to external (including DMA)
> observers.
> > @@ -982,7 +982,7 @@ nvme_qpair_submit_tracker(struct nvme_qpair *qpair,
> st
> >
> >   bus_dmamap_sync(qpair->dma_tag, qpair->queuemem_map,
> >   BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE);
> > -#ifndef __powerpc__
> > +#if !defined( __powerpc__) && !defined( __aarch64__)  && !defined(
> __arm__)
> >   /*
> >* powerpc's bus_dmamap_sync() already includes a heavyweight
> sync, but
> >* no other archs do.
> Does anybody have any evidence that the wmb() below is useful ?
> For instance, on x86, does nvme driver use any write-combining mappings ?
>

It translates to a sfence on x86. It is done just before the write
that moves the tail pointer. sfence ensures that all writes are done before
that write is done. I believe that the nvme spec requires that the entire
submission queue entry be fully filled out before the write to the tailq
pointer moving it.[*]

I'm not enough of an expert on the exact details here to know if it's
absolutely required or not, but given the ordering requirements in the
spec, the intent appears to be related to enforcing that ordering. I don't
know enough to know if it accomplishes this goal or not.

Warner

[*] I know I said in the review it  may be due to getting lower latency to
the device, but I now believe that to be mistaken after studying it further.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r368187 - head/sys/dev/nvme

2020-11-30 Thread Warner Losh
On Mon, Nov 30, 2020 at 9:56 AM Michal Meloun 
wrote:

>
>
> On 30.11.2020 17:02, Ian Lepore wrote:
> > On Mon, 2020-11-30 at 14:51 +, Michal Meloun wrote:
> >> Author: mmel
> >> Date: Mon Nov 30 14:51:48 2020
> >> New Revision: 368187
> >> URL: https://svnweb.freebsd.org/changeset/base/368187
> >>
> >> Log:
> >>Unbreak r368167 in userland. Decorate unused arguments.
> >>
> >>Reported by:  kp, tuexen, jenkins, and many others
> >>MFC with: r368167
> >>
> >> Modified:
> >>head/sys/dev/nvme/nvme.h
> >>
> >> Modified: head/sys/dev/nvme/nvme.h
> >> =
> >> =
> >> --- head/sys/dev/nvme/nvme.h Mon Nov 30 14:49:13 2020(r368186)
> >> +++ head/sys/dev/nvme/nvme.h Mon Nov 30 14:51:48 2020(r368187)
> >> @@ -1728,9 +1728,15 @@ extern int nvme_use_nvd;
> >>
> >>   #endif /* _KERNEL */
> >>
> >> +#if _BYTE_ORDER != _LITTLE_ENDIAN
> >> +#define MODIF
> >> +#else
> >> +#define MODIF __unused
> >> +#endif
> >> +
> >>   /* Endianess conversion functions for NVMe structs */
> >>   static inline
> >> -voidnvme_completion_swapbytes(struct nvme_completion *s)
> >> +voidnvme_completion_swapbytes(struct nvme_completion *s MODIF)
> >
> > IMO, this is pretty ugly, it causes the brain to screech to a halt when
> > you see it.  Why not just add an unconditional __unused to the
> > functions?  The unused attribute is defined as marking the variable as
> > "potentially unused" -- there is no penalty for having it there and
> > then actually using the variable.
> >
>
> I understand, (and I have significant tendency to agree) but I did not
> find more correct way how to do it.
> Are you sure that __unused is defined as *potentially* unused?  I cannot
> find nothing about this and you known how are compiler guys creative
> with generating of new warnings...
> I known that C++17 have 'maybe_unused' attribute, but relationship to
> standard '__unused' looks unclear.
>
> In any case, I have not single problem to change this to the proposed
> style if we found that this is the optimal way.
>

__unused means 'don't warn me if this is unused' elsewhere in the tree.
Better to use it here.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r368045 - in head: . etc/mtree rescue/rescue sbin sbin/ping sbin/ping/tests sbin/ping6 sbin/ping6/tests tools/build/mk

2020-11-26 Thread Warner Losh
On Thu, Nov 26, 2020, 8:37 AM Alan Somers  wrote:

>
>
>
> > >
>> > >  I think you should add a LINKS=... here so people script which uses
>> > > ping6 won't break (and of course adding support in the code to do ipv6
>> > > ping if progname is ping6 if this isn't the case).
>> > >
>> > >  Cheers,
>> > >
>> > > --
>> > > Emmanuel Vadot 
>> > >
>> >
>> > Yes, that would make sense.  But for how long?  Would the ping6 hard
>> link
>> > stick around forever, or eventually be removed in some future version of
>> > FreeBSD?
>>
>>  I have no opinion on this matter.
>>  But since ping6 was present for a very long time I guess we're stuck
>> with it for a long time too.
>>
>
> Do you have an opinion on whether there should be a /rescue/ping6 link
> too?
>

Yes. It should, imho.

Warner

>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r367963 - head/sbin/devd

2020-11-23 Thread Warner Losh
Author: imp
Date: Mon Nov 23 18:37:19 2020
New Revision: 367963
URL: https://svnweb.freebsd.org/changeset/base/367963

Log:
  Prefer Em to Ar for emphasis
  
  Em is better than Ar if all we want to do is underline the text.
  
  Submitted by: yuripv@

Modified:
  head/sbin/devd/devd.conf.5

Modified: head/sbin/devd/devd.conf.5
==
--- head/sbin/devd/devd.conf.5  Mon Nov 23 18:27:21 2020(r367962)
+++ head/sbin/devd/devd.conf.5  Mon Nov 23 18:37:19 2020(r367963)
@@ -416,7 +416,7 @@ node is destroyed.
 .Sy "System" Ta Sy "Subsystem" Ta Sy "Type" Ta Sy "Description"
 .It Li ETHERNET Ta Ar inet Ta IFATTACH Ta
 Notification when the default VNET instance of the
-.Ar inet
+.Em inet
 interface is attached.
 .El
 .Pp
@@ -454,18 +454,18 @@ provider size has changed.
 .Bl -column "System" "Subsystem" "1234567" -compact
 .Sy "System" Ta Sy "Subsystem" Ta Sy "Type" Ta Sy "Description"
 .It Li IFNET
-.It Li IFNET Ta Ar inet Ta Ta
+.It Li IFNET Ta Em inet Ta Ta
 The
 .Dq subsystem
 is the actual name of the network interface on which the event
 took place.
-.It Li IFNET Ta Ar inet Ta Li LINK_UP Ta
+.It Li IFNET Ta Em inet Ta Li LINK_UP Ta
 Carrier status changed to UP.
-.It Li IFNET Ta Ar inet Ta Li LINK_DOWN Ta
+.It Li IFNET Ta Em inet Ta Li LINK_DOWN Ta
 Carrier status changed to DOWN.
-.It Li IFNET Ta Ar inet Ta Li ATTACH Ta
+.It Li IFNET Ta Em inet Ta Li ATTACH Ta
 The network interface is attached to the system.
-.It Li IFNET Ta Ar inet Ta Li DETACH Ta
+.It Li IFNET Ta Em inet Ta Li DETACH Ta
 The network interface is detached from the system.
 .El
 .Pp
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r367847 - head/share/man/man4

2020-11-19 Thread Warner Losh
Author: imp
Date: Thu Nov 19 17:54:41 2020
New Revision: 367847
URL: https://svnweb.freebsd.org/changeset/base/367847

Log:
  Document disk ioctl
  
  First stab at documenting the different disk ioctl commands defined in
  sys/disk.h.
  
  Reviewed by: phk (prior version)
  Differential Revision: https://reviews.freebsd.org/D26994

Added:
  head/share/man/man4/disk.4   (contents, props changed)
Modified:
  head/share/man/man4/Makefile

Modified: head/share/man/man4/Makefile
==
--- head/share/man/man4/MakefileThu Nov 19 16:57:45 2020
(r367846)
+++ head/share/man/man4/MakefileThu Nov 19 17:54:41 2020
(r367847)
@@ -130,6 +130,7 @@ MAN=aac.4 \
ddb.4 \
devctl.4 \
disc.4 \
+   disk.4 \
divert.4 \
${_dpms.4} \
ds1307.4 \

Added: head/share/man/man4/disk.4
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/share/man/man4/disk.4  Thu Nov 19 17:54:41 2020(r367847)
@@ -0,0 +1,210 @@
+.\" Copyright (c) 2020 M. Warner Losh 
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\"notice, this list of conditions and the following disclaimer.
+.\"
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\"notice, this list of conditions and the following disclaimer in the
+.\"documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\" $FreeBSD$
+.\"
+.Dd November 20, 2020
+.Dt disk 4
+.Os
+.Sh NAME
+.Nm disk
+.Nd common disk interfaces
+.Sh SYNOPSIS
+.Cd device cd
+.Sh DESCRIPTION
+Common block device IOCTLs
+.Pp
+All the block devices in the system should support these disk
+.Xr ioctl 2
+commands defined here.
+Much of this information is also available via the
+.Xr geom 2
+attributes.
+.Sh IOCTLS
+The following
+.Xr ioctl 2
+calls apply to disk drives, and are defined
+in the
+.In sys/disk.h
+header file.
+.Bl -tag -width DIOCGPROVIDERNAME
+.It Dv DIOCGSECTORSIZE
+.Pq Li "u_int"
+Get the sector or block size of the device in bytes.
+The sector size is the smallest unit of data which can be transferred
+from this device.
+This is usually a power of 2 but it might not be (e.g. CDROM audio).
+Operations to block devices such as
+.Xr lseek 2 ,
+.Xr read 2 ,
+and
+.Xr write
+may only be performed at file offsets that are integral multiple of
+this size.
+.It Dv DIOCGMEDIASIZE
+.Pq Li "off_t"
+Get the size of the entire device in bytes.
+This should be a multiple of the sector size.
+.It Dv DIOCGFWSECTORS
+.Pq Li "u_int"
+Return the firmware's notion of number of sectors per track.
+This value is mostly used for compatibility with various ill designed
+disk label formats.
+Use this value only when absolutely required.
+Its interpretation and use is largely obsolete.
+.It Dv DIOCGFWHEADS
+.Pq Li "u_int"
+Return the firmware's notion of number of heads per cylinder.
+This value is mostly used for compatibility with various ill designed
+disk label formats.
+Use this value only when absolutely required.
+Its interpretation and use is largely obsolete.
+.It Dv DIOCGFLUSH
+Flush write cache of the device.
+.It Dv DIOCGDELETE
+.Pq Li "off_t[2]"
+Mark data on the device as unused.
+The first element is the offset to start deleting.
+The second element is the length to delete.
+Providers may use this information to free storage or instruct storage
+devices the contents can be discarded.
+.It Dv DIOCGIDENT
+.Pq Li "char[DISK_IDENT_SIZE]"
+Get the ident for this provider.
+Ident is a unique and fixed identifier for this provider.
+Ident's properties are as follow:
+.Bl -bullet
+.It
+preserved between reboots,
+.It
+preserved across a provider being det

svn commit: r367810 - head/usr.sbin/mergemaster

2020-11-18 Thread Warner Losh
Author: imp
Date: Wed Nov 18 19:22:24 2020
New Revision: 367810
URL: https://svnweb.freebsd.org/changeset/base/367810

Log:
  mergemaster: handle symbolic links during update.
  
  /etc/os-release is now a symbolic link to a generated file. Make
  mergemaster cope with symbolic links generically. I'm no longer
  a big mergemaster user, so this has only been lightly tested
  by me, though Kimura-san has ran it through its paces.
  
  Submitted by: Yasushiro KIMURA-san
  PR: 242212
  MFC After: 2 weeks

Modified:
  head/usr.sbin/mergemaster/mergemaster.sh

Modified: head/usr.sbin/mergemaster/mergemaster.sh
==
--- head/usr.sbin/mergemaster/mergemaster.shWed Nov 18 18:40:58 2020
(r367809)
+++ head/usr.sbin/mergemaster/mergemaster.shWed Nov 18 19:22:24 2020
(r367810)
@@ -1093,6 +1093,7 @@ for COMPFILE in `find . | sort` ; do
   fi
 done
 
+# Compare regular files
 for COMPFILE in `find . -type f | sort`; do
 
   # First, check to see if the file exists in DESTDIR.  If not, the
@@ -1182,6 +1183,119 @@ for COMPFILE in `find . -type f | sort`; do
   fi # Yes, the file still remains to be checked
 done # This is for the for way up there at the beginning of the comparison
 
+ask_answer_for_symbolic_link () {
+  HANDLE_COMPSYMLINK=''
+  while true; do
+echo "  Use 'd' to delete the temporary ${COMPSYMLINK}"
+echo "  Use 'i' to install the temporary ${COMPSYMLINK}"
+echo ''
+echo "  Default is to leave the temporary symbolic link to deal with by 
hand"
+echo ''
+echo -n "How should I deal with this? [Leave it for later] "
+read HANDLE_COMPSYMLINK
+case ${HANDLE_COMPSYMLINK} in
+  ''|[dDiI])
+break
+;;
+  *)
+echo "invalid choice: ${HANDLE_COMPSYMLINK}"
+echo ''
+HANDLE_COMPSYMLINK=''
+;;
+esac
+  done
+}
+
+install_symbolic_link () {
+  rm -f ${DESTDIR}${COMPSYMLINK#.} > /dev/null 2>&1
+  if [ -L ${DESTDIR}${COMPSYMLINK#.} ]; then
+return 1
+  fi
+  cp -a ${COMPSYMLINK} ${DESTDIR}${COMPSYMLINK#.} > /dev/null 2>&1
+  if [ ! -L ${DESTDIR}${COMPSYMLINK#.} ]; then
+return 1
+  fi
+  return 0
+}
+
+handle_symbolic_link () {
+  case ${HANDLE_COMPSYMLINK} in
+[dD])
+  rm ${COMPSYMLINK}
+  echo ''
+  echo "   *** Deleting ${COMPSYMLINK}"
+  echo ''
+  return 1
+  ;;
+[iI])
+  echo ''
+  if install_symbolic_link; then
+rm ${COMPSYMLINK}
+echo "   *** ${COMPSYMLINK} installed successfully"
+return 2
+  else
+echo "   *** Problem installing ${COMPSYMLINK}, it will remain to 
merge by hand"
+return 3
+  fi
+  echo ''
+  ;;
+'')
+  echo ''
+  echo "   *** ${COMPSYMLINK} will remain for your consideration"
+  echo ''
+  return 0
+  ;;
+  esac
+}
+
+# Compare symblic links
+for COMPSYMLINK in `find . -type l | sort`; do
+  if [ ! -L "${DESTDIR}${COMPSYMLINK#.}" ]; then
+if [ -n "${AUTO_RUN}" -a -z "${AUTO_INSTALL}" ]; then
+  echo "   *** ${COMPSYMLINK} will remain for your consideration"
+  continue
+else
+  echo ''
+  echo "  *** There is no installed version of ${COMPSYMLINK}"
+  echo ''
+  if [ -n "${AUTO_INSTALL}" ]; then
+HANDLE_COMPSYMLINK="i"
+  else
+ask_answer_for_symbolic_link
+  fi
+  handle_symbolic_link
+  if [ -n "${AUTO_INSTALL}" -a $? -eq 2 ]; then
+AUTO_INSTALLED_FILES="${AUTO_INSTALLED_FILES}  
${DESTDIR}${COMPSYMLINK#.}
+"
+  fi
+fi
+  elif [ $(readlink ${COMPSYMLINK}) = $(readlink ${DESTDIR}${COMPSYMLINK#.}) 
]; then
+echo " *** Temp ${COMPSYMLINK} and installed are the same, deleting"
+rm ${COMPSYMLINK}
+  else
+if [ -n "${AUTO_RUN}" -a -z "${AUTO_UPGRADE}" ]; then
+  echo "   *** ${COMPSYMLINK} will remain for your consideration"
+  continue
+else
+  echo ''
+  echo " *** Target of temp symbolic link is differnt from that of 
installed one"
+  echo " Temp (${COMPSYMLINK}): $(readlink ${COMPSYMLINK})"
+  echo " Installed (${DESTDIR}${COMPSYMLINK#.})): $(readlink 
${DESTDIR}${COMPSYMLINK#.})"
+  echo ''
+  if [ -n "${AUTO_UPGRADE}" ]; then
+HANDLE_COMPSYMLINK="i"
+  else
+ask_answer_for_symbolic_link
+  fi
+  handle_symbolic_link
+  if [ -n "${AUTO_UPGRADE}" -a $? -eq 2 ]; then
+AUTO_UPGRADED_FILES="${AUTO_UPGRADED_FILES}  
${DESTDIR}${COMPSYMLINK#.}
+"
+  fi
+fi
+  fi
+done
+
 echo ''
 echo "*** Comparison complete"
 
@@ -1193,10 +1307,10 @@ fi
 
 echo ''
 
-TEST_FOR_FILES=`find ${TEMPROOT} -type f -size +0 2>/dev/null`
+TEST_FOR_FILES=`find ${TEMPROOT} -type f -size +0 -or -type l 2>/dev/null`
 if [ -n "${TEST_FOR_FILES}" ]; then
   echo "*** Files that remain for you to merge by hand:"
-  find "${TEMPROOT}" -type f -size +0 | sort
+  find "${TEMPROOT}" -type f -size +0 -or -type l | sort
   echo ''
 
   

Re: svn commit: r367692 - head/sys/sys

2020-11-17 Thread Warner Losh
On Tue, Nov 17, 2020 at 3:18 PM John Baldwin  wrote:

> On 11/14/20 2:34 PM, Warner Losh wrote:
> > true, but a version bump forces that and versions are cheap enough...
>
> Strictly speaking, version bumps don't force anything to recompile, they
> just ensure that newer modules won't load on older kernels.  In this case,
> the change to sys/ucred.h will result in sys/ucred.h's mtime changing so
> that any kernel modules being built via NO_CLEAN=yes will rebuild ok.
>
> I'm not quite sure where this mantra that version bumps force rebuilds
> came from, but they don't.  It's true that since it lives in 
> and most things include that, it mostly forces a rebuild, but that's
> mostly a side effect, not due to explicit magic around __FreeBSD_version.
>

It's more that modules stop loading when there's a version bump. This is
both good and bad. It's good when there's a legit, KBI change that's likely
to affect modules. This one seems on the edge. ZFS is affected, but most
drivers are not.

It's bad when there's not really a problem since the last bump and you have
to rebuild your kernel + modules to be a matched set. For production, you
always want this, but sometimes you want to be able to run slightly newer
modules than the kernel and that's oftentimes OK because some bumps don't
affect KBI.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r367701 - head/lib/libutil

2020-11-15 Thread Warner Losh
On Sun, Nov 15, 2020 at 1:13 PM Scott Long  wrote:

>
> > On Nov 15, 2020, at 1:05 PM, Warner Losh  wrote:
> >
> > Hey Scott,
> >
> > On Sun, Nov 15, 2020 at 11:46 AM Scott Long  wrote:
> > The man page for strlcpy() made reference to the return value being
> > equivalent to what snprintf() does.  The man page for snprintf() states
> > that negatve return values are possible, so I assumed the same was
> > true for strlcpy().  However, now that I’ve looked at the implementation
> > of strlcpy(), I see that you’re correct.  The man pages are definitely
> > confusing, and this isn’t the only place where I think there’s
> > inconsistency in the documentation, or at least poor wording choices.
> >
> > Yea, it says both that it will never return a negative value (since
> size_t is never negative) and that it returns the same things as snprintf
> (which is true... except for that detail which it glosses over in return
> type differences).
> >
> > So this issue doesn't get lost, I've added a clarification to the
> examples in  https://reviews.freebsd.org/D27228 . Please take a look and
> let me know what you think. If more extensive edits are needed, there's
> full context so you can at least flag those in the review as well. I've
> read these too many times to see the other places you're talking about, so
> a fresh set of eyes would be helpful.
> >
>
> The wording on whether or not strlcpy and strlcat will provide NULL
> termination is also inconsistent, hence my comments about it last weekend.
> I’m going to revert all of this back to and including r367075, since Stefan
> wants to do this a totally different way.  Sorry for the noise everyone and
> thanks for the help, I learned a lot through this process.
>

OK.  I'll update the man page to document the guaranteed behavior wrt NUL
as well. I know what it's trying to say, but you are not the first person
to stumble on these details. Thanks for pointing me at the ones that need
improvement. And thanks for getting the localbase issue seen through.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r367701 - head/lib/libutil

2020-11-15 Thread Warner Losh
Hey Scott,

On Sun, Nov 15, 2020 at 11:46 AM Scott Long  wrote:

> The man page for strlcpy() made reference to the return value being
> equivalent to what snprintf() does.  The man page for snprintf() states
> that negatve return values are possible, so I assumed the same was
> true for strlcpy().  However, now that I’ve looked at the implementation
> of strlcpy(), I see that you’re correct.  The man pages are definitely
> confusing, and this isn’t the only place where I think there’s
> inconsistency in the documentation, or at least poor wording choices.


Yea, it says both that it will never return a negative value (since size_t
is never negative) and that it returns the same things as snprintf (which
is true... except for that detail which it glosses over in return type
differences).

So this issue doesn't get lost, I've added a clarification to the examples
in  https://reviews.freebsd.org/D27228 . Please take a look and let me know
what you think. If more extensive edits are needed, there's full context so
you can at least flag those in the review as well. I've read these too many
times to see the other places you're talking about, so a fresh set of eyes
would be helpful.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r367692 - head/sys/sys

2020-11-14 Thread Warner Losh
true, but a version bump forces that and versions are cheap enough...

Warner

On Sat, Nov 14, 2020 at 1:58 PM Mateusz Guzik  wrote:

> you are expected to recompile all your kernel modules every time you
> update head
>
> On 11/14/20, Shawn Webb  wrote:
> > Are there any kernel modules (in base, in ports, or out-of-both-trees)
> > that access struct ucred?
> >
> > On Sat, Nov 14, 2020 at 09:51:47PM +0100, Mateusz Guzik wrote:
> >> I don't think so, it does not change any APIs
> >>
> >> On 11/14/20, Shawn Webb  wrote:
> >> > On Sat, Nov 14, 2020 at 07:20:37PM +, Mateusz Guzik wrote:
> >> >> Author: mjg
> >> >> Date: Sat Nov 14 19:20:37 2020
> >> >> New Revision: 367692
> >> >> URL: https://svnweb.freebsd.org/changeset/base/367692
> >> >>
> >> >> Log:
> >> >>   cred: reorder cr_audit to be closer to the lock
> >> >>
> >> >>   This makes cr_uid avoid sharing.
> >> >>
> >> >> Modified:
> >> >>   head/sys/sys/ucred.h
> >> >>
> >> >> Modified: head/sys/sys/ucred.h
> >> >>
> ==
> >> >> --- head/sys/sys/ucred.h  Sat Nov 14 19:19:27 2020(r367691)
> >> >> +++ head/sys/sys/ucred.h  Sat Nov 14 19:20:37 2020(r367692)
> >> >> @@ -63,6 +63,7 @@ struct ucred {
> >> >>   struct mtx cr_mtx;
> >> >>   u_int   cr_ref; /* (c) reference count */
> >> >>   u_int   cr_users;   /* (c) proc + thread using this
> cred */
> >> >> + struct auditinfo_addr   cr_audit;   /* Audit properties. */
> >> >>  #define  cr_startcopy cr_uid
> >> >>   uid_t   cr_uid; /* effective user id */
> >> >>   uid_t   cr_ruid;/* real user id */
> >> >> @@ -78,7 +79,6 @@ struct ucred {
> >> >>   void*cr_pspare2[2]; /* general use 2 */
> >> >>  #define  cr_endcopy  cr_label
> >> >>   struct label*cr_label;  /* MAC label */
> >> >> - struct auditinfo_addr   cr_audit;   /* Audit properties. */
> >> >>   gid_t   *cr_groups; /* groups */
> >> >>   int cr_agroups; /* Available groups */
> >> >>   gid_t   cr_smallgroups[XU_NGROUPS]; /* storage for small
> groups */
> >> >
> >> > Hey Mateusz,
> >> >
> >> > Since this changes KBI, does __FreeBSD_version need bumping?
> >> >
> >> > Thanks,
> >> >
> >> > --
> >> > Shawn Webb
> >> > Cofounder / Security Engineer
> >> > HardenedBSD
> >> >
> >> > GPG Key ID:  0xFF2E67A277F8E1FA
> >> > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23
> 0FB2
> >> >
> https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
> >> >
> >>
> >>
> >> --
> >> Mateusz Guzik 
> >
> > --
> > Shawn Webb
> > Cofounder / Security Engineer
> > HardenedBSD
> >
> > GPG Key ID:  0xFF2E67A277F8E1FA
> > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
> >
> https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
> >
>
>
> --
> Mateusz Guzik 
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r367581 - head/sys/conf

2020-11-10 Thread Warner Losh
Author: imp
Date: Tue Nov 10 23:25:16 2020
New Revision: 367581
URL: https://svnweb.freebsd.org/changeset/base/367581

Log:
  Add INIT_ALL_ZERO and INIT_ALL_PATTERN to kern.opts.mk
  
  These options need to be in the kern.opts.mk file to be alive for kernel
  and module builds. This also reverts r367579 since that's not needed with
  this fix: the host's bsd.opts.mk is irrelevant.
  
  Reviewed by: brooks@
  Differential Revision:  https://reviews.freebsd.org/D27170

Modified:
  head/sys/conf/kern.mk
  head/sys/conf/kern.opts.mk

Modified: head/sys/conf/kern.mk
==
--- head/sys/conf/kern.mk   Tue Nov 10 21:29:10 2020(r367580)
+++ head/sys/conf/kern.mk   Tue Nov 10 23:25:16 2020(r367581)
@@ -230,15 +230,15 @@ CFLAGS+=  -mretpoline
 #
 # Initialize stack variables on function entry
 #
-.if defined(MK_INIT_ALL_ZERO) && ${MK_INIT_ALL_ZERO} == "yes"
-.if defined(COMPILER_FEATURES) && ${COMPILER_FEATURES:Minit-all}
+.if ${MK_INIT_ALL_ZERO} == "yes"
+.if ${COMPILER_FEATURES:Minit-all}
 CFLAGS+= -ftrivial-auto-var-init=zero \
 -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
 .else
 .warning InitAll (zeros) requested but not support by compiler
 .endif
-.elif defined(MK_INIT_ALL_PATTERN) && ${MK_INIT_ALL_PATTERN} == "yes"
-.if defined(COMPILER_FEATURES) && ${COMPILER_FEATURES:Minit-all}
+.elif ${MK_INIT_ALL_PATTERN} == "yes"
+.if ${COMPILER_FEATURES:Minit-all}
 CFLAGS+= -ftrivial-auto-var-init=pattern
 .else
 .warning InitAll (pattern) requested but not support by compiler

Modified: head/sys/conf/kern.opts.mk
==
--- head/sys/conf/kern.opts.mk  Tue Nov 10 21:29:10 2020(r367580)
+++ head/sys/conf/kern.opts.mk  Tue Nov 10 23:25:16 2020(r367581)
@@ -52,6 +52,8 @@ __DEFAULT_YES_OPTIONS = \
 __DEFAULT_NO_OPTIONS = \
 BHYVE_SNAPSHOT \
 EXTRA_TCP_STACKS \
+INIT_ALL_PATTERN \
+INIT_ALL_ZERO \
 KERNEL_RETPOLINE \
 OFED \
 RATELIMIT \
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r367514 - head/sys/dev/bxe

2020-11-08 Thread Warner Losh
Author: imp
Date: Mon Nov  9 03:02:34 2020
New Revision: 367514
URL: https://svnweb.freebsd.org/changeset/base/367514

Log:
  Remove newline from bxe description, it's not done elsewhere.

Modified:
  head/sys/dev/bxe/bxe.c

Modified: head/sys/dev/bxe/bxe.c
==
--- head/sys/dev/bxe/bxe.c  Mon Nov  9 01:57:07 2020(r367513)
+++ head/sys/dev/bxe/bxe.c  Mon Nov  9 03:02:34 2020(r367514)
@@ -2520,7 +2520,7 @@ bxe_probe(device_t dev)
 
 /* Print out the device identity. */
 snprintf(descbuf, BXE_DEVDESC_MAX,
- "%s (%c%d) BXE v:%s\n", t->bxe_name,
+ "%s (%c%d) BXE v:%s", t->bxe_name,
  (((pci_read_config(dev, PCIR_REVID, 4) &
 0xf0) >> 4) + 'A'),
  (pci_read_config(dev, PCIR_REVID, 4) & 0xf),
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r367475 - head

2020-11-07 Thread Warner Losh
Author: imp
Date: Sun Nov  8 02:46:04 2020
New Revision: 367475
URL: https://svnweb.freebsd.org/changeset/base/367475

Log:
  Also mention PORTS_MODULES
  
  PORTS_MODULES is also an effective way to update the tree. Also
  a minor rejustify on this an an adjacent paragraph.
  
  Suggested by: David Wolfskill

Modified:
  head/UPDATING

Modified: head/UPDATING
==
--- head/UPDATING   Sun Nov  8 02:20:21 2020(r367474)
+++ head/UPDATING   Sun Nov  8 02:46:04 2020(r367475)
@@ -2303,14 +2303,16 @@ COMMON ITEMS:
messages there.  If in doubt, please track -stable which has
much fewer pitfalls.
 
-   [1] If you have third party modules, such as vmware, you
-   should disable them at this point so they don't crash your
-   system on reboot. Alternatively, you should rebuild all the
-   modules you have in your system and install them as well.  If
-   you are running -current, you should seriously consider
-   placing all sources to all the modules for your system (or
-   symlinks to them) in /usr/local/sys/modules so this happens
-   automatically...
+   [1] If you have third party modules, such as vmware, you should disable
+   them at this point so they don't crash your system on
+   reboot. Alternatively, you should rebuild all the modules you have in
+   your system and install them as well.  If you are running -current, you
+   should seriously consider placing all sources to all the modules for
+   your system (or symlinks to them) in /usr/local/sys/modules so this
+   happens automatically. If all your modules come from ports, then adding
+   the port origin directories to PORTS_MODULES instead is also automatic
+   and effective, eg:
+PORTS_MODULES+=x11/nvidia-driver
 
[3] From the bootblocks, boot -s, and then do
fsck -p
@@ -2319,8 +2321,8 @@ COMMON ITEMS:
sh /etc/rc.d/zfs start  # mount zfs filesystem, if needed
cd src  # full path to source
adjkerntz -i# if CMOS is wall time
-   Also, when doing a major release upgrade, it is required that
-   you boot into single user mode to do the installworld.
+   Also, when doing a major release upgrade, it is required that you boot
+   into single user mode to do the installworld.
 
[4] Note: This step is non-optional.  Failure to do this step
can result in a significant reduction in the functionality of the
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r367474 - head

2020-11-07 Thread Warner Losh
Author: imp
Date: Sun Nov  8 02:20:21 2020
New Revision: 367474
URL: https://svnweb.freebsd.org/changeset/base/367474

Log:
  Be explicit about recompiling all the modules...
  
  Add a note about always recompiling all modules on every new kernel
  change / update. In addition, suggest using /usr/local/sys/modules
  so this happens automatically.

Modified:
  head/UPDATING

Modified: head/UPDATING
==
--- head/UPDATING   Sun Nov  8 01:02:40 2020(r367473)
+++ head/UPDATING   Sun Nov  8 02:20:21 2020(r367474)
@@ -2305,7 +2305,12 @@ COMMON ITEMS:
 
[1] If you have third party modules, such as vmware, you
should disable them at this point so they don't crash your
-   system on reboot.
+   system on reboot. Alternatively, you should rebuild all the
+   modules you have in your system and install them as well.  If
+   you are running -current, you should seriously consider
+   placing all sources to all the modules for your system (or
+   symlinks to them) in /usr/local/sys/modules so this happens
+   automatically...
 
[3] From the bootblocks, boot -s, and then do
fsck -p
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r367229 - in head/sys/contrib/openzfs: include/sys/zstd module/zstd

2020-10-31 Thread Warner Losh
Go for it.

Warner


On Sat, Oct 31, 2020, 2:57 PM Mateusz Guzik  wrote:

> I agree. Please commit.
>
> On 10/31/20, Brandon Bergren  wrote:
> > Yeah, that is what was happening. The minimal implementation needed for
> > libsa was missing.
> >
> > On Sat, Oct 31, 2020, at 3:33 PM, Brandon Bergren wrote:
> >> Maybe this is it?:
> >>
> >> Index: sys/contrib/openzfs/include/os/freebsd/spl/sys/atomic.h
> >> ===
> >> --- sys/contrib/openzfs/include/os/freebsd/spl/sys/atomic.h  (revision
> >> 367230)
> >> +++ sys/contrib/openzfs/include/os/freebsd/spl/sys/atomic.h  (working
> >> copy)
> >> @@ -188,6 +188,8 @@
> >>   */
> >>  #undef atomic_add_64
> >>  #define atomic_add_64(ptr, val) *(ptr) += val
> >> +#undef atomic_sub_64
> >> +#define atomic_sub_64(ptr, val) *(ptr) -= val
> >>  #endif /* !_STANDALONE */
> >>
> >>  #endif  /* !_OPENSOLARIS_SYS_ATOMIC_H_ */
> >>
> >>
> >> Note that there is also another build failure in the tree at the moment.
> >>
> >> On Sat, Oct 31, 2020, at 3:25 PM, Brandon Bergren wrote:
> >> > Actually, looking at it again, it looks like the spl header is doing
> it
> >> >
> >> > wrong and not providing a fallback for atomic_sub_64, it's just
> >> > defining it to atomic_subtract_64 and assuming that exists.
> >> >
> >> > On Sat, Oct 31, 2020, at 3:23 PM, Mateusz Guzik wrote:
> >> > > Yep, jenkins told me. Working on it.
> >> > >
> >> > > On 10/31/20, Brandon Bergren  wrote:
> >> > > > This doesn't compile on platforms such as powerpc without pulling
> in
> >> > > > the
> >> > > > opensolaris atomics header from the spl that does locking
> emulation
> >> > > > of 64
> >> > > > bit atomics, as platforms that don't have native 64 bit atomics do
> >> > > > not
> >> > > > provide them in the system header.
> >> >
> >>
> >> --
> >>   Brandon Bergren
> >>   bdra...@imap.cc
> >>
> >
> > --
> >   Brandon Bergren
> >   bdra...@freebsd.org
> >
>
>
> --
> Mateusz Guzik 
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r367189 - head/sys/sys

2020-10-30 Thread Warner Losh
Author: imp
Date: Fri Oct 30 22:00:35 2020
New Revision: 367189
URL: https://svnweb.freebsd.org/changeset/base/367189

Log:
  Integrate 4.4BSD-Lite2 changes to IOC_* definitions
  
  Bring in the long-overdue 4.4BSD-Lite2 rev 8.3 by cgd of
  sys/ioccom.h. This uses UL suffix for the IOC_* constants so they
  don't sign extend. Also bring in the handy diagram from NetBSD's
  version of this file. This alters the 4.4BSD-Lite2 code slightly
  in a way that's semantically the same but more compact.
  
  This should stop the warnings from Chrome for bogus sign extension.
  
  Reviewed by: kib@, jhb@
  Differential Revision: https://reviews.freebsd.org/D26423

Modified:
  head/sys/sys/ioccom.h

Modified: head/sys/sys/ioccom.h
==
--- head/sys/sys/ioccom.h   Fri Oct 30 21:13:05 2020(r367188)
+++ head/sys/sys/ioccom.h   Fri Oct 30 22:00:35 2020(r367189)
@@ -28,7 +28,7 @@
  * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  * SUCH DAMAGE.
  *
- * @(#)ioccom.h8.2 (Berkeley) 3/28/94
+ * @(#)ioccom.h8.3 (Berkeley) 1/9/95
  * $FreeBSD$
  */
 
@@ -39,6 +39,11 @@
  * Ioctl's have the command encoded in the lower word, and the size of
  * any in or out parameters in the upper word.  The high 3 bits of the
  * upper word are used to encode the in/out status of the parameter.
+ *
+ *  31 29 28 16 158 7 0
+ * +---+
+ * | I/O | Parameter Length| Command Group | Command   |
+ * +---+
  */
 #defineIOCPARM_SHIFT   13  /* number of bits for ioctl 
size */
 #defineIOCPARM_MASK((1 << IOCPARM_SHIFT) - 1) /* parameter length 
mask */
@@ -47,11 +52,12 @@
 #defineIOCGROUP(x) (((x) >> 8) & 0xff)
 
 #defineIOCPARM_MAX (1 << IOCPARM_SHIFT) /* max size of ioctl */
-#defineIOC_VOID0x2000  /* no parameters */
-#defineIOC_OUT 0x4000  /* copy out parameters */
-#defineIOC_IN  0x8000  /* copy in parameters */
-#defineIOC_INOUT   (IOC_IN|IOC_OUT)
-#defineIOC_DIRMASK (IOC_VOID|IOC_OUT|IOC_IN)
+
+#defineIOC_VOID0x2000UL/* no parameters */
+#defineIOC_OUT 0x4000UL/* copy out parameters */
+#defineIOC_IN  0x8000UL/* copy in parameters */
+#defineIOC_INOUT   (IOC_IN|IOC_OUT)/* copy parameters in and out */
+#defineIOC_DIRMASK (IOC_VOID|IOC_OUT|IOC_IN)/* mask for 
IN/OUT/VOID */
 
 #define_IOC(inout,group,num,len)   ((unsigned long) \
((inout) | (((len) & IOCPARM_MASK) << 16) | ((group) << 8) | (num)))
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r367119 - head/stand/libsa/zfs

2020-10-28 Thread Warner Losh
This looks like it is missing something, but it isn't.

I should have updated the commit message to say that it's just the makefile
part of this since these commits were in upstream when it was last brought
in.

So it looks like things are missing but they are already in the tree...

Warner

On Wed, Oct 28, 2020 at 3:18 PM Warner Losh  wrote:

> Author: imp
> Date: Wed Oct 28 21:18:04 2020
> New Revision: 367119
> URL: https://svnweb.freebsd.org/changeset/base/367119
>
> Log:
>   loader: add aarch64 support for zstd
>
>   We don't have NEON available in the boot loader, so we have to disable
>   it. OpenZFS included ZSTD which used the wrong symbol to bring in neon
>   support. Change to use the code that's been submitted upstream as a
>   pull request to both.
>
>   __ARM_NEON is the proper symbol, defined in ARM C Language Extensions
>   Release 2.1 (https://developer.arm.com/documentation/ihi0053/d/). Some
>   sources suggest __ARM_NEON__, but that's the obsolete spelling from
>   prior versions of the standard.
>
>   OpenZFS Pull Request: https://github.com/openzfs/zfs/pull/11055
>   ZSTD Pull Request: https://github.com/facebook/zstd/pull/2356
>
> Modified:
>   head/stand/libsa/zfs/Makefile.inc
>
> Modified: head/stand/libsa/zfs/Makefile.inc
>
> ==
> --- head/stand/libsa/zfs/Makefile.inc   Wed Oct 28 21:09:56 2020
> (r367118)
> +++ head/stand/libsa/zfs/Makefile.inc   Wed Oct 28 21:18:04 2020
> (r367119)
> @@ -5,10 +5,8 @@
>  .PATH: ${ZFSOSSRC}/spl
>  .PATH: ${OZFS}/module/zstd/lib
>  ZFSSRC=zfs.c nvlist.c skein.c skein_block.c list.c
> -.if ${MACHINE_ARCH} != aarch64
>  ZFSSRC+=   zstd_shim.c zstd.c
>  CFLAGS+=   -DHAS_ZSTD_ZFS
> -.endif
>  SRCS+= ${ZFSSRC}
>
>  CFLAGS+=   -I${LDRSRC}
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r367119 - head/stand/libsa/zfs

2020-10-28 Thread Warner Losh
Author: imp
Date: Wed Oct 28 21:18:04 2020
New Revision: 367119
URL: https://svnweb.freebsd.org/changeset/base/367119

Log:
  loader: add aarch64 support for zstd
  
  We don't have NEON available in the boot loader, so we have to disable
  it. OpenZFS included ZSTD which used the wrong symbol to bring in neon
  support. Change to use the code that's been submitted upstream as a
  pull request to both.
  
  __ARM_NEON is the proper symbol, defined in ARM C Language Extensions
  Release 2.1 (https://developer.arm.com/documentation/ihi0053/d/). Some
  sources suggest __ARM_NEON__, but that's the obsolete spelling from
  prior versions of the standard.
  
  OpenZFS Pull Request: https://github.com/openzfs/zfs/pull/11055
  ZSTD Pull Request: https://github.com/facebook/zstd/pull/2356

Modified:
  head/stand/libsa/zfs/Makefile.inc

Modified: head/stand/libsa/zfs/Makefile.inc
==
--- head/stand/libsa/zfs/Makefile.inc   Wed Oct 28 21:09:56 2020
(r367118)
+++ head/stand/libsa/zfs/Makefile.inc   Wed Oct 28 21:18:04 2020
(r367119)
@@ -5,10 +5,8 @@
 .PATH: ${ZFSOSSRC}/spl
 .PATH: ${OZFS}/module/zstd/lib
 ZFSSRC=zfs.c nvlist.c skein.c skein_block.c list.c
-.if ${MACHINE_ARCH} != aarch64
 ZFSSRC+=   zstd_shim.c zstd.c
 CFLAGS+=   -DHAS_ZSTD_ZFS
-.endif
 SRCS+= ${ZFSSRC}
 
 CFLAGS+=   -I${LDRSRC}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r367118 - head/share/man/man9

2020-10-28 Thread Warner Losh
Author: imp
Date: Wed Oct 28 21:09:56 2020
New Revision: 367118
URL: https://svnweb.freebsd.org/changeset/base/367118

Log:
  Note that sys/systm.h is special too
  
  If you need / want to includerd sys/systm.h, it has to be just after
  param.h/types.h. Document this existing practice. Not all kernel files
  include systm.h, but when you do, it should be done out of order.
  
  Reviewed by: vangyzen, kib, emaste
  Differential Review: https://reviews.freebsd.org/D26981

Modified:
  head/share/man/man9/style.9

Modified: head/share/man/man9/style.9
==
--- head/share/man/man9/style.9 Wed Oct 28 21:06:17 2020(r367117)
+++ head/share/man/man9/style.9 Wed Oct 28 21:09:56 2020(r367118)
@@ -25,7 +25,7 @@
 .\"From: @(#)style 1.14 (Berkeley) 4/28/95
 .\" $FreeBSD$
 .\"
-.Dd July 16, 2020
+.Dd October 28, 2020
 .Dt STYLE 9
 .Os
 .Sh NAME
@@ -156,9 +156,13 @@ includes
 .In sys/types.h ;
 do not include both.
 .Pc
+Next, include
+.In sys/systm.h ,
+if needed.
 The remaining kernel headers should be sorted alphabetically.
 .Bd -literal
 #include  /* Non-local includes in angle brackets. */
+#include 
 #include 
 #include 
 #include 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r367103 - head/usr.bin/calendar

2020-10-28 Thread Warner Losh
On Wed, Oct 28, 2020 at 9:09 AM Stefan Esser  wrote:

> Am 28.10.20 um 14:34 schrieb Kyle Evans:
> > On Wed, Oct 28, 2020 at 8:24 AM Stefan Esser  wrote:
> >> I'm thinking about support for nested conditionals and #else in
> >> calendar files, but I'm not sure about the possibility to MFC
> >> such a change and I do not want to invite users to create calendar
> >> files that work in -CURRENT but not in -STABLE.
> >
> > Unsolicited $0.02: Do whatever you feel comfortable with. It's up to
> > people trying to use the new/advanced features to make sure it's
> > compatible with the calendar(1) that *they* are using, and I'm having
> > a hard time imagining folks using deploying additional calendar data
> > in ports outside of deskutils/calendar-data which you can curate for
> > stuff like that.
>
> I only read your reply after committing the change that allows for
> recursion.
>
> The issue reported by Julian H. Stacey on the freebsd-stable list
> made me check for the code that implements these conditions, and
> I noticed that there was no #ifdef (which he had tried to use),
> but it was trivial to implement.
>
> The man-page mentions that a restricted subset of CPP directives
> is supported, and ISTR that an earlier version of the calendar
> program actually forked CPP to pre-process the data files.
>
> This approach required a "traditional" CPP that ignored the content
> of the non-directives being processed, which is no longer available.
>
> In a way I'm removing some of the limitations that resulted from
> the switch to an internal parser for the conditions.
>
> If there is consensus not to introduce any new features into our
> calendar program, then I'm going to revert these changes.
>
> I had planned to give time for a discussion about a possible
> merge to -STABLE.
>
> I have already created a port of the calendar program as
> deskutils/calendar and was planning to upgrade the port to include
> these changes in -CURRENT.
>
> The port could be used to provide release users with these features,
> if they consider them useful.
>
> Since the changes are fully compatible with old data files, I do
> not think that a MFC was a violation of POLA.
>
> We do now have the calendar-data port for use in -CURRENT and it
> could be used to distribute calendar files that use the new features.
>
> Since old calendar programs will not look into the port's data file
> directory, they will continue to operate on files in the base
> system.
>
> If the calendar program from a port is used, it will support the
> features of this version and that all calendar files that take
> advantage of them.
>
> We might hide these new features by removal from the man-page or we
> could discourage their use by declaring them unportable extensions.
>

Honestly, I think MFCing what we've committed to date and requiring
calendar-data is fine. POLA isn't violated because you have to install a
new port, especially when the program that 'fails' includes that in its
failure message. It's the least bad solution, and calendar isn't a critical
part of the infrastructure where we have to make herculean efforts to hide
any changes. It beats the old files rotting in stable.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366993 - head/sys/net

2020-10-27 Thread Warner Losh
On Tue, Oct 27, 2020 at 2:23 PM Konstantin Belousov 
wrote:

> On Tue, Oct 27, 2020 at 02:52:38PM -0400, Ed Maste wrote:
> > On Sat, 24 Oct 2020 at 06:46, Konstantin Belousov 
> wrote:
> > >
> > > > -#include 
> > > sys/systm.h should come right after sys/param.h.  These two headers are
> > > exceptions to the normal alphabetical rule.
> >
> > style(9) claims that sys/types.h and sys/param.h are the special headers:
> >
> >  Kernel include files (sys/*.h) come first.  If  is
> needed
> >  for __FBSDID(), include it first.  If either  or
> >   is needed, include it before other include files.
> >  ( includes ; do not include both.) The
> >  remaining kernel headers should be sorted alphabetically.
> >
> > We should add sys/systm.h to style(9) as another special case if
> necessary.
> Yes sys/systm.h is very special because it defines a lot of basic things,
> like asserts, printf(9), and so on, and because it includes enough other
> popular headers.  Its intent is to gather all common stuff, which makes
> it both convenient and necessary to go before other (but sys/param.h is
> more
> prioritized).
>

So sorted after sys/types.h or sys/param.h should be documented in style(9).

https://reviews.freebsd.org/D26981

has a proposed change.

Warner


> >
> > > > -infiniband_ipv4_multicast_map(uint32_t addr,
> > > > -const uint8_t *broadcast, uint8_t *buf)
> > > > +infiniband_ipv4_multicast_map(
> > > > +uint32_t addr, const uint8_t *broadcast, uint8_t *buf)
> > > And this is arguably regression, we fill line up to columns 72-80
> before
> > > splitting to the continuation line.
> >
> > I agree with kib and arichardson has a clang-format fix for this in
> > D26978. That said I can see an argument for it being easier to read
> > with all function args on the same line.
> >
> > > > - m = NULL;   /* mbuf is consumed by
> resolver */
> > > > + m = NULL; /* mbuf is consumed by
> resolver */
> > > This is a regression as well, in-line comment is typically preceeded
> by tab.
> >
> > I suspect this is hard to do in an automated fashion in a way that's
> > sensible overall (i.e., lining up inline comments on different lines).
> >
> > This could be a case where we decide to just accept it when someone
> > uses clang-format on new code, and just discourage sweeping
> > clang-format changes on existing code.
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r367071 - in head/sys: geom sys

2020-10-27 Thread Warner Losh
Author: imp
Date: Tue Oct 27 06:43:24 2020
New Revision: 367071
URL: https://svnweb.freebsd.org/changeset/base/367071

Log:
  Remove frontstuff
  
  Nothing implements this in the tree. Remove the ioctl and the
  conversion to the geom atttribute stuff.
  
  This was introduced in r94287 in 2002 and was retired in r113390
  2003. It appeared in FreeBSD 5.0, but no other releases. This is a
  vestige that was missed at the time and overlooked until now. No
  compat is provided for this reason.  And there's no implementation of
  it today. And it was never part of a release from a stable branch.
  
  Reviewed by: phk@
  Differential Revision: https://reviews.freebsd.org/D26967

Modified:
  head/sys/geom/geom_dev.c
  head/sys/geom/geom_disk.c
  head/sys/sys/disk.h

Modified: head/sys/geom/geom_dev.c
==
--- head/sys/geom/geom_dev.cTue Oct 27 04:35:47 2020(r367070)
+++ head/sys/geom/geom_dev.cTue Oct 27 06:43:24 2020(r367071)
@@ -550,9 +550,6 @@ g_dev_ioctl(struct cdev *dev, u_long cmd, caddr_t data
if (error == 0 && *(u_int *)data == 0)
error = ENOENT;
break;
-   case DIOCGFRONTSTUFF:
-   error = g_io_getattr("GEOM::frontstuff", cp, , data);
-   break;
 #ifdef COMPAT_FREEBSD11
case DIOCSKERNELDUMP_FREEBSD11:
{

Modified: head/sys/geom/geom_disk.c
==
--- head/sys/geom/geom_disk.c   Tue Oct 27 04:35:47 2020(r367070)
+++ head/sys/geom/geom_disk.c   Tue Oct 27 06:43:24 2020(r367071)
@@ -498,8 +498,6 @@ g_disk_start(struct bio *bp)
break;
else if (g_handleattr_int(bp, "GEOM::fwheads", dp->d_fwheads))
break;
-   else if (g_handleattr_off_t(bp, "GEOM::frontstuff", 0))
-   break;
else if (g_handleattr_str(bp, "GEOM::ident", dp->d_ident))
break;
else if (g_handleattr_str(bp, "GEOM::descr", dp->d_descr))

Modified: head/sys/sys/disk.h
==
--- head/sys/sys/disk.h Tue Oct 27 04:35:47 2020(r367070)
+++ head/sys/sys/disk.h Tue Oct 27 06:43:24 2020(r367071)
@@ -64,14 +64,6 @@ void disk_err(struct bio *bp, const char *what, int bl
 * core dumps.
 */
 
-#defineDIOCGFRONTSTUFF _IOR('d', 134, off_t)
-   /*
-* Many disk formats have some amount of space reserved at the
-* start of the disk to hold bootblocks, various disklabels and
-* similar stuff.  This ioctl returns the number of such bytes
-* which may apply to the device.
-*/
-
 #defineDIOCGFLUSH _IO('d', 135)/* Flush write cache */
/*
 * Flush write cache of the device.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366962 - in head: include usr.bin/calendar

2020-10-26 Thread Warner Losh
On Mon, Oct 26, 2020 at 12:01 AM Alex Kozlov  wrote:

> On Sun, Oct 25, 2020 at 11:37:34AM +0100, Stefan Esser wrote:
> > Am 25.10.20 um 06:56 schrieb Alex Kozlov:
> > > On Sat, Oct 24, 2020 at 04:37:45PM +0200, Stefan Esser wrote:
> > > > Am 24.10.20 um 09:48 schrieb Alex Kozlov:
> > [...]
> > > > > You are hardcoding assumption that LOCALBASE = /usr/local. Please
> make it
> > > > > overridable with LOCALBASE environment variable.
> > > > This was a trivial change to get us going with calendars provided by
> > > > a port (which has not been committed, yet - therefore there are no
> > > > port-provided calendars, neither under /usr/local nor under any other
> > > > PREFIX, as of now).
> > >
> > > > I understand what you are asking for, but in such a case I'd rather
> > > > think you want to rebuild FreeBSD with _PATH_LOCALBASE modified in
> > > > paths.h.
> > > The PREFIX != LOCALBASE and both != /usr/local configurations
> > > are supported in the ports tree and the base for a long time, please
> see
> > >
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-prefix.html
> >
> > Yes, and I do not need to look that up in the handbook, having been
> > a ports committer for 2 decades by now.
> >
> > > If after this commit you need to rebuild base to use non-default
> LOCALBASE/PREFIX
> > > it is pretty big regression and POLA.
> >
> > How is that any different than before?
> >
> > What I did is make the PATH easier to change when you rebuild base.
> >
> > There are numerous programs in base that contain the literal string
> > /usr/local - and what I did was implement a mechanism that allows
> > to replace this literal reference with a simple change in paths.h.
> >
> > If you do not modify paths.h for a different LOCALBASE, then you'll
> > get a wrong _PATH_DEFPATH compiled into your binaries, for example.
> >
> > > > And I have made this a single instance that needs to be changed.
> > > > Before my change there were 2 instances of /usr/local hard-coded
> > > > in _PATH_DEFPATH - now you have to only change the definition of
> > > > _PATH_LOCALBASE to adjust all 3 locations that use it.
> > > I think you made situation worse, there were two stray hardcoded
> > > string and now there is official LOCALBASE define which likely will be
> > > used by other people in the future.
> >
> > I'd hope so to get rid of many of the 1713 literal uses of /usr/local
> > in our source tree.
> >
> > > > If you can show me precedence of a LOCALBASE environment variable
> > > > being used in the way you suggest, I'd be willing to make calendar
> > > > use it.
> > > Just an analogy from LOCALBASE make variable, perhaps CALENDAR_HOME
> > > is a better name.
> >
> > Yes, I already suggested CALENDAR_HOME, but as an environment variable
> > to check, if you want to be able to path an additional directory (or
> > search path) to the calendar program at run-time. But why introduce
> > a CALENDAR_HOME macro in the sources, if the port supplied calendar
> > files are known to be found at LOCALBASE/share/calendar (for some value
> > of LOCALBASE).
> >
> > I want to make more programs that currently hard-code /usr/local use
> > _PATH_LOCALBASE instead. This C macro can then be default to /usr/local
> > but can be overridden by passing LOCALBASE to the compiler (from the
> > build infrastructure) when paths.h is included.
> >
> > Instead of referring to _PATH_LOCALBASE these files could directly use
> > LOCALBASE, but since other paths are defined as _PATH_xxx in paths.h I
> > think it is best to follow this precedent.
> >
> > > > But then I think a CALENDAR_HOME variable would be even more useful,
> > > > since it would allow to search an additional user selected directory
> > > > (and not just share/calendar within what you provide as LOCALBASE).
> >
> > My change did not add any dependency on LOCALBASE to any previously
> > existing functionality. It added support for calendar files provided
> > by a port (a feature that did not exist before) at a location that is
> > correct for the big majority of users (who do not modify LOCALBASE).
> >
> > As I said: I'm going to make it easier to build the base system with
> > a different LOCALBASE, but not by run-time checking an environment
> > variable that specifies LOCALBASE in each affected program.
> It seems that you intend to follow through no matter what. So, just for
> the record, I think that hardcoding LOCALBASE and requiring base rebuild
> to change it is a very wrong approach.
>

So, first off, it's already hard coded. Stefan's changes change the hard
coding from 'impossible to change' to 'changeable with a recompile' which
is an improvement. It might even wind up as a build variable (or not, doing
that has some really ugly, nasty dependencies).

But even in ports-land, it's a compile time constant. Quite a large number
of ports will allow you to change it at compile / build time, but not
after. You have to rebuild if you want to change PREFIX...

So I'm a bit 

svn commit: r367051 - in head: . usr.bin/calendar usr.bin/calendar/calendars usr.bin/calendar/calendars/de_AT.ISO_8859-15 usr.bin/calendar/calendars/de_DE.ISO8859-1 usr.bin/calendar/calendars/fr_FR...

2020-10-25 Thread Warner Losh
Author: imp
Date: Mon Oct 26 03:26:18 2020
New Revision: 367051
URL: https://svnweb.freebsd.org/changeset/base/367051

Log:
  calendar: remove all datafiles except freebsd one
  
  Move all the data files for the calendar(1) program, except
  calendar.freebsd to the calendar-data package. When a file
  can't be found, and /usr/local/share/calendar doesn't exist
  provide a helpful hint to install this package.
  
  Reviewed by: se@
  Differential Revision:  https://reviews.freebsd.org/D26926

Deleted:
  head/usr.bin/calendar/calendars/calendar.all
  head/usr.bin/calendar/calendars/calendar.australia
  head/usr.bin/calendar/calendars/calendar.birthday
  head/usr.bin/calendar/calendars/calendar.brazilian
  head/usr.bin/calendar/calendars/calendar.christian
  head/usr.bin/calendar/calendars/calendar.computer
  head/usr.bin/calendar/calendars/calendar.croatian
  head/usr.bin/calendar/calendars/calendar.dutch
  head/usr.bin/calendar/calendars/calendar.french
  head/usr.bin/calendar/calendars/calendar.german
  head/usr.bin/calendar/calendars/calendar.history
  head/usr.bin/calendar/calendars/calendar.holiday
  head/usr.bin/calendar/calendars/calendar.hungarian
  head/usr.bin/calendar/calendars/calendar.judaic
  head/usr.bin/calendar/calendars/calendar.lotr
  head/usr.bin/calendar/calendars/calendar.music
  head/usr.bin/calendar/calendars/calendar.newzealand
  head/usr.bin/calendar/calendars/calendar.russian
  head/usr.bin/calendar/calendars/calendar.southafrica
  head/usr.bin/calendar/calendars/calendar.ukrainian
  head/usr.bin/calendar/calendars/calendar.usholiday
  head/usr.bin/calendar/calendars/calendar.world
  head/usr.bin/calendar/calendars/de_AT.ISO_8859-15/
  head/usr.bin/calendar/calendars/de_DE.ISO8859-1/
  head/usr.bin/calendar/calendars/fr_FR.ISO8859-1/
  head/usr.bin/calendar/calendars/hr_HR.ISO8859-2/
  head/usr.bin/calendar/calendars/hu_HU.ISO8859-2/
  head/usr.bin/calendar/calendars/pt_BR.ISO8859-1/
  head/usr.bin/calendar/calendars/pt_BR.UTF-8/
  head/usr.bin/calendar/calendars/ru_RU.KOI8-R/
  head/usr.bin/calendar/calendars/ru_RU.UTF-8/
  head/usr.bin/calendar/calendars/uk_UA.KOI8-U/
Modified:
  head/ObsoleteFiles.inc
  head/UPDATING
  head/usr.bin/calendar/Makefile
  head/usr.bin/calendar/calendar.1
  head/usr.bin/calendar/io.c

Modified: head/ObsoleteFiles.inc
==
--- head/ObsoleteFiles.inc  Mon Oct 26 01:23:14 2020(r367050)
+++ head/ObsoleteFiles.inc  Mon Oct 26 03:26:18 2020(r367051)
@@ -36,6 +36,72 @@
 #   xargs -n1 | sort | uniq -d;
 # done
 
+# 20201025: Remove cal data files
+OLD_FILES+=usr/share/calendar/calendar.all
+OLD_FILES+=usr/share/calendar/calendar.australia
+OLD_FILES+=usr/share/calendar/calendar.birthday
+OLD_FILES+=usr/share/calendar/calendar.brazilian
+OLD_FILES+=usr/share/calendar/calendar.christian
+OLD_FILES+=usr/share/calendar/calendar.computer
+OLD_FILES+=usr/share/calendar/calendar.croatian
+OLD_FILES+=usr/share/calendar/calendar.dutch
+OLD_FILES+=usr/share/calendar/calendar.french
+OLD_FILES+=usr/share/calendar/calendar.german
+OLD_FILES+=usr/share/calendar/calendar.history
+OLD_FILES+=usr/share/calendar/calendar.holiday
+OLD_FILES+=usr/share/calendar/calendar.hungarian
+OLD_FILES+=usr/share/calendar/calendar.judaic
+OLD_FILES+=usr/share/calendar/calendar.lotr
+OLD_FILES+=usr/share/calendar/calendar.music
+OLD_FILES+=usr/share/calendar/calendar.newzealand
+OLD_FILES+=usr/share/calendar/calendar.russian
+OLD_FILES+=usr/share/calendar/calendar.southafrica
+OLD_FILES+=usr/share/calendar/calendar.ukrainian
+OLD_FILES+=usr/share/calendar/calendar.usholiday
+OLD_FILES+=usr/share/calendar/calendar.world
+OLD_FILES+=usr/share/calendar/de_AT.ISO_8859-15/calendar.feiertag
+OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.all
+OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.feiertag
+OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.geschichte
+OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.kirche
+OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.literatur
+OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.musik
+OLD_FILES+=usr/share/calendar/de_DE.ISO8859-1/calendar.wissenschaft
+OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.all
+OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.fetes
+OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.french
+OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.jferies
+OLD_FILES+=usr/share/calendar/fr_FR.ISO8859-1/calendar.proverbes
+OLD_FILES+=usr/share/calendar/hr_HR.ISO8859-2/calendar.all
+OLD_FILES+=usr/share/calendar/hr_HR.ISO8859-2/calendar.praznici
+OLD_FILES+=usr/share/calendar/hu_HU.ISO8859-2/calendar.all
+OLD_FILES+=usr/share/calendar/hu_HU.ISO8859-2/calendar.nevnapok
+OLD_FILES+=usr/share/calendar/hu_HU.ISO8859-2/calendar.unnepek
+OLD_FILES+=usr/share/calendar/pt_BR.ISO8859-1/calendar.all
+OLD_FILES+=usr/share/calendar/pt_BR.ISO8859-1/calendar.commemorative

Re: svn commit: r366962 - in head: include usr.bin/calendar

2020-10-25 Thread Warner Losh
On Sun, Oct 25, 2020, 9:04 AM Kyle Evans  wrote:

> On Sun, Oct 25, 2020 at 5:21 AM Stefan Esser  wrote:
> >
> > Am 25.10.20 um 04:46 schrieb Rodney W. Grimes:
> > >> On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes <
> free...@gndrsh.dnsmgr.net>
> > >> wrote:
> >  +#define  _PATH_LOCALBASE "/usr/local"
> >  +
> > >>>
> > >>> Something feels very wrong about this becoming a  defined path in
> base,
> > >>> it is further dependence on /usr/local which in the early days we
> spent
> > >>> a great deal of time removing.
> > >>>
> > >>> I believe the whole ports system allows this to be something other
> > >>> than /usr/local.  Package should also allow it to be some other
> place.
> > >>>
> > >>
> > >> This removes a couple of instances of /usr/local being hardcoded and
> > >> replaces with a define, so net it's better.
> > >
> > > No, its net worse as it now creates a define that is highly likely
> > > to propogate adding additional dependencies on this value.
> > >
> > >>
> > >> It could be even better, but this is slightly better than it was
> before.
> > >
> > > I disagree, as it is now easier for additional contamination of
> > > the base system.
> >
> > There already are places that hard-code /usr/local, and I do agree
> > that this is architecturally bad, if you want to keep the base system
> > and ports as independent from each other as possible.
> >
> > But I do disagree that this was worse than before, and I'd even consider
> > replacing other verbatim occurrences of /usr/local with _PATH_LOCALBASE
> > in our sources (but not introduce new references to LOCALBASE in base).
> >
> > This would simplify a grep for such source files, for example, and also
> > to build base for systems with modified LOCALBASE.
> >
> > The following C header files in base (ignoring contrib) contain the
> > string /usr/local:
> >
> > ...
> > sys/contrib/openzfs/include/sys/lua/luaconf.h (FreeBSD specific?)
> > ...
>
> I see that you've excluded sys/contrib from the initial review, but I
> would not bother with luaconf.h in particular. These definitions just
> come from a stock Lua 5.2 and are not used in a ZFS context, they've
> ripped out loadlib and anything else that could try.
>

As an aside: I looked at using this Lua for the boot loader, but quickly
found that it was no good for that purpose due to changes like that. And it
was too far hacked from 5.2 to try to update easily...

Warner

Thanks,
>
> Kyle Evans
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366962 - in head: include usr.bin/calendar

2020-10-24 Thread Warner Losh
On Sat, Oct 24, 2020 at 8:51 PM Rodney W. Grimes 
wrote:

> [ Charset UTF-8 unsupported, converting... ]
> > Author: se
> > Date: Fri Oct 23 09:22:23 2020
> > New Revision: 366962
> > URL: https://svnweb.freebsd.org/changeset/base/366962
> >
> > Log:
> >   Add search of LOCALBASE/share/calendar for calendars supplied by a
> port.
> >
> >   Calendar files in LOCALBASE override similarily named ones in the base
> >   system. This could easily be changed if the base system calendars
> should
> >   have precedence, but it could lead to a violation of POLA since then
> the
> >   port's files were ignored unless those in base have been deleted.
> >
> >   There was no definition of _PATH_LOCALBASE in paths.h, but verbatim
> uses
> >   of /usr/local existed for _PATH_DEFPATH. Use _PATH_LOCALBASE here to
> ease
> >   a consistent modification of this prefix.
> >
> >   Reviewed by:imp, pfg
> >   Differential Revision:  https://reviews.freebsd.org/D26882
> >
> > Modified:
> >   head/include/paths.h
> >   head/usr.bin/calendar/io.c
> >   head/usr.bin/calendar/pathnames.h
> >
> > Modified: head/include/paths.h
> >
> ==
> > --- head/include/paths.h  Fri Oct 23 08:44:53 2020(r366961)
> > +++ head/include/paths.h  Fri Oct 23 09:22:23 2020(r366962)
> > @@ -37,8 +37,11 @@
> >
> >  #include 
> >
> > +#define  _PATH_LOCALBASE "/usr/local"
> > +
>
> Something feels very wrong about this becoming a  defined path in base,
> it is further dependence on /usr/local which in the early days we spent
> a great deal of time removing.
>
> I believe the whole ports system allows this to be something other
> than /usr/local.  Package should also allow it to be some other place.
>

This removes a couple of instances of /usr/local being hardcoded and
replaces with a define, so net it's better.

It could be even better, but this is slightly better than it was before.

Warner


> >  /* Default search path. */
> > -#define  _PATH_DEFPATH
>  "/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
> > +#define  _PATH_DEFPATH   "/sbin:/bin:/usr/sbin:/usr/bin:" \
> > + _PATH_LOCALBASE "/sbin:" _PATH_LOCALBASE "/bin"
> >  /* All standard utilities path. */
> >  #define  _PATH_STDPATH   "/usr/bin:/bin:/usr/sbin:/sbin"
> >  /* Locate system binaries. */
> >
> > Modified: head/usr.bin/calendar/io.c
> >
> ==
> > --- head/usr.bin/calendar/io.cFri Oct 23 08:44:53 2020
> (r366961)
> > +++ head/usr.bin/calendar/io.cFri Oct 23 09:22:23 2020
> (r366962)
> > @@ -71,7 +71,7 @@ enum {
> >  };
> >
> >  const char *calendarFile = "calendar";   /* default calendar file */
> > -static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE}; /*
> HOME */
> > +static const char *calendarHomes[] = {".calendar", _PATH_INCLUDE_LOCAL,
> _PATH_INCLUDE}; /* HOME */
> >  static const char *calendarNoMail = "nomail";/* don't sent mail if file
> exist */
> >
> >  static char path[MAXPATHLEN];
> >
> > Modified: head/usr.bin/calendar/pathnames.h
> >
> ==
> > --- head/usr.bin/calendar/pathnames.h Fri Oct 23 08:44:53 2020
> (r366961)
> > +++ head/usr.bin/calendar/pathnames.h Fri Oct 23 09:22:23 2020
> (r366962)
> > @@ -35,3 +35,4 @@
> >  #include 
> >
> >  #define  _PATH_INCLUDE   "/usr/share/calendar"
> > +#define  _PATH_INCLUDE_LOCAL _PATH_LOCALBASE "/share/calendar"
> >
>
> --
> Rod Grimes
> rgri...@freebsd.org
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366993 - head/sys/net

2020-10-24 Thread Warner Losh
On Sat, Oct 24, 2020 at 7:20 PM Ed Maste  wrote:

> On Sat, 24 Oct 2020 at 11:27, Warner Losh  wrote:
> >
> >> Given we already have nice .clang-format, that does most of the job,
> maybe it's worth considering looking into tweaking it further to fix this
> part?
> >> It would be nice if we could finally offload all formatting issues to
> the tool and focus on the actual code :-)
> >
> > It would be nice if it produced one of the style(9) acceptable formats
> without disrupting things already acceptable.  That's been the big problem
> with the tweaks to date... some things are fixed, others break. It's
> getting a lot closer, though
>
> Upstream clang-format comes with a script that can integrate with git,
> adding a `git clang-format` command. It will apply formatting to
> modified lines, leaving unchanged ones alone.
>

As long as it's optional...

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r367032 - head/sys/sys

2020-10-24 Thread Warner Losh
Author: imp
Date: Sat Oct 24 23:21:31 2020
New Revision: 367032
URL: https://svnweb.freebsd.org/changeset/base/367032

Log:
  cdefs.h: remove intel_compiler support
  
  The  age  of   the  intel  compiler  support  is  so   old  as  to  be
  uninteresting. No recent recports of  intel compiler support have been
  received.  Remove  all the  special  case  workarounds for  the  Intel
  compiler. Should there be interest in supporting the compiler, contact
  me and I'll work with people to make it happen, though I suspect these
  instances are more likely to be in the way than to be helpful.
  
  Reviewed by: cem, emaste, vangyzen, dim
  Differential Revision: https://reviews.freebsd.org/D26817

Modified:
  head/sys/sys/cdefs.h

Modified: head/sys/sys/cdefs.h
==
--- head/sys/sys/cdefs.hSat Oct 24 23:21:27 2020(r367031)
+++ head/sys/sys/cdefs.hSat Oct 24 23:21:31 2020(r367032)
@@ -75,9 +75,9 @@
  * having a compiler-agnostic source tree.
  */
 
-#if defined(__GNUC__) || defined(__INTEL_COMPILER)
+#if defined(__GNUC__)
 
-#if __GNUC__ >= 3 || defined(__INTEL_COMPILER)
+#if __GNUC__ >= 3
 #define__GNUCLIKE_ASM 3
 #define__GNUCLIKE_MATH_BUILTIN_CONSTANTS
 #else
@@ -87,15 +87,9 @@
 #define__GNUCLIKE___OFFSETOF 1
 #define__GNUCLIKE___SECTION 1
 
-#ifndef __INTEL_COMPILER
 #define__GNUCLIKE_CTOR_SECTION_HANDLING 1
-#endif
 
 #define__GNUCLIKE_BUILTIN_CONSTANT_P 1
-#if defined(__INTEL_COMPILER) && defined(__cplusplus) && \
-   __INTEL_COMPILER < 800
-#undef __GNUCLIKE_BUILTIN_CONSTANT_P
-#endif
 
 #if (__GNUC_MINOR__ > 95 || __GNUC__ >= 3)
 #define__GNUCLIKE_BUILTIN_VARARGS 1
@@ -114,10 +108,8 @@
 #define__compiler_membar() __asm __volatile(" " : : : "memory")
 #endif
 
-#ifndef __INTEL_COMPILER
 #define__GNUCLIKE_BUILTIN_NEXT_ARG 1
 #define__GNUCLIKE_MATH_BUILTIN_RELOPS
-#endif
 
 #define__GNUCLIKE_BUILTIN_MEMCPY 1
 
@@ -133,12 +125,12 @@
 
 #define__CC_SUPPORTS_DYNAMIC_ARRAY_INIT 1
 
-#endif /* __GNUC__ || __INTEL_COMPILER */
+#endif /* __GNUC__ */
 
 /*
  * Macro to test if we're using a specific version of gcc or later.
  */
-#if defined(__GNUC__) && !defined(__INTEL_COMPILER)
+#if defined(__GNUC__)
 #define__GNUC_PREREQ__(ma, mi) \
(__GNUC__ > (ma) || __GNUC__ == (ma) && __GNUC_MINOR__ >= (mi))
 #else
@@ -212,18 +204,18 @@
  * a feature that we cannot live without.
  */
 #define__weak_symbol   __attribute__((__weak__))
-#if !__GNUC_PREREQ__(2, 5) && !defined(__INTEL_COMPILER)
+#if !__GNUC_PREREQ__(2, 5)
 #define__dead2
 #define__pure2
 #define__unused
 #endif
-#if __GNUC__ == 2 && __GNUC_MINOR__ >= 5 && __GNUC_MINOR__ < 7 && 
!defined(__INTEL_COMPILER)
+#if __GNUC__ == 2 && __GNUC_MINOR__ >= 5 && __GNUC_MINOR__ < 7
 #define__dead2 __attribute__((__noreturn__))
 #define__pure2 __attribute__((__const__))
 #define__unused
 /* XXX Find out what to do for __packed, __aligned and __section */
 #endif
-#if __GNUC_PREREQ__(2, 7) || defined(__INTEL_COMPILER)
+#if __GNUC_PREREQ__(2, 7)
 #define__dead2 __attribute__((__noreturn__))
 #define__pure2 __attribute__((__const__))
 #define__unused__attribute__((__unused__))
@@ -360,7 +352,7 @@
 #define__pure
 #endif
 
-#if __GNUC_PREREQ__(3, 1) || (defined(__INTEL_COMPILER) && __INTEL_COMPILER >= 
800)
+#if __GNUC_PREREQ__(3, 1)
 #define__always_inline __attribute__((__always_inline__))
 #else
 #define__always_inline
@@ -393,11 +385,11 @@
 #endif
 
 /* XXX: should use `#if __STDC_VERSION__ < 199901'. */
-#if !__GNUC_PREREQ__(2, 7) && !defined(__INTEL_COMPILER)
+#if !__GNUC_PREREQ__(2, 7)
 #define__func__NULL
 #endif
 
-#if (defined(__INTEL_COMPILER) || (defined(__GNUC__) && __GNUC__ >= 2)) && 
!defined(__STRICT_ANSI__) || __STDC_VERSION__ >= 199901
+#if (defined(__GNUC__) && __GNUC__ >= 2) && !defined(__STRICT_ANSI__) || 
__STDC_VERSION__ >= 199901
 #define__LONG_LONG_SUPPORTED
 #endif
 
@@ -514,7 +506,7 @@
  * that are known to support the features properly (old versions of gcc-2
  * didn't permit keeping the keywords out of the application namespace).
  */
-#if !__GNUC_PREREQ__(2, 7) && !defined(__INTEL_COMPILER)
+#if !__GNUC_PREREQ__(2, 7)
 #define__printflike(fmtarg, firstvararg)
 #define__scanflike(fmtarg, firstvararg)
 #define__format_arg(fmtarg)
@@ -534,18 +526,16 @@
 
 /* Compiler-dependent macros that rely on FreeBSD-specific extensions. */
 #if defined(__FreeBSD_cc_version) && __FreeBSD_cc_version >= 31 && \
-defined(__GNUC__) && !defined(__INTEL_COMPILER)
+defined(__GNUC__)
 #define__printf0like(fmtarg, firstvararg) \
__attribute__((__format__ (__printf0__, fmtarg, firstvararg)))
 #else
 #define__printf0like(fmtarg, 

svn commit: r367031 - in head/sys/i386: i386 include

2020-10-24 Thread Warner Losh
Author: imp
Date: Sat Oct 24 23:21:27 2020
New Revision: 367031
URL: https://svnweb.freebsd.org/changeset/base/367031

Log:
  Remove support for intel compiler from i386 in_cksum
  
  We no longer support building the kernel with the old intel
  compiler. Remove support for it from in_cksum. Should there be
  interest in reviving it, this is as likely to get in the way as to
  help anyway.

Modified:
  head/sys/i386/i386/in_cksum.c
  head/sys/i386/include/in_cksum.h

Modified: head/sys/i386/i386/in_cksum.c
==
--- head/sys/i386/i386/in_cksum.c   Sat Oct 24 23:21:22 2020
(r367030)
+++ head/sys/i386/i386/in_cksum.c   Sat Oct 24 23:21:27 2020
(r367031)
@@ -60,7 +60,7 @@ __FBSDID("$FreeBSD$");
  * icc needs to be special cased here, as the asm code below results
  * in broken code if compiled with icc.
  */
-#if !defined(__GNUCLIKE_ASM) || defined(__INTEL_COMPILER)
+#if !defined(__GNUCLIKE_ASM)
 /* non gcc parts stolen from sys/alpha/alpha/in_cksum.c */
 #define REDUCE32 \
 {\
@@ -77,7 +77,7 @@ __FBSDID("$FreeBSD$");
 #endif
 #define REDUCE  {sum = (sum & 0x) + (sum >> 16); ADDCARRY(sum);}
 
-#if !defined(__GNUCLIKE_ASM) || defined(__INTEL_COMPILER)
+#if !defined(__GNUCLIKE_ASM)
 static const u_int32_t in_masks[] = {
/*0 bytes*/ /*1 byte*/  /*2 bytes*/ /*3 bytes*/
0x, 0x00FF, 0x, 0x00FF, /* offset 0 */

Modified: head/sys/i386/include/in_cksum.h
==
--- head/sys/i386/include/in_cksum.hSat Oct 24 23:21:22 2020
(r367030)
+++ head/sys/i386/include/in_cksum.hSat Oct 24 23:21:27 2020
(r367031)
@@ -55,7 +55,7 @@
  * in the normal case (where there are no options and the header length is
  * therefore always exactly five 32-bit words.
  */
-#if defined(__GNUCLIKE_ASM) && !defined(__INTEL_COMPILER)
+#if defined(__GNUCLIKE_ASM)
 #if defined(IPVERSION) && (IPVERSION == 4)
 static __inline u_int
 in_cksum_hdr(const struct ip *ip)
@@ -137,7 +137,7 @@ in_pseudo(u_int sum, u_int b, u_int c)
 #endif
 
 #ifdef _KERNEL
-#if !defined(__GNUCLIKE_ASM) || defined(__INTEL_COMPILER)
+#if !defined(__GNUCLIKE_ASM)
 #if defined(IPVERSION) && (IPVERSION == 4)
 u_int in_cksum_hdr(const struct ip *ip);
 #endif
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r367029 - head/sys/dev/bxe

2020-10-24 Thread Warner Losh
Author: imp
Date: Sat Oct 24 23:21:18 2020
New Revision: 367029
URL: https://svnweb.freebsd.org/changeset/base/367029

Log:
  Remove support for ancient compilers
  
  We don't support building the kernel from such old compilers, nor with
  the Intel Compiler specifically. Remove support for this old construct
  that was copied from stdbool.h and not relevant here.

Modified:
  head/sys/dev/bxe/ecore_sp.h

Modified: head/sys/dev/bxe/ecore_sp.h
==
--- head/sys/dev/bxe/ecore_sp.h Sat Oct 24 23:21:06 2020(r367028)
+++ head/sys/dev/bxe/ecore_sp.h Sat Oct 24 23:21:18 2020(r367029)
@@ -75,9 +75,6 @@ typedef volatile int ecore_atomic_t;
 #ifndef __bool_true_false_are_defined
 #ifndef __cplusplus
 #define bool _Bool
-#if __STDC_VERSION__ < 199901L && __GNUC__ < 3 && !defined(__INTEL_COMPILER)
-typedef _Bool bool;
-#endif
 #endif /* !__cplusplus */
 #endif /* !__bool_true_false_are_defined$ */
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r367030 - head/lib/msun/src

2020-10-24 Thread Warner Losh
Author: imp
Date: Sat Oct 24 23:21:22 2020
New Revision: 367030
URL: https://svnweb.freebsd.org/changeset/base/367030

Log:
  Remove intel compiler support from math.h
  
  The intel compiler support has badly decayed over the years. Stop
  pretending that we support it. Note, I've stopped short of requiring
  gcc builtin support with this commit since other compilers may be used
  to build non-base software and we need to support those so more
  investigation is needed before simplifying further.

Modified:
  head/lib/msun/src/math.h

Modified: head/lib/msun/src/math.h
==
--- head/lib/msun/src/math.hSat Oct 24 23:21:18 2020(r367029)
+++ head/lib/msun/src/math.hSat Oct 24 23:21:22 2020(r367030)
@@ -34,11 +34,11 @@ extern const union __nan_un {
float   __uf;
 } __nan;
 
-#if __GNUC_PREREQ__(3, 3) || (defined(__INTEL_COMPILER) && __INTEL_COMPILER >= 
800)
+#if __GNUC_PREREQ__(3, 3)
 #define__MATH_BUILTIN_CONSTANTS
 #endif
 
-#if __GNUC_PREREQ__(3, 0) && !defined(__INTEL_COMPILER)
+#if __GNUC_PREREQ__(3, 0)
 #define__MATH_BUILTIN_RELOPS
 #endif
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r367028 - in head: include sys/sys

2020-10-24 Thread Warner Losh
Author: imp
Date: Sat Oct 24 23:21:06 2020
New Revision: 367028
URL: https://svnweb.freebsd.org/changeset/base/367028

Log:
  Remove obsolete check for GCC < 3 and support for Intel Compiler
  
  We no longer support old versions of GCC. Remove this check by
  assuming it's false. That will make the entire expression false.  Also
  remove support for Intel compiler, it's badly bitrotted.  Technically,
  this removes support for C89 and K from compilers that don't define
  _Bool in those compilation environments as well. I'm unaware of any
  working compiler today for which that would be relevant (pcc has it
  and tcc sadly isn't working for other reasons), though if one
  pops up in ports, I'll work to resolve the issue.

Modified:
  head/include/stdbool.h
  head/include/stdlib.h
  head/sys/sys/types.h

Modified: head/include/stdbool.h
==
--- head/include/stdbool.h  Sat Oct 24 22:52:29 2020(r367027)
+++ head/include/stdbool.h  Sat Oct 24 23:21:06 2020(r367028)
@@ -37,9 +37,6 @@
 #definetrue1
 
 #definebool_Bool
-#if __STDC_VERSION__ < 199901L && __GNUC__ < 3 && !defined(__INTEL_COMPILER)
-typedefint _Bool;
-#endif
 
 #endif /* !__cplusplus */
 #endif /* __bool_true_false_are_defined */

Modified: head/include/stdlib.h
==
--- head/include/stdlib.h   Sat Oct 24 22:52:29 2020(r367027)
+++ head/include/stdlib.h   Sat Oct 24 23:21:06 2020(r367028)
@@ -253,7 +253,7 @@ extern void (*malloc_message)(void *, const char *);
  * On platforms where alloca() is not in libc, programs which use it
  * will fail to link when compiled with non-GNU compilers.
  */
-#if __GNUC__ >= 2 || defined(__INTEL_COMPILER)
+#if __GNUC__ >= 2
 #undef  alloca /* some GNU bits try to get cute and define this on their own */
 #define alloca(sz) __builtin_alloca(sz)
 #endif

Modified: head/sys/sys/types.h
==
--- head/sys/sys/types.hSat Oct 24 22:52:29 2020(r367027)
+++ head/sys/sys/types.hSat Oct 24 23:21:06 2020(r367028)
@@ -300,9 +300,6 @@ typedef struct vm_page  *vm_page_t;
 #define__bool_true_false_are_defined   1
 #definefalse   0
 #definetrue1
-#if __STDC_VERSION__ < 199901L && __GNUC__ < 3 && !defined(__INTEL_COMPILER)
-typedefint _Bool;
-#endif
 typedef_Bool   bool;
 #endif /* !__bool_true_false_are_defined && !__cplusplus */
 #endif /* KERNEL || _STANDALONE */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366372 - in head/sys: compat/linuxkpi/common/include/linux compat/linuxkpi/common/src conf

2020-10-24 Thread Warner Losh
On Sat, Oct 24, 2020 at 9:38 AM Kyle Evans  wrote:

> On Sat, Oct 24, 2020 at 4:52 AM Hans Petter Selasky 
> wrote:
> >
> > On 2020-10-24 02:13, Warner Losh wrote:
> > > I was going to suggest and try this change, but life has been
> complicated...
> > >
> > > Has it been committed?
> > >
> >
> > No, not yet.
> >
> > --HPS
> >
>
> I went ahead and did so: r367004
>

Excellent. I was going to do that, but you committed exactly what I was
going to.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366993 - head/sys/net

2020-10-24 Thread Warner Losh
On Sat, Oct 24, 2020, 7:38 AM Alexander V. Chernikov 
wrote:

> 24.10.2020, 14:08, "Hans Petter Selasky" :
> > On 2020-10-24 14:52, Alexey Dokuchaev wrote:
> >>  On Sat, Oct 24, 2020 at 10:23:22AM +, Hans Petter Selasky wrote:
> >>>  New Revision: 366993
> >>>  URL: https://svnweb.freebsd.org/changeset/base/366993
> >>>
> >>>  Log:
> >>> Run code through "clang-format -style=file" with some additional
> fixes.
> >>> No functional change.
> >>>
> >>>  ...
> >>>  @@ -99,8 +97,8 @@ infiniband_ipv4_multicast_map(uint32_t addr,
> >>>
> >>>#ifdef INET6
> >>>static inline void
> >>>  -infiniband_ipv6_multicast_map(const struct in6_addr *addr,
> >>>  - const uint8_t *broadcast, uint8_t *buf)
> >>>  +infiniband_ipv6_multicast_map(
> >>>  + const struct in6_addr *addr, const uint8_t *broadcast, uint8_t *buf)
> >>>{
> >>
> >>  This is not how we format these in FreeBSD, please revert. It was
> correct
> >>  before and no "fix" is need here.
> Given we already have nice .clang-format, that does most of the job, maybe
> it's worth considering looking into tweaking it further to fix this part?
> It would be nice if we could finally offload all formatting issues to the
> tool and focus on the actual code :-)
>

It would be nice if it produced one of the style(9) acceptable formats
without disrupting things already acceptable.  That's been the big problem
with the tweaks to date... some things are fixed, others break. It's
getting a lot closer, though

Warner

> Done.
> >
> > --HPS
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366989 - head/sys/dev/nvme

2020-10-23 Thread Warner Losh
Author: imp
Date: Sat Oct 24 01:59:01 2020
New Revision: 366989
URL: https://svnweb.freebsd.org/changeset/base/366989

Log:
  nvme: Remove compat code for older kernels
  
  Remove code that supported pre-2011 kernels. CTLTYPE_S64 was defined
  in rev 217616. All supported branches have it, so remove its compat
  definition as OBE.

Modified:
  head/sys/dev/nvme/nvme_sysctl.c

Modified: head/sys/dev/nvme/nvme_sysctl.c
==
--- head/sys/dev/nvme/nvme_sysctl.c Sat Oct 24 01:14:52 2020
(r366988)
+++ head/sys/dev/nvme/nvme_sysctl.c Sat Oct 24 01:59:01 2020
(r366989)
@@ -52,16 +52,6 @@ SYSCTL_BOOL(_hw_nvme, OID_AUTO, verbose_cmd_dump, CTLF
 _verbose_cmd_dump, 0,
 "enable verbose command printting when a command fails");
 
-/*
- * CTLTYPE_S64 and sysctl_handle_64 were added in r217616.  Define these
- *  explicitly here for older kernels that don't include the r217616
- *  changeset.
- */
-#ifndef CTLTYPE_S64
-#define CTLTYPE_S64CTLTYPE_QUAD
-#define sysctl_handle_64   sysctl_handle_quad
-#endif
-
 static void
 nvme_dump_queue(struct nvme_qpair *qpair)
 {
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366372 - in head/sys: compat/linuxkpi/common/include/linux compat/linuxkpi/common/src conf

2020-10-23 Thread Warner Losh
I was going to suggest and try this change, but life has been complicated...

Has it been committed?

Warner

On Thu, Oct 22, 2020, 1:43 PM Kyle Evans  wrote:

> On Thu, Oct 22, 2020 at 2:35 PM Niclas Zeising 
> wrote:
> >
> > On 2020-10-22 15:22, Kyle Evans wrote:
> > > On Sat, Oct 17, 2020 at 11:40 AM Warner Losh  wrote:
> > >>
> > >>
> > >>
> > >> On Sat, Oct 17, 2020, 10:11 AM Alexander V. Chernikov <
> melif...@ipfw.ru> wrote:
> > >>>
> > >>> 17.10.2020, 14:07, "Hans Petter Selasky" :
> > >>>
> > >>> On 2020-10-17 14:34, Alexander V. Chernikov wrote:
> > >>>
> > >>>   17.10.2020, 12:32, "Hans Petter Selasky" :
> > >>>
> > >>>On 2020-10-17 13:27, Alexander V. Chernikov wrote:
> > >>>
> > >>>  02.10.2020, 19:26, "Emmanuel Vadot"  > >>><mailto:m...@freebsd.org>>:
> > >>>
> > >>>   Author: manu
> > >>>   Date: Fri Oct 2 18:26:41 2020
> > >>>   New Revision: 366372
> > >>>   URL:
> https://svnweb.freebsd.org/changeset/base/366372
> > >>>
> > >>>   Log:
> > >>>  linuxkpi: Add backlight support
> > >>>
> > >>>  Add backlight function to linuxkpi.
> > >>>  Graphics drivers expose the backlight of the
> panel directly so
> > >>>allow them
> > >>>   to use the backlight subsystem so
> > >>>  user can use backlight(8) to configure them.
> > >>>
> > >>>  Reviewed by: hselasky
> > >>>  Relnotes: yes
> > >>>  Differential Revision: The FreeBSD Foundation
> > >>>
> > >>>   Added:
> > >>>
> head/sys/compat/linuxkpi/common/include/linux/backlight.h
> > >>>(contents,
> > >>>   props changed)
> > >>>   Modified:
> > >>>
> head/sys/compat/linuxkpi/common/include/linux/device.h
> > >>>  head/sys/compat/linuxkpi/common/src/linux_kmod.c
> > >>>  head/sys/compat/linuxkpi/common/src/linux_pci.c
> > >>>  head/sys/conf/kmod.mk
> > >>>
> > >>>  It breaks the build for me with
> > >>>
> /usr/home/melifaro/free/head/sys/compat/linuxkpi/common/src/linux_pci.c:70:10:
> > >>>  fatal error: 'backlight_if.h' file not found
> > >>>
> > >>>
> > >>>How do you build? Doesn't break over here.
> > >>>
> > >>>   GENERIC + COMPAT_LINUXKPI.
> > >>>
> > >>>
> > >>>
> > >>> Try adding:
> > >>>
> > >>> options backlight
> > >>>
> > >>> To the kernel config.
> > >>>
> > >>> Yep, thank you!
> > >>> Maybe it's worth considering adding static assert with the message
> describing this dependency?
> > >>
> > >>
> > >> Yes. It likely is worth doing something to highlight this issue.
> > >>
> > >> Warner
> > >>
> > >
> > > I think we just need to slap the two core backlight files with an ` |
> > > compat_linux` so that they simply get pulled in if you specify
> > > COMPAT_LINUX. config(8) handles this terribly, configng must have a
> > > better provides/requires/implies/whatever functionality so we can
> > > specify that compat_linux implies backlight and not do crud like this
> > > where it becomes more complicated to see what any given option really
> > > entails.
> > >
> > > Thanks,
> >
> > COMPAT_LINUX can't be right.  Isn't that the linuxolator?
> > Regards
> > --
> > Niclas Zeising
>
> Whoops, s/LINUX/LINUXKPI/
>
> :-)
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366983 - head/lib/libc/gen

2020-10-23 Thread Warner Losh
Author: imp
Date: Sat Oct 24 00:03:11 2020
New Revision: 366983
URL: https://svnweb.freebsd.org/changeset/base/366983

Log:
  warnx: fix needless static
  
  I noticed after the review that these shouldn't be static. Remove the
  'static' from them, otherwise concurrent calls to warn* might see a
  similar but to the original.

Modified:
  head/lib/libc/gen/err.c

Modified: head/lib/libc/gen/err.c
==
--- head/lib/libc/gen/err.c Fri Oct 23 23:56:00 2020(r366982)
+++ head/lib/libc/gen/err.c Sat Oct 24 00:03:11 2020(r366983)
@@ -161,7 +161,7 @@ warnc(int code, const char *fmt, ...)
 void
 vwarnc(int code, const char *fmt, va_list ap)
 {
-   static int saved_errno;
+   int saved_errno;
 
saved_errno = errno;
if (err_file == NULL)
@@ -187,7 +187,7 @@ warnx(const char *fmt, ...)
 void
 vwarnx(const char *fmt, va_list ap)
 {
-   static int saved_errno;
+   int saved_errno;
 
saved_errno = errno;
if (err_file == NULL)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366982 - head/lib/libc/gen

2020-10-23 Thread Warner Losh
Author: imp
Date: Fri Oct 23 23:56:00 2020
New Revision: 366982
URL: https://svnweb.freebsd.org/changeset/base/366982

Log:
  warnx: Save errno across calls that might change it.
  
  When warn() family of functions is being used after err_set_file() has
  been set to, for example, /dev/null, errno is being clobbered,
  rendering it unreliable after, for example, procstat_getpathname()
  when it is supposed to emit a warning. Then the errno is changed to
  Inappropriate ioctl for device, destroying the original value (via
  calls to fprintf()functions).
  
  Submitted by: Juraj Lutter
  Differential Revision: https://reviews.freebsd.org/D26871

Modified:
  head/lib/libc/gen/err.c

Modified: head/lib/libc/gen/err.c
==
--- head/lib/libc/gen/err.c Fri Oct 23 22:27:45 2020(r366981)
+++ head/lib/libc/gen/err.c Fri Oct 23 23:56:00 2020(r366982)
@@ -161,6 +161,9 @@ warnc(int code, const char *fmt, ...)
 void
 vwarnc(int code, const char *fmt, va_list ap)
 {
+   static int saved_errno;
+
+   saved_errno = errno;
if (err_file == NULL)
err_set_file(NULL);
fprintf(err_file, "%s: ", _getprogname());
@@ -169,6 +172,7 @@ vwarnc(int code, const char *fmt, va_list ap)
fprintf(err_file, ": ");
}
fprintf(err_file, "%s\n", strerror(code));
+   errno = saved_errno;
 }
 
 void
@@ -183,10 +187,14 @@ warnx(const char *fmt, ...)
 void
 vwarnx(const char *fmt, va_list ap)
 {
+   static int saved_errno;
+
+   saved_errno = errno;
if (err_file == NULL)
err_set_file(NULL);
fprintf(err_file, "%s: ", _getprogname());
if (fmt != NULL)
vfprintf(err_file, fmt, ap);
fprintf(err_file, "\n");
+   errno = saved_errno;
 }
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366822 - in head: share/man/man5 usr.bin/login

2020-10-18 Thread Warner Losh
Author: imp
Date: Mon Oct 19 01:16:39 2020
New Revision: 366822
URL: https://svnweb.freebsd.org/changeset/base/366822

Log:
  Add more explicit instructions about updating motd
  
  Not that you can regenerate the motd by editing motd.template and
  running 'service motd restart' rather than rebooting.
  
  Small wordsmithing by me, and updated the example from FreeBSD 2.1.6.1
  release to 12.1 release.
  
  Submitted by: Dan Mack

Modified:
  head/share/man/man5/motd.5
  head/usr.bin/login/motd.template

Modified: head/share/man/man5/motd.5
==
--- head/share/man/man5/motd.5  Sun Oct 18 23:58:40 2020(r366821)
+++ head/share/man/man5/motd.5  Mon Oct 19 01:16:39 2020(r366822)
@@ -3,7 +3,7 @@
 .\" This file is in the public domain.
 .\" $FreeBSD$
 .\"
-.Dd July 20, 2019
+.Dd October 18, 2020
 .Dt MOTD 5
 .Os
 .Sh NAME
@@ -22,6 +22,14 @@ prepended to
 and the contents are written to
 .Pa /var/run/motd .
 .Pp
+.Pa /var/run/motd
+can be updated without a system reboot by manually restarting the
+motd service after updating
+.Pa /etc/motd.template:
+.Bd -literal -offset -ident -compact
+service motd restart
+.Ed
+.Pp
 Individual users may suppress the display of this file by
 creating a file named
 .Dq Pa .hushlogin
@@ -39,7 +47,7 @@ Suppresses output of
 .El
 .Sh EXAMPLES
 .Bd -literal
-FreeBSD 2.1.6.1-RELEASE (GENERIC) #0: Sun Dec 29 03:08:31 PST 1996
+FreeBSD 12.1-RELEASE (GENERIC) #0: Sun Dec 29 03:08:31 PST 2019
 
 /home is full.  Please cleanup your directories.
 .Ed

Modified: head/usr.bin/login/motd.template
==
--- head/usr.bin/login/motd.templateSun Oct 18 23:58:40 2020
(r366821)
+++ head/usr.bin/login/motd.templateMon Oct 19 01:16:39 2020
(r366822)
@@ -17,4 +17,4 @@ Please include that output and any error messages when
 Introduction to manual pages:  man man
 FreeBSD directory layout:  man hier
 
-Edit /etc/motd.template to change this login announcement.
+To change this login announcement, see motd(5).
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366372 - in head/sys: compat/linuxkpi/common/include/linux compat/linuxkpi/common/src conf

2020-10-17 Thread Warner Losh
On Sat, Oct 17, 2020, 10:11 AM Alexander V. Chernikov 
wrote:

> 17.10.2020, 14:07, "Hans Petter Selasky" :
>
> On 2020-10-17 14:34, Alexander V. Chernikov wrote:
>
>  17.10.2020, 12:32, "Hans Petter Selasky" :
>
>   On 2020-10-17 13:27, Alexander V. Chernikov wrote:
>
> 02.10.2020, 19:26, "Emmanuel Vadot">:
>
>  Author: manu
>  Date: Fri Oct 2 18:26:41 2020
>  New Revision: 366372
>  URL: https://svnweb.freebsd.org/changeset/base/366372
>
>  Log:
> linuxkpi: Add backlight support
>
> Add backlight function to linuxkpi.
> Graphics drivers expose the backlight of the panel
> directly so
>   allow them
>  to use the backlight subsystem so
> user can use backlight(8) to configure them.
>
> Reviewed by: hselasky
> Relnotes: yes
> Differential Revision: The FreeBSD Foundation
>
>  Added:
>
> head/sys/compat/linuxkpi/common/include/linux/backlight.h
>   (contents,
>  props changed)
>  Modified:
> head/sys/compat/linuxkpi/common/include/linux/device.h
> head/sys/compat/linuxkpi/common/src/linux_kmod.c
> head/sys/compat/linuxkpi/common/src/linux_pci.c
> head/sys/conf/kmod.mk
>
> It breaks the build for me with
>
> 
> /usr/home/melifaro/free/head/sys/compat/linuxkpi/common/src/linux_pci.c:70:10:
> fatal error: 'backlight_if.h' file not found
>
>
>   How do you build? Doesn't break over here.
>
>  GENERIC + COMPAT_LINUXKPI.
>
>
>
> Try adding:
>
> options backlight
>
> To the kernel config.
>
> Yep, thank you!
> Maybe it's worth considering adding static assert with the message
> describing this dependency?
>

Yes. It likely is worth doing something to highlight this issue.

Warner


--HPS
>
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366732 - in head/release: amd64 arm64

2020-10-15 Thread Warner Losh
And on a related note, I can make it so we can build w/o ZSTD in the CD
boot loader because it's not needed there. I'd rather not, but if the 800k
limit is a real thing in relevant places, we have that as an option.

Warner

On Thu, Oct 15, 2020 at 1:34 PM Warner Losh  wrote:

> I'd recommend bumping this to 2MB or larger.
>
> This most likely is from the zstd landing which pushed arm64's size over
> the 1MB limit in memory, so it's only a matter of time before the file
> grows past 1MB in size.
>
> Warner
>
> On Thu, Oct 15, 2020 at 11:13 AM Glen Barber  wrote:
>
>> Author: gjb
>> Date: Thu Oct 15 17:12:58 2020
>> New Revision: 366732
>> URL: https://svnweb.freebsd.org/changeset/base/366732
>>
>> Log:
>>   Increase the amd64 ISO ESP file size from 800KB to 1024KB.
>>
>>   At some poing over the last week, the bootx64.efi file has grown
>>   past the 800KB threshold, resulting in being unable to copy it to
>>   the EFI/BOOT directory.
>>
>># stat -f %z efiboot.znWo7m
>>819200
>># stat -f %z stand-test.PIEugN/EFI/BOOT/bootx64.efi
>>842752
>>
>>   The comment in the script that creates the ISOs suggests that 800KB
>>   is the maximum allowed for the boot code, however I was able to
>>   boot an ISO with a 1024KB boot partition.  Additionally, I verified
>>   against an ISO from OtherOS, where the boot EFI partition is 2.4MB.
>>
>>   Sponsored by: Rubicon Communications, LLC (netgate.com)
>>
>> Modified:
>>   head/release/amd64/mkisoimages.sh
>>   head/release/arm64/mkisoimages.sh
>>
>> Modified: head/release/amd64/mkisoimages.sh
>>
>> ==
>> --- head/release/amd64/mkisoimages.sh   Thu Oct 15 17:05:21 2020
>> (r366731)
>> +++ head/release/amd64/mkisoimages.sh   Thu Oct 15 17:12:58 2020
>> (r366732)
>> @@ -46,10 +46,10 @@ if [ "$1" = "-b" ]; then
>> bootable="-o bootimage=i386;$BASEBITSDIR/boot/cdboot -o
>> no-emul-boot"
>>
>> # Make EFI system partition.
>> -   # The ISO file is a special case, in that it only has a maximum of
>> -   # 800 KB available for the boot code. So make an 800 KB ESP
>> espfilename=$(mktemp /tmp/efiboot.XX)
>> -   make_esp_file ${espfilename} 800 ${BASEBITSDIR}/boot/loader.efi
>> +   # ESP file size in KB.
>> +   espsize="1024"
>> +   make_esp_file ${espfilename} ${espsize}
>> ${BASEBITSDIR}/boot/loader.efi
>> bootable="$bootable -o bootimage=i386;${espfilename} -o
>> no-emul-boot -o platformid=efi"
>>
>> shift
>>
>> Modified: head/release/arm64/mkisoimages.sh
>>
>> ==
>> --- head/release/arm64/mkisoimages.sh   Thu Oct 15 17:05:21 2020
>> (r366731)
>> +++ head/release/arm64/mkisoimages.sh   Thu Oct 15 17:12:58 2020
>> (r366732)
>> @@ -40,10 +40,10 @@ if [ "$1" = "-b" ]; then
>> BASEBITSDIR="$4"
>>
>> # Make an EFI system partition.
>> -   # The ISO file is a special case, in that it only has a maximum of
>> -   # 800 KB available for the boot code. So make an 800 KB ESP
>> espfilename=$(mktemp /tmp/efiboot.XX)
>> -   make_esp_file ${espfilename} 800 ${BASEBITSDIR}/boot/loader.efi
>> +   # ESP file size in KB.
>> +   espsize="1024"
>> +   make_esp_file ${espfilename} ${espsize}
>> ${BASEBITSDIR}/boot/loader.efi
>>
>> bootable="-o bootimage=efi;${espfilename} -o no-emul-boot -o
>> platformid=efi"
>>
>>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366732 - in head/release: amd64 arm64

2020-10-15 Thread Warner Losh
I'd recommend bumping this to 2MB or larger.

This most likely is from the zstd landing which pushed arm64's size over
the 1MB limit in memory, so it's only a matter of time before the file
grows past 1MB in size.

Warner

On Thu, Oct 15, 2020 at 11:13 AM Glen Barber  wrote:

> Author: gjb
> Date: Thu Oct 15 17:12:58 2020
> New Revision: 366732
> URL: https://svnweb.freebsd.org/changeset/base/366732
>
> Log:
>   Increase the amd64 ISO ESP file size from 800KB to 1024KB.
>
>   At some poing over the last week, the bootx64.efi file has grown
>   past the 800KB threshold, resulting in being unable to copy it to
>   the EFI/BOOT directory.
>
># stat -f %z efiboot.znWo7m
>819200
># stat -f %z stand-test.PIEugN/EFI/BOOT/bootx64.efi
>842752
>
>   The comment in the script that creates the ISOs suggests that 800KB
>   is the maximum allowed for the boot code, however I was able to
>   boot an ISO with a 1024KB boot partition.  Additionally, I verified
>   against an ISO from OtherOS, where the boot EFI partition is 2.4MB.
>
>   Sponsored by: Rubicon Communications, LLC (netgate.com)
>
> Modified:
>   head/release/amd64/mkisoimages.sh
>   head/release/arm64/mkisoimages.sh
>
> Modified: head/release/amd64/mkisoimages.sh
>
> ==
> --- head/release/amd64/mkisoimages.sh   Thu Oct 15 17:05:21 2020
> (r366731)
> +++ head/release/amd64/mkisoimages.sh   Thu Oct 15 17:12:58 2020
> (r366732)
> @@ -46,10 +46,10 @@ if [ "$1" = "-b" ]; then
> bootable="-o bootimage=i386;$BASEBITSDIR/boot/cdboot -o
> no-emul-boot"
>
> # Make EFI system partition.
> -   # The ISO file is a special case, in that it only has a maximum of
> -   # 800 KB available for the boot code. So make an 800 KB ESP
> espfilename=$(mktemp /tmp/efiboot.XX)
> -   make_esp_file ${espfilename} 800 ${BASEBITSDIR}/boot/loader.efi
> +   # ESP file size in KB.
> +   espsize="1024"
> +   make_esp_file ${espfilename} ${espsize}
> ${BASEBITSDIR}/boot/loader.efi
> bootable="$bootable -o bootimage=i386;${espfilename} -o
> no-emul-boot -o platformid=efi"
>
> shift
>
> Modified: head/release/arm64/mkisoimages.sh
>
> ==
> --- head/release/arm64/mkisoimages.sh   Thu Oct 15 17:05:21 2020
> (r366731)
> +++ head/release/arm64/mkisoimages.sh   Thu Oct 15 17:12:58 2020
> (r366732)
> @@ -40,10 +40,10 @@ if [ "$1" = "-b" ]; then
> BASEBITSDIR="$4"
>
> # Make an EFI system partition.
> -   # The ISO file is a special case, in that it only has a maximum of
> -   # 800 KB available for the boot code. So make an 800 KB ESP
> espfilename=$(mktemp /tmp/efiboot.XX)
> -   make_esp_file ${espfilename} 800 ${BASEBITSDIR}/boot/loader.efi
> +   # ESP file size in KB.
> +   espsize="1024"
> +   make_esp_file ${espfilename} ${espsize}
> ${BASEBITSDIR}/boot/loader.efi
>
> bootable="-o bootimage=efi;${espfilename} -o no-emul-boot -o
> platformid=efi"
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366662 - head/sbin/devmatch

2020-10-13 Thread Warner Losh
On Mon, Oct 12, 2020, 11:50 PM Alexey Dokuchaev  wrote:

> On Tue, Oct 13, 2020 at 05:32:00AM +0000, Warner Losh wrote:
> > New Revision: 32
> > URL: https://svnweb.freebsd.org/changeset/base/32
> >
> > Log:
> >   devmatch: First appeared in 12.0
> >
> >   Document that devmatch first appeared in FreeBSD 12.0.
> >   Also can't -> can not. But it doesn't help the sentence much.
> >
> > ...
> > @@ -62,7 +62,7 @@ Parse and use a standard NOMATCH event from
> >  for matching instead of searching the device tree.
> >  .It Fl u Fl -unbound
> >  Attempt to produce a list of those drivers with PNP info whose driver
> > -tables with that PNP info can't be found.
> > +tables with that PNP info can not be found.
>
> Are you sure you've really meant "can not" and not "cannot" here?
>

They are variants of the same word (though it seems the one word
variationis more common here) the whole sentence is a trainwreck,
though, and I should have just completely rewritten it.

Warner

>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366663 - head/share/man/man5

2020-10-12 Thread Warner Losh
Author: imp
Date: Tue Oct 13 05:39:43 2020
New Revision: 33
URL: https://svnweb.freebsd.org/changeset/base/33

Log:
  Document /boot/config as well as /boot.config
  
  Add a note about /boot/config being an alternative location for this
  information. Correct description of -P.

Modified:
  head/share/man/man5/boot.config.5

Modified: head/share/man/man5/boot.config.5
==
--- head/share/man/man5/boot.config.5   Tue Oct 13 05:32:00 2020
(r32)
+++ head/share/man/man5/boot.config.5   Tue Oct 13 05:39:43 2020
(r33)
@@ -23,7 +23,7 @@
 .\" SUCH DAMAGE.
 .\"
 .\" $FreeBSD$
-.Dd May 13, 2007
+.Dd October 12, 2020
 .Dt BOOT.CONFIG 5
 .Os
 .Sh NAME
@@ -68,6 +68,8 @@ manual page.
 .Bl -tag -width /boot.config -compact
 .It Pa /boot.config
 parameters for the boot blocks (optional)
+.It Pa /boot/config
+Altnerate location for boot config information
 .El
 .Sh EXAMPLES
 The command:
@@ -76,7 +78,8 @@ The command:
 .Ed
 .Pp
 will activate the serial console of
-.Fx .
+.Fx
+if no keyboard is present, otherwise video console will be used.
 .Pp
 The command:
 .Bd -literal -offset indent
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366662 - head/sbin/devmatch

2020-10-12 Thread Warner Losh
Author: imp
Date: Tue Oct 13 05:32:00 2020
New Revision: 32
URL: https://svnweb.freebsd.org/changeset/base/32

Log:
  devmatch: First appeared in 12.0
  
  Document that devmatch first appeared in FreeBSD 12.0. Also can't -> can not. 
But
  it doesn't help the sentence much.
  
  MFC After: 3 days

Modified:
  head/sbin/devmatch/devmatch.8

Modified: head/sbin/devmatch/devmatch.8
==
--- head/sbin/devmatch/devmatch.8   Tue Oct 13 05:19:00 2020
(r31)
+++ head/sbin/devmatch/devmatch.8   Tue Oct 13 05:32:00 2020
(r32)
@@ -23,7 +23,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd February 16, 2018
+.Dd October 12, 2020
 .Dt DEVMATCH 8
 .Os
 .Sh NAME
@@ -62,7 +62,7 @@ Parse and use a standard NOMATCH event from
 for matching instead of searching the device tree.
 .It Fl u Fl -unbound
 Attempt to produce a list of those drivers with PNP info whose driver
-tables with that PNP info can't be found.
+tables with that PNP info can not be found.
 .It Fl v Fl -verbose
 Produce more verbose output.
 .El
@@ -94,3 +94,7 @@ logical equivalent in USB, PCI, and others.
 .Pp
 Many drivers currently lack proper PNP table decorations and need to
 be updated.
+.Sh HISTORY
+.Nm
+first appeared in
+.Fx 12.0 .
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366661 - head/sbin/devd

2020-10-12 Thread Warner Losh
Author: imp
Date: Tue Oct 13 05:19:00 2020
New Revision: 31
URL: https://svnweb.freebsd.org/changeset/base/31

Log:
  Document the rather suprising behavior with ' inside action rules.
  
  To prevent issues with odd shell characters appearing in, a surprising
  shell feature is used. Document it and a workaround for it.
  
  Differential Revision: https://reviews.freebsd.org/D26723

Modified:
  head/sbin/devd/devd.conf.5

Modified: head/sbin/devd/devd.conf.5
==
--- head/sbin/devd/devd.conf.5  Tue Oct 13 04:37:57 2020(r30)
+++ head/sbin/devd/devd.conf.5  Tue Oct 13 05:19:00 2020(r31)
@@ -40,7 +40,7 @@
 .\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
 .\" SOFTWARE.
 .\"
-.Dd August 18, 2020
+.Dd October 12, 2020
 .Dt DEVD.CONF 5
 .Os
 .Sh NAME
@@ -662,6 +662,59 @@ For example:
 // is a new comment, even though it is logically
 // part of the previous comment.
 .Ed
+.Ss Notes on Variable Expansion
+To prevent issues with special shell characters, the following happens for each
+variable
+.Ic $foo .
+.Bl -enum
+.It
+The characters
+.Dq $'
+are inserted.
+.It
+The string
+.Dq $foo
+is removed.
+.It
+The value of the
+.Ic foo
+variable is inserted into the buffer with all single quote characters
+prefixed by a backslash.
+.El
+.Pp
+See
+.Xr sh 1
+for what this construct means.
+It is safe in all context, except one: inside single quotes.
+If foo=meta and bar=var, then a rule like the following:
+.Bd -literal -offset indent -compact
+action "echo '$foo $bar'";
+.Ed
+will be presented to the shell via
+.Xr system 3
+as
+.Bd -literal -offset indent -compact
+echo '$'meta' $'var''
+.Ed
+which produces the following output:
+.Bd -literal -offset indent -compact
+$meta $var
+.Ed
+as its output.
+This is an unanticipated result.
+A future version of this software will change this behavior.
+Users are discouraged from using single quotes inside
+.Ic action
+value without due care.
+.Pp
+The above should be written as
+.Bd -literal -offset indent -compact
+action "echo $foo' '$bar"
+.Ed
+to produce a single argument to echo.
+Given the above expansion, juxtaposing bare variables with
+single quote expressions will produce the right output,
+regardless of the value of the variable.
 .Sh FILES
 .Bl -tag -width ".Pa /etc/devd.conf" -compact
 .It Pa /etc/devd.conf
@@ -733,6 +786,9 @@ detach 0 {
 The installed
 .Pa /etc/devd.conf
 has many additional examples.
+.Sh BUGS
+The variable expansion's interaction with single quotes is
+suboptimal and surprising.
 .Sh SEE ALSO
 .Xr cam 4 ,
 .Xr coretemp 4 ,
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366660 - head/stand/libsa/zfs

2020-10-12 Thread Warner Losh
Author: imp
Date: Tue Oct 13 04:37:57 2020
New Revision: 30
URL: https://svnweb.freebsd.org/changeset/base/30

Log:
  Force __BMI__ experimental instructions off.
  
  The OpenZFS code that uses the BMI instructions is broken. Forcibly
  disable them to prevent their use. When enabled, the build breaks.
  This fixes the build when compiled for a core with BMI instructions.
  This is the same fix committed in r364777, for the same issue.
  
  Submitted by: Jung-uk Kim

Modified:
  head/stand/libsa/zfs/Makefile.inc

Modified: head/stand/libsa/zfs/Makefile.inc
==
--- head/stand/libsa/zfs/Makefile.inc   Tue Oct 13 03:49:12 2020
(r366659)
+++ head/stand/libsa/zfs/Makefile.inc   Tue Oct 13 04:37:57 2020
(r30)
@@ -31,6 +31,7 @@ CFLAGS_EARLY.zstd_shim.c+= ${ZFS_EARLY}
 CFLAGS.nvlist.c+= -I${ZFSOSINC}/spl
 CFLAGS.zfs.c+= -I${ZFSOSINC}/spl   \
-I${SRCTOP}/sys/cddl/contrib/opensolaris/common/lz4
+CFLAGS.zstd.c+=-U__BMI__
 CFLAGS.zstd_shim.c+= -DIN_BASE -I${OZFS}/include
 
 # Do not unroll skein loops, reduce code size
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366659 - head/stand/libsa/zfs

2020-10-12 Thread Warner Losh
Author: imp
Date: Tue Oct 13 03:49:12 2020
New Revision: 366659
URL: https://svnweb.freebsd.org/changeset/base/366659

Log:
  Add back org.freebsd:zstd_compress to features_for_read
  
  This list is the of features that are allowed on the whole pool,
  not the list of features that are implemented.

Modified:
  head/stand/libsa/zfs/zfsimpl.c

Modified: head/stand/libsa/zfs/zfsimpl.c
==
--- head/stand/libsa/zfs/zfsimpl.c  Tue Oct 13 02:36:16 2020
(r366658)
+++ head/stand/libsa/zfs/zfsimpl.c  Tue Oct 13 03:49:12 2020
(r366659)
@@ -132,9 +132,7 @@ static const char *features_for_read[] = {
"com.delphix:device_removal",
"com.delphix:obsolete_counts",
"com.intel:allocation_classes",
-#ifdef HAS_ZSTD_ZFS
"org.freebsd:zstd_compress",
-#endif
NULL
 };
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366658 - in head: stand/libsa/zfs sys/cddl/boot/zfs

2020-10-12 Thread Warner Losh
Author: imp
Date: Tue Oct 13 02:36:16 2020
New Revision: 366658
URL: https://svnweb.freebsd.org/changeset/base/366658

Log:
  Turn off zstd on aarch64
  
  loader support for zstd and zfs doesn't work for aarch64. Disable it
  to unbreak the build.

Modified:
  head/stand/libsa/zfs/Makefile.inc
  head/stand/libsa/zfs/zfsimpl.c
  head/sys/cddl/boot/zfs/zfssubr.c

Modified: head/stand/libsa/zfs/Makefile.inc
==
--- head/stand/libsa/zfs/Makefile.inc   Mon Oct 12 22:19:07 2020
(r366657)
+++ head/stand/libsa/zfs/Makefile.inc   Tue Oct 13 02:36:16 2020
(r366658)
@@ -4,7 +4,11 @@
 .PATH: ${SYSDIR}/crypto/skein
 .PATH: ${ZFSOSSRC}/spl
 .PATH: ${OZFS}/module/zstd/lib
-ZFSSRC=zfs.c nvlist.c skein.c skein_block.c list.c zstd_shim.c 
zstd.c
+ZFSSRC=zfs.c nvlist.c skein.c skein_block.c list.c
+.if ${MACHINE_ARCH} != aarch64
+ZFSSRC+=   zstd_shim.c zstd.c
+CFLAGS+=   -DHAS_ZSTD_ZFS
+.endif
 SRCS+= ${ZFSSRC}
 
 CFLAGS+=   -I${LDRSRC}

Modified: head/stand/libsa/zfs/zfsimpl.c
==
--- head/stand/libsa/zfs/zfsimpl.c  Mon Oct 12 22:19:07 2020
(r366657)
+++ head/stand/libsa/zfs/zfsimpl.c  Tue Oct 13 02:36:16 2020
(r366658)
@@ -42,7 +42,9 @@ __FBSDID("$FreeBSD$");
 #include "zfsimpl.h"
 #include "zfssubr.c"
 
+#ifdef HAS_ZSTD_ZFS
 extern int zstd_init(void);
+#endif
 
 struct zfsmount {
const spa_t *spa;
@@ -130,7 +132,9 @@ static const char *features_for_read[] = {
"com.delphix:device_removal",
"com.delphix:obsolete_counts",
"com.intel:allocation_classes",
+#ifdef HAS_ZSTD_ZFS
"org.freebsd:zstd_compress",
+#endif
NULL
 };
 
@@ -171,7 +175,9 @@ zfs_init(void)
dnode_cache_buf = malloc(SPA_MAXBLOCKSIZE);
 
zfs_init_crc();
+#ifdef HAS_ZSTD_ZFS
zstd_init();
+#endif
 }
 
 static int

Modified: head/sys/cddl/boot/zfs/zfssubr.c
==
--- head/sys/cddl/boot/zfs/zfssubr.cMon Oct 12 22:19:07 2020
(r366657)
+++ head/sys/cddl/boot/zfs/zfssubr.cTue Oct 13 02:36:16 2020
(r366658)
@@ -105,10 +105,11 @@ typedef struct zio_checksum_info {
 #include "sha256.c"
 #include "skein_zfs.c"
 
+#ifdef HAS_ZSTD_ZFS
 extern int zfs_zstd_decompress(void *s_start, void *d_start, size_t s_len,
 size_t d_len, int n);
+#endif
 
-
 static zio_checksum_info_t zio_checksum_table[ZIO_CHECKSUM_FUNCTIONS] = {
{{NULL, NULL}, NULL, NULL, 0, "inherit"},
{{NULL, NULL}, NULL, NULL, 0, "on"},
@@ -183,7 +184,9 @@ static zio_compress_info_t zio_compress_table[ZIO_COMP
{NULL,  NULL,   9,  "gzip-9"},
{NULL,  zle_decompress, 64, "zle"},
{NULL,  lz4_decompress, 0,  "lz4"},
+#ifdef HAS_ZSTD_ZFS
{NULL,  zfs_zstd_decompress, ZIO_ZSTD_LEVEL_DEFAULT, 
"zstd"}
+#endif
 };
 
 static void
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366657 - in head: stand/efi/boot1 stand/libsa/zfs sys/cddl/boot/zfs sys/cddl/contrib/opensolaris/uts/common/os sys/contrib/openzfs/include/os/freebsd/linux sys/contrib/openzfs/include/...

2020-10-12 Thread Warner Losh
/zfsimpl.c  Mon Oct 12 22:07:44 2020
(r366656)
+++ head/stand/libsa/zfs/zfsimpl.c  Mon Oct 12 22:19:07 2020
(r366657)
@@ -42,6 +42,7 @@ __FBSDID("$FreeBSD$");
 #include "zfsimpl.h"
 #include "zfssubr.c"
 
+extern int zstd_init(void);
 
 struct zfsmount {
const spa_t *spa;
@@ -170,6 +171,7 @@ zfs_init(void)
dnode_cache_buf = malloc(SPA_MAXBLOCKSIZE);
 
zfs_init_crc();
+   zstd_init();
 }
 
 static int

Copied and modified: head/stand/libsa/zfs/zstd_shim.c (from r366656, 
head/sys/contrib/openzfs/include/os/freebsd/spl/sys/kmem_cache.h)
==
--- head/sys/contrib/openzfs/include/os/freebsd/spl/sys/kmem_cache.hMon Oct 
12 22:07:44 2020(r366656, copy source)
+++ head/stand/libsa/zfs/zstd_shim.cMon Oct 12 22:19:07 2020
(r366657)
@@ -1,6 +1,5 @@
-/*
- * Copyright (c) 2020 iXsystems, Inc.
- * All rights reserved.
+/*-
+ * Copyright (c) 2020 M. Warner Losh 
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -11,10 +10,10 @@
  *notice, this list of conditions and the following disclaimer in the
  *documentation and/or other materials provided with the distribution.
  *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
  * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
  * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
@@ -23,27 +22,19 @@
  * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  * SUCH DAMAGE.
  *
- * $FreeBSD$
  */
+#include 
+__FBSDID("$FreeBSD$");
 
+/*
+ * Small amount of shim code needed to get zfs_zstd.c to compile. These items
+ * here should all be defined in the SPL or as part of libstand somewhere, but
+ * aren't for reasons that haven't been tracked down yet. Ideally, they would
+ * all go away and we'd compile zfs_zstd.c directly. Based on an original by
+ * Matt Macey, but only the #include remains untouched from that.
+ */
 
-#ifndef _SPL_KMEM_CACHE_H
-#define_SPL_KMEM_CACHE_H
+#define ZFS_MODULE_PARAM_ARGS void
+typedef int boolean_t; /* This one may be tough to get rid of */
 
-#include 
-
-/* kmem move callback return values */
-typedef enum kmem_cbrc {
-   KMEM_CBRC_YES   = 0,/* Object moved */
-   KMEM_CBRC_NO= 1,/* Object not moved */
-   KMEM_CBRC_LATER = 2,/* Object not moved, try again later */
-   KMEM_CBRC_DONT_NEED = 3,/* Neither object is needed */
-   KMEM_CBRC_DONT_KNOW = 4,/* Object unknown */
-} kmem_cbrc_t;
-
-extern void spl_kmem_cache_set_move(kmem_cache_t *,
-kmem_cbrc_t (*)(void *, void *, size_t, void *));
-
-#definekmem_cache_set_move(skc, move)  spl_kmem_cache_set_move(skc, 
move)
-
-#endif
+#include 

Modified: head/sys/cddl/boot/zfs/zfsimpl.h
==
--- head/sys/cddl/boot/zfs/zfsimpl.hMon Oct 12 22:07:44 2020
(r366656)
+++ head/sys/cddl/boot/zfs/zfsimpl.hMon Oct 12 22:19:07 2020
(r366657)
@@ -611,7 +611,61 @@ enum zio_compress {
ZIO_COMPRESS_GZIP_9,
ZIO_COMPRESS_ZLE,
ZIO_COMPRESS_LZ4,
+   ZIO_COMPRESS_ZSTD,
ZIO_COMPRESS_FUNCTIONS
+};
+
+enum zio_zstd_levels {
+   ZIO_ZSTD_LEVEL_INHERIT = 0,
+   ZIO_ZSTD_LEVEL_1,
+#defineZIO_ZSTD_LEVEL_MIN  ZIO_ZSTD_LEVEL_1
+   ZIO_ZSTD_LEVEL_2,
+   ZIO_ZSTD_LEVEL_3,
+#defineZIO_ZSTD_LEVEL_DEFAULT  ZIO_ZSTD_LEVEL_3
+   ZIO_ZSTD_LEVEL_4,
+   ZIO_ZSTD_LEVEL_5,
+   ZIO_ZSTD_LEVEL_6,
+   ZIO_ZSTD_LEVEL_7,
+   ZIO_ZSTD_LEVEL_8,
+   ZIO_ZSTD_LEVEL_9,
+   ZIO_ZSTD_LEVEL_10,
+   ZIO_ZSTD_LEVEL_11,
+   ZIO_ZSTD_LEVEL_12,
+   ZIO_ZSTD_LEVEL_13,
+   ZIO_ZSTD_LEVEL_14,
+   ZIO_ZSTD_LEVEL_15,
+   ZIO_ZSTD_LEVEL_16,
+   ZIO_ZSTD_LEVEL_17,
+   ZIO_ZSTD_LEVEL_18,
+   ZIO_ZSTD_LEVEL_19,
+#defineZIO_ZSTD_LEVEL_MAX  ZIO_ZSTD_LEVEL_19
+   ZIO_ZSTD_LEVEL_RESERVE = 101, /* Leave room for new positive levels */
+   ZIO_ZSTD_LEVEL_FAST, /* Fast levels are negative */
+   ZIO_ZSTD_LEVEL_FAST_1,
+#defineZIO_ZSTD_LEVEL_FAST_DEFAULT ZIO_ZSTD_LEVEL_FAST_1
+   ZIO_ZSTD_LEVEL_FAST_2,
+   ZIO_ZSTD_LEVEL_FAST_3,
+   ZIO_ZSTD_LEVEL_FAST_4,
+   ZIO_ZSTD_LEV

svn commit: r366656 - head/sys/kern

2020-10-12 Thread Warner Losh
Author: imp
Date: Mon Oct 12 22:07:44 2020
New Revision: 366656
URL: https://svnweb.freebsd.org/changeset/base/366656

Log:
  newbus: use ssize_t to match sb's len and size, fix ordering of space check
  
  Both s_len and s_size are ssize_t, so their differece is also more
  properly a ssize_t not a size_t. Also, assert that len is <= size when
  we enter. This should always be the case. Ensure that we have that one
  byte that we write to the end of the buffer before we do so, though
  the error should already be set on the buffer if not, and the only
  times we supply 'partial' buffers they should be plenty large.
  
  Reviewed by: cem, jhb (prior version, I did cem's suggestion)
  Differential Revsion: https://reviews.freebsd.org/D26752

Modified:
  head/sys/kern/subr_bus.c

Modified: head/sys/kern/subr_bus.c
==
--- head/sys/kern/subr_bus.cMon Oct 12 21:35:29 2020(r366655)
+++ head/sys/kern/subr_bus.cMon Oct 12 22:07:44 2020(r366656)
@@ -4956,18 +4956,19 @@ static int
 bus_child_pnpinfo_sb(device_t dev, struct sbuf *sb)
 {
char *p;
-   size_t space;
+   ssize_t space;
 
MPASS((sb->s_flags & SBUF_INCLUDENUL) == 0);
+   MPASS(sb->s_size >= sb->s_len);
if (sb->s_error != 0)
return (-1);
-   p = EOB(sb);
-   *p = '\0';  /* sbuf buffer isn't NUL terminated until sbuf_finish() 
*/
space = SPACE(sb);
if (space <= 1) {
sb->s_error = ENOMEM;
return (-1);
}
+   p = EOB(sb);
+   *p = '\0';  /* sbuf buffer isn't NUL terminated until sbuf_finish() 
*/
bus_child_pnpinfo_str(dev, p, space);
sb->s_len += strlen(p);
return (0);
@@ -4985,18 +4986,19 @@ static int
 bus_child_location_sb(device_t dev, struct sbuf *sb)
 {
char *p;
-   size_t space;
+   ssize_t space;
 
MPASS((sb->s_flags & SBUF_INCLUDENUL) == 0);
+   MPASS(sb->s_size >= sb->s_len);
if (sb->s_error != 0)
return (-1);
-   p = EOB(sb);
-   *p = '\0';  /* sbuf buffer isn't NUL terminated until sbuf_finish() 
*/
space = SPACE(sb);
if (space <= 1) {
sb->s_error = ENOMEM;
return (-1);
}
+   p = EOB(sb);
+   *p = '\0';  /* sbuf buffer isn't NUL terminated until sbuf_finish() 
*/
bus_child_location_str(dev, p, space);
sb->s_len += strlen(p);
return (0);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366629 - head/sys/sys

2020-10-11 Thread Warner Losh
Author: imp
Date: Mon Oct 12 05:56:29 2020
New Revision: 366629
URL: https://svnweb.freebsd.org/changeset/base/366629

Log:
  systm.h: forward declare ucred for _STANDALONE too
  
  There's a number of types we forward declare for the kernel. We need
  struct ucred for the ZSTD ZFS integration, so go ahead and forward
  declare it here too.

Modified:
  head/sys/sys/systm.h

Modified: head/sys/sys/systm.h
==
--- head/sys/sys/systm.hSun Oct 11 16:01:16 2020(r366628)
+++ head/sys/sys/systm.hMon Oct 12 05:56:29 2020(r366629)
@@ -124,6 +124,7 @@ voidvpanic(const char *, __va_list) __dead2 
__printfl
 
 
 #if defined(_STANDALONE)
+struct ucred;
 /*
  * Until we have more experience with KASSERTS that are called
  * from the boot loader, they are off. The bootloader does this
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366626 - head/sbin/reboot

2020-10-11 Thread Warner Losh
On Sun, Oct 11, 2020, 8:13 PM Alexey Dokuchaev  wrote:

> On Sun, Oct 11, 2020 at 09:12:43AM -0600, Warner Losh wrote:
> > ...
> > There were cases that were discussed when the feature went in that
> > required it to be removed in some failure modes for full functionality.
> > I don't recall if they were in the rc thread or somewhere else.
>
> You mean, literally delete the file, that is, nextboot_enable="NO" can
> not be enough?
>

Yes. Sometimes it's not reliably written in some failure scenarios. In
those cases it must be deleted.

> And honestly, nextboot.conf is special in so many ways. We have no
> > unlink in the loader for UFS and no write for ZFS or MSDOS. In those
>
> What's the problem with in-place overwrite in the FAT case?
>

Last I checked, it wasn't implemented. It could be done, but hasn't been.

> cases, the rm from rc is what you want
>
> I still don't understand how could rm be better than graceful disabling
> alternative configuration with nextboot_enable="NO".  I most certainly
> do *not* like when my custom config files are being removed, especially
> silently.  When I see nextboot_enable="NO" I know that the file
> had been processed, and processed by the machine, not me (since I would
> never add trailing space).  When I don't see the file, I'd be questioning
> myself if I've ever added it here, or maybe I put in the wrong location.
>

Nextboot.conf is special. It will be deleted. It doesn't belong to you, it
belongs to nextboot(8).

> I'm not likely to remove it, but if UFS grows unlink in the future,
> > this man page will need to change.
>
> Just because it's easier to implemented unlink for UFS then (over)write
> for ZFS?
>

Both are hard in ZFS. Unlink has issues that I hadn't recalled, so that
path is unlikely...

> Then again, all the loser [loader?] man pages need a complete rewrite,
> > or close to it.
>
> Personally I find them quite useful, except when they contradict the
> reality (like this time).  In these cases, I'd fix them.
>

For now, it's fine.

Warner

>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366626 - head/sbin/reboot

2020-10-11 Thread Warner Losh
On Sun, Oct 11, 2020, 8:00 AM Kyle Evans  wrote:

> On Sun, Oct 11, 2020 at 8:30 AM Alexey Dokuchaev 
> wrote:
> >
> > On Sun, Oct 11, 2020 at 04:08:09PM +0300, Toomas Soome wrote:
> > > > On 11. Oct 2020, at 16:01, Alexey Dokuchaev wrote:
> > > >> ...
> > > >> Also nextboot.conf not generic configuration file (such as
> loader.conf
> > > >> or loader.conf.local), but the implementation specific file, part of
> > > >> special feature.
> > > >>
> > > >> That is, one should not assume the presence of nextboot.conf file,
> make
> > > >> assumptions about its content, or perform manual edits on it.
> > > >
> > > > Do we want it to be the second-class citizen like this?  Would it
> make
> > > > better sense by documenting it more completely instead?
> > >
> > > It is not really about being second-class citizen, it really is about
> if
> > > and how we can implement the feature. With UFS there is a limited write
> > > (write to existing, allocated disk blocks), with ZFS there is no write
> to
> > > file system at all.
> >
> > I see; that would explain why loader(8) replaces the "YES" ->
> "NO",
> > but I guess I'd have to read the discussion on -rc@ which lead to
> r177062,
> > because I don't see the reason for it to be removed (twice) if it's being
> > disabled by the loader(8) earlier anyway.
> >
>
> IMO both steps are important. You have to (at least try to) disable it
> in case it doesn't get you all the way to multi-user, but then you
> don't want the old contents of nextboot.conf being inadvertently used
> on another boot if someone's habitually `nextboot -a`ing.
>

There were cases that were discussed when the geature went in that required
it to be removed in some failure modes for full functionality. I don't
recall if they were in the rc thread or somewhere else.

And honestly, nextboot.conf is special in so many ways. We have no unlink
in the loader for UFS and no write for ZFS or MSDOS. In those cases, the rm
from rc is what you want (though lately we use a different mechanism for
ZFS).

So the docs were right before, in the big picture. The implementation
detail now enshrined there is unwise. I'm not likely to remove it, but if
UFS grows unlink in the future, this man page will need to change.

Then again, all the loser man pages need a complete rewrite, or close to it.

Warner

>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366578 - head/sbin/devd

2020-10-09 Thread Warner Losh
On Fri, Oct 9, 2020 at 12:47 PM Warner Losh  wrote:

>
>
> On Fri, Oct 9, 2020, 12:20 PM Renato Botelho  wrote:
>
>> On 09/10/20 15:16, Renato Botelho wrote:
>> > On 09/10/20 13:57, Warner Losh wrote:
>> >>
>> >>
>> >> On Fri, Oct 9, 2020 at 10:19 AM Renato Botelho > >> <mailto:ga...@freebsd.org>> wrote:
>> >>
>> >> On 09/10/20 12:29, Warner Losh wrote:
>> >>  > Author: imp
>> >>  > Date: Fri Oct  9 15:29:05 2020
>> >>  > New Revision: 366578
>> >>  > URL: https://svnweb.freebsd.org/changeset/base/366578
>> >> <https://svnweb.freebsd.org/changeset/base/366578>
>> >>  >
>> >>  > Log:
>> >>  >Avoid using single quotes in arguments to logger.
>> >>  >
>> >>  >Single quotes interfere with the workaround put in with
>> >> r335753 and
>> >>  >aren't necessary in this case. I believe that all the
>> >> underling issues
>> >>  >with r335753 have been corrected, but need to do more
>> extensive
>> >>  >followup before reverting it as a bad idea.
>> >>
>> >> Hi Warner,
>> >>
>> >> How to proceed if it's needed to pass multiple parameters to a
>> >> command
>> >> in following format?
>> >>
>> >> cmd param1 'param2 has spaces and a $variable'
>> >>
>> >>
>> >> action "cmd param1 'param2 has spaces and a '$variable";
>> >>
>> >> should do the trick. I'm documenting this now...
>> >
>> > It worked!! Thanks!
>>
>> Oooops, too fast.
>>
>> I wrote this script:
>>
>> #!/bin/sh
>>
>> echo "Param1 = '${1}'" >> /root/log
>> echo "Param2 = '${2}'" >> /root/log
>>
>> And added this action on devd config:
>>
>> notify 0 {
>>  match "system"  "IFNET";
>>  match "type""LINK_UP";
>>  media-type  "ethernet";
>> action "/root/log.sh -c 'interface linkup start '$subsystem";
>> };
>>
>> notify 0 {
>>  match "system"  "IFNET";
>> match "type""LINK_DOWN";
>> media-type  "ethernet";
>> action "/root/log.sh -c 'interface linkup stop '$subsystem";
>> };
>>
>> And got the following output on /root/log:
>>
>> Param1 = '-c'
>> Param2 = 'interface linkup start $em0'
>>
>
> Doh. I'll dig deeper.
>

It works for me. Did you remember to kill -HUP devd?

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366578 - head/sbin/devd

2020-10-09 Thread Warner Losh
On Fri, Oct 9, 2020, 12:20 PM Renato Botelho  wrote:

> On 09/10/20 15:16, Renato Botelho wrote:
> > On 09/10/20 13:57, Warner Losh wrote:
> >>
> >>
> >> On Fri, Oct 9, 2020 at 10:19 AM Renato Botelho  >> <mailto:ga...@freebsd.org>> wrote:
> >>
> >> On 09/10/20 12:29, Warner Losh wrote:
> >>  > Author: imp
> >>  > Date: Fri Oct  9 15:29:05 2020
> >>  > New Revision: 366578
> >>  > URL: https://svnweb.freebsd.org/changeset/base/366578
> >> <https://svnweb.freebsd.org/changeset/base/366578>
> >>  >
> >>  > Log:
> >>  >Avoid using single quotes in arguments to logger.
> >>  >
> >>  >Single quotes interfere with the workaround put in with
> >> r335753 and
> >>  >aren't necessary in this case. I believe that all the
> >> underling issues
> >>  >with r335753 have been corrected, but need to do more
> extensive
> >>  >followup before reverting it as a bad idea.
> >>
> >> Hi Warner,
> >>
> >> How to proceed if it's needed to pass multiple parameters to a
> >> command
> >> in following format?
> >>
> >> cmd param1 'param2 has spaces and a $variable'
> >>
> >>
> >> action "cmd param1 'param2 has spaces and a '$variable";
> >>
> >> should do the trick. I'm documenting this now...
> >
> > It worked!! Thanks!
>
> Oooops, too fast.
>
> I wrote this script:
>
> #!/bin/sh
>
> echo "Param1 = '${1}'" >> /root/log
> echo "Param2 = '${2}'" >> /root/log
>
> And added this action on devd config:
>
> notify 0 {
>  match "system"  "IFNET";
>  match "type""LINK_UP";
>  media-type  "ethernet";
> action "/root/log.sh -c 'interface linkup start '$subsystem";
> };
>
> notify 0 {
>  match "system"  "IFNET";
> match "type""LINK_DOWN";
> media-type  "ethernet";
> action "/root/log.sh -c 'interface linkup stop '$subsystem";
> };
>
> And got the following output on /root/log:
>
> Param1 = '-c'
> Param2 = 'interface linkup start $em0'
>

Doh. I'll dig deeper.

Warner

>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366578 - head/sbin/devd

2020-10-09 Thread Warner Losh
On Fri, Oct 9, 2020 at 10:19 AM Renato Botelho  wrote:

> On 09/10/20 12:29, Warner Losh wrote:
> > Author: imp
> > Date: Fri Oct  9 15:29:05 2020
> > New Revision: 366578
> > URL: https://svnweb.freebsd.org/changeset/base/366578
> >
> > Log:
> >Avoid using single quotes in arguments to logger.
> >
> >Single quotes interfere with the workaround put in with r335753 and
> >aren't necessary in this case. I believe that all the underling issues
> >with r335753 have been corrected, but need to do more extensive
> >followup before reverting it as a bad idea.
>
> Hi Warner,
>
> How to proceed if it's needed to pass multiple parameters to a command
> in following format?
>
> cmd param1 'param2 has spaces and a $variable'
>

action "cmd param1 'param2 has spaces and a '$variable";

should do the trick. I'm documenting this now...

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366579 - head/sbin/devd

2020-10-09 Thread Warner Losh
Author: imp
Date: Fri Oct  9 15:45:34 2020
New Revision: 366579
URL: https://svnweb.freebsd.org/changeset/base/366579

Log:
  Remove gratuitous use of '' around arguments
  
  There's no need to use ' here, so remove it. This use causes no
  problems, but is a bad example.

Modified:
  head/sbin/devd/devd.conf

Modified: head/sbin/devd/devd.conf
==
--- head/sbin/devd/devd.confFri Oct  9 15:29:05 2020(r366578)
+++ head/sbin/devd/devd.confFri Oct  9 15:45:34 2020(r366579)
@@ -229,7 +229,7 @@ notify 10 {
match "system"  "ACPI";
match "subsystem"   "Thermal";
match "notify"  "0xcc";
-   action "logger -p kern.emerg 'WARNING: system temperature too high, 
shutting down soon!'";
+   action "logger -p kern.emerg WARNING: system temperature too high, 
shutting down soon!";
 };
 
 # User requested suspend, so perform preparation steps and then execute
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366578 - head/sbin/devd

2020-10-09 Thread Warner Losh
Author: imp
Date: Fri Oct  9 15:29:05 2020
New Revision: 366578
URL: https://svnweb.freebsd.org/changeset/base/366578

Log:
  Avoid using single quotes in arguments to logger.
  
  Single quotes interfere with the workaround put in with r335753 and
  aren't necessary in this case. I believe that all the underling issues
  with r335753 have been corrected, but need to do more extensive
  followup before reverting it as a bad idea.
  
  PR: 240411
  MFC After: 2 days (to give it time to get into 12.2)

Modified:
  head/sbin/devd/zfs.conf

Modified: head/sbin/devd/zfs.conf
==
--- head/sbin/devd/zfs.conf Fri Oct  9 15:27:37 2020(r366577)
+++ head/sbin/devd/zfs.conf Fri Oct  9 15:29:05 2020(r366578)
@@ -5,73 +5,73 @@
 notify 10 {
match "system"  "ZFS";
match "type""ereport.fs.zfs.checksum";
-   action "logger -p local7.warn -t ZFS 'checksum mismatch, zpool=$pool 
path=$vdev_path offset=$zio_offset size=$zio_size'";
+   action "logger -p local7.warn -t ZFS checksum mismatch, zpool=$pool 
path=$vdev_path offset=$zio_offset size=$zio_size";
 };
 
 notify 10 {
match "system"  "ZFS";
match "type""ereport.fs.zfs.io";
-   action "logger -p local7.warn -t ZFS 'vdev I/O failure, zpool=$pool 
path=$vdev_path offset=$zio_offset size=$zio_size error=$zio_err'";
+   action "logger -p local7.warn -t ZFS vdev I/O failure, zpool=$pool 
path=$vdev_path offset=$zio_offset size=$zio_size error=$zio_err";
 };
 
 notify 10 {
match "system"  "ZFS";
match "type""ereport.fs.zfs.data";
-   action "logger -p local7.warn -t ZFS 'pool I/O failure, zpool=$pool 
error=$zio_err'";
+   action "logger -p local7.warn -t ZFS pool I/O failure, zpool=$pool 
error=$zio_err";
 };
 
 notify 10 {
match "system"  "ZFS";
match "type""ereport.fs.zfs.zpool";
-   action "logger -p local7.err -t ZFS 'failed to load zpool $pool'";
+   action "logger -p local7.err -t ZFS failed to load zpool $pool";
 };
 
 notify 10 {
match "system"  "ZFS";
match "type""ereport.fs.zfs.vdev\..*";
-   action "logger -p local7.err -t ZFS 'vdev problem, zpool=$pool 
path=$vdev_path type=$type'";
+   action "logger -p local7.err -t ZFS vdev problem, zpool=$pool 
path=$vdev_path type=$type";
 };
 
 notify 10 {
match "system"  "ZFS";
match "type""ereport.fs.zfs.io_failure";
-   action "logger -p local7.alert -t ZFS 'catastrophic pool I/O failure, 
zpool=$pool'";
+   action "logger -p local7.alert -t ZFS catastrophic pool I/O failure, 
zpool=$pool";
 };
 
 notify 10 {
match "system"  "ZFS";
match "type""ereport.fs.zfs.probe_failure";
-   action "logger -p local7.err -t ZFS 'vdev probe failure, zpool=$pool 
path=$vdev_path'";
+   action "logger -p local7.err -t ZFS vdev probe failure, zpool=$pool 
path=$vdev_path";
 };
 
 notify 10 {
match "system"  "ZFS";
match "type""ereport.fs.zfs.log_replay";
-   action "logger -p local7.err -t ZFS 'pool log replay failure, 
zpool=$pool'";
+   action "logger -p local7.err -t ZFS pool log replay failure, 
zpool=$pool";
 };
 
 notify 10 {
match "system"  "ZFS";
match "type""ereport.fs.zfs.config_cache_write";
-   action "logger -p local7.warn -t ZFS 'failed to write zpool.cache, 
zpool=$pool'";
+   action "logger -p local7.warn -t ZFS failed to write zpool.cache, 
zpool=$pool";
 };
 
 
 notify 10 {
match "system"  "ZFS";
match "type""resource.fs.zfs.removed";
-   action "logger -p local7.notice -t ZFS 'vdev is removed, 
pool_guid=$pool_guid vdev_guid=$vdev_guid'";
+   action "logger -p local7.notice -t ZFS vdev is removed, 
pool_guid=$pool_guid vdev_guid=$vdev_guid";
 };
 
 notify 10 {
match "system"  "ZFS";
match "type""resource.fs.zfs.autoreplace";
-   action "logger -p local7.info -t ZFS 'autoreplace is configured for 
vdev, pool_guid=$pool_guid vdev_guid=$vdev_guid'";
+   action "logger -p local7.info -t ZFS autoreplace is configured for 
vdev, pool_guid=$pool_guid vdev_guid=$vdev_guid";
 };
 
 notify 10 {
match "system"  "ZFS";
match "type""resource.fs.zfs.statechange";
-   action "logger -p local7.notice -t ZFS 'vdev state changed, 
pool_guid=$pool_guid vdev_guid=$vdev_guid'";
+   action "logger -p local7.notice -t ZFS vdev state changed, 
pool_guid=$pool_guid vdev_guid=$vdev_guid";
 };
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366560 - head/sys/conf

2020-10-08 Thread Warner Losh
Author: imp
Date: Fri Oct  9 01:48:21 2020
New Revision: 366560
URL: https://svnweb.freebsd.org/changeset/base/366560

Log:
  Remove now-unused files
  
  makeLINT.mk isn't needed or used anymore, remove it and all the files
  it uses.
  
  Reviewed by: kevans
  Differential Revision: https://reviews.freebsd.org/D26540

Deleted:
  head/sys/conf/makeLINT.mk
  head/sys/conf/makeLINT.sed
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366559 - in head: . sys/amd64/conf sys/arm/conf sys/arm64/conf sys/i386/conf sys/powerpc/conf

2020-10-08 Thread Warner Losh
Author: imp
Date: Fri Oct  9 01:48:14 2020
New Revision: 366559
URL: https://svnweb.freebsd.org/changeset/base/366559

Log:
  Create in-tree LINT files
  
  Now that config(8) has supported include for 19 years, transition to
  including the NOTES files. include support didn't exist at the time,
  nor did the envvar stuff recently added. Now that it does, eliminate
  the building of LINT files by just including everything you need.
  
  Note: This may cause conflicts with updating in some cases.
find sys -name LINT\* -rm
  is suggested across this commit to remove the generated LINT
  files.
  
  Reviewed by: kevans
  Differential Revision: https://reviews.freebsd.org/D26540

Added:
  head/sys/amd64/conf/LINT   (contents, props changed)
  head/sys/amd64/conf/LINT-NOINET   (contents, props changed)
  head/sys/amd64/conf/LINT-NOINET6   (contents, props changed)
  head/sys/amd64/conf/LINT-NOIP   (contents, props changed)
  head/sys/arm/conf/LINT   (contents, props changed)
  head/sys/arm64/conf/LINT   (contents, props changed)
  head/sys/i386/conf/LINT   (contents, props changed)
  head/sys/i386/conf/LINT-NOINET   (contents, props changed)
  head/sys/i386/conf/LINT-NOINET6   (contents, props changed)
  head/sys/i386/conf/LINT-NOIP   (contents, props changed)
  head/sys/powerpc/conf/LINT   (contents, props changed)
  head/sys/powerpc/conf/LINT64   (contents, props changed)
Deleted:
  head/sys/amd64/conf/Makefile
  head/sys/arm/conf/Makefile
  head/sys/arm64/conf/Makefile
  head/sys/i386/conf/Makefile
  head/sys/powerpc/conf/Makefile
Modified:
  head/UPDATING

Modified: head/UPDATING
==
--- head/UPDATING   Fri Oct  9 01:37:17 2020(r366558)
+++ head/UPDATING   Fri Oct  9 01:48:14 2020(r366559)
@@ -26,6 +26,19 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
world, or to merely disable the most expensive debugging functionality
at runtime, run "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
 
+20200923:
+   LINT files are no longer generated. We now include the relevant NOTES
+   files. Note: This may cause conflicts with updating in some cases.
+   find sys -name LINT\* -rm
+   is suggested across this commit to remove the generated LINT files.
+
+   If you have tried to update with generated files there, the svn
+   command you want to un-auger the tree is
+   cd sys/amd64/conf
+   svn revert -R .
+   and then do the above find from the top level. Substitute 'amd64'
+   above with where the error message indicates a conflict.
+
 20200824:
OpenZFS support has been integrated. Do not upgrade root pools until
the loader is updated to support zstd. Furthermore, we caution against

Added: head/sys/amd64/conf/LINT
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/sys/amd64/conf/LINTFri Oct  9 01:48:14 2020(r366559)
@@ -0,0 +1,5 @@
+# $FreeBSD$
+
+include "../../conf/NOTES"
+include "../../x86/conf/NOTES"
+include NOTES

Added: head/sys/amd64/conf/LINT-NOINET
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/sys/amd64/conf/LINT-NOINET Fri Oct  9 01:48:14 2020
(r366559)
@@ -0,0 +1,8 @@
+# $FreeBSD$
+
+include LINT
+ident LINT-NOINET
+makeoptions MKMODULESENV+="WITHOUT_INET_SUPPORT="
+nooptions INET
+nodevice gre
+nodevice netmap

Added: head/sys/amd64/conf/LINT-NOINET6
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/sys/amd64/conf/LINT-NOINET6Fri Oct  9 01:48:14 2020
(r366559)
@@ -0,0 +1,6 @@
+# $FreeBSD$
+
+include LINT
+ident LINT-NOINET6
+makeoptions MKMODULESENV+="WITHOUT_INET6_SUPPORT="
+nooptions INET6

Added: head/sys/amd64/conf/LINT-NOIP
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/sys/amd64/conf/LINT-NOIP   Fri Oct  9 01:48:14 2020
(r366559)
@@ -0,0 +1,21 @@
+# $FreeBSD$
+
+include LINT
+ident LINT-NOIP
+makeoptions MKMODULESENV+="WITHOUT_INET_SUPPORT="
+makeoptions MKMODULESENV+="WITHOUT_INET6_SUPPORT="
+nooptions INET
+nooptions INET6
+nodevice age
+nodevice alc
+nodevice ale
+nodevice bxe
+nodevice em
+nodevice fxp
+nodevice jme
+nodevice msk
+nodevice mxge
+nodevice sge
+nodevice sk
+nodevice txp
+nodevice netmap

Added: head/sys/arm/conf/LINT
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/sys/arm/conf/LINT  Fri Oct  9 01:48:14 2020(r366559)
@@ -0,0 +1,4 @@
+# $FreeBSD$
+
+include "../../conf/NOTES"

svn commit: r366555 - head

2020-10-08 Thread Warner Losh
Author: imp
Date: Fri Oct  9 00:27:40 2020
New Revision: 366555
URL: https://svnweb.freebsd.org/changeset/base/366555

Log:
  Eliminate building LINT makefiles
  
  LINT config files are about to be checked in directly. Eliminate
  building them by hand here from NOTES files.
  
  Reviewed by: kevans
  Differential Revision: https://reviews.freebsd.org/D26540

Modified:
  head/Makefile

Modified: head/Makefile
==
--- head/Makefile   Fri Oct  9 00:16:26 2020(r366554)
+++ head/Makefile   Fri Oct  9 00:27:40 2020(r366555)
@@ -682,13 +682,6 @@ universe_${target}_${target_arch}: universe_${target}_
 universe_${target}_done: universe_${target}_kernels .PHONY
 universe_${target}_kernels: universe_${target}_worlds .PHONY
 universe_${target}_kernels: universe_${target}_prologue .MAKE .PHONY
-   @if [ -e "${KERNSRCDIR}/${target}/conf/NOTES" ]; then \
- (cd ${KERNSRCDIR}/${target}/conf && env __MAKE_CONF=/dev/null \
-   ${SUB_MAKE} LINT \
-   > ${.CURDIR}/_.${target}.makeLINT 2>&1 || \
-   (echo "${target} 'make LINT' failed," \
-   "check _.${target}.makeLINT for details"| ${MAKEFAIL})); \
-   fi
@cd ${.CURDIR}; ${SUB_MAKE} ${.MAKEFLAGS} TARGET=${target} \
universe_kernels
 .endif # ${__DO_KERNELS} == "yes"
@@ -760,9 +753,6 @@ universe_epilogue: .PHONY
fi
 .endif
 .endif
-
-buildLINT: .PHONY
-   ${MAKE} -C ${.CURDIR}/sys/${_TARGET}/conf LINT
 
 .if defined(.PARSEDIR)
 # This makefile does not run in meta mode
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366556 - head

2020-10-08 Thread Warner Losh
Author: imp
Date: Fri Oct  9 00:27:45 2020
New Revision: 366556
URL: https://svnweb.freebsd.org/changeset/base/366556

Log:
  Stop ignoring makeLINT generated files
  
  We're going to check these files in shortly since we don't need to
  generate them anymore. Generated files cause issues for different work
  flows anyway.
  
  Reviewed by: kevans
  Differential Revision: https://reviews.freebsd.org/D26540

Modified:
  head/.gitignore

Modified: head/.gitignore
==
--- head/.gitignore Fri Oct  9 00:27:40 2020(r366555)
+++ head/.gitignore Fri Oct  9 00:27:45 2020(r366556)
@@ -17,19 +17,3 @@ GTAGS
 ID
 cscope.out
 ?cscope.out
-# Ignore LINT generated configs.
-/sys/amd64/conf/LINT
-/sys/amd64/conf/LINT-NOINET
-/sys/amd64/conf/LINT-NOINET6
-/sys/amd64/conf/LINT-NOIP
-/sys/arm/conf/LINT
-/sys/arm/conf/LINT-V5
-/sys/arm/conf/LINT-V7
-/sys/arm64/conf/LINT
-/sys/i386/conf/LINT
-/sys/i386/conf/LINT-NOINET
-/sys/i386/conf/LINT-NOINET6
-/sys/i386/conf/LINT-NOIP
-/sys/powerpc/conf/LINT
-/sys/powerpc/conf/LINT64
-/sys/sparc64/conf/LINT
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366554 - head/usr.sbin/bsdinstall/scripts

2020-10-08 Thread Warner Losh
Author: imp
Date: Fri Oct  9 00:16:26 2020
New Revision: 366554
URL: https://svnweb.freebsd.org/changeset/base/366554

Log:
  Initial support for implementing the bootXXX.efi workaround
  
  Too many version of UEFI firmware (so far only confirmed on amd64)
  don't really support efibootmgr selection of boot. That's the most
  reliable, when it works, since there's no guesswork. However, many do
  not save, unmolested, the variables that efibootmgr sets, so as a
  fallback we also install loader.efi as bootXXX.efi (where XXX is
  either aa64 or x64) if it doesn't already exist in /efi/boot on the
  ESP. The standard only defines this for removable devices, but it's
  almost ubiquitously used as a fallback. Many BIOSes implement a drive
  selection feature that takes over the efibootmgr protocol, rendinering
  it useless (either generally, or for those vendors not on the short
  list). bootxxx.efi works around this. However, we don't install it
  unconditionally there, as that breaks some popular multi-boot setups.
  
  MFC After: 1 week
  Differential Revision: https://reviews.freebsd.org/D26428

Modified:
  head/usr.sbin/bsdinstall/scripts/bootconfig

Modified: head/usr.sbin/bsdinstall/scripts/bootconfig
==
--- head/usr.sbin/bsdinstall/scripts/bootconfig Thu Oct  8 23:59:58 2020
(r366553)
+++ head/usr.sbin/bsdinstall/scripts/bootconfig Fri Oct  9 00:16:26 2020
(r366554)
@@ -124,6 +124,15 @@ if [ "$(uname -m)" = "arm64" ] || [ "$X86_BOOTMETHOD" 
done
fi
 
+   case $(uname -m) in
+   arm64)  ARCHBOOTNAME=aa64 ;;
+   amd64)  ARCHBOOTNAME=x64 ;;
+#  arm)ARCHBOOTNAME=arm ;; # No other support for arm install
+#  i386)   ARCHBOOTNAME=ia32 ;; # no support for this in i386 
kernels, rare machines
+   *)  die "Unsupported arch $(uname -m) for UEFI install"
+   esac
+   BOOTNAME="/EFI/BOOT/BOOT${ARCHBOOTNAME}.EFI"
+
for esp in $ESPS; do
f_dprintf "Formatting /dev/${esp} as FAT32"
newfs_msdos -F 32 -c 1 -L EFISYS "/dev/$esp" > /dev/null 2>&1
@@ -141,6 +150,21 @@ if [ "$(uname -m)" = "arm64" ] || [ "$X86_BOOTMETHOD" 
f_dprintf "Installing loader.efi onto ESP"
mkdir -p "$mntpt/EFI/freebsd"
cp "$BSDINSTALL_CHROOT/boot/loader.efi" 
"${mntpt}/EFI/freebsd/loader.efi"
+
+   #
+   # The following shouldn't be necessary. UEFI defines a way to
+   # specifically select what to boot (which we do via
+   # efibootmgr). However, virtual environments often times lack
+   # support for the NV variables efibootmgr sets. In addition,
+   # some UEFI implementations have features that interfere with
+   # the setting of these variables. To combat that, we install the
+   # default removable media boot file as a fallback if it doesn't
+   # exist. We don't install it all the time since that can
+   # interfere with other installations on the drive (like rEFInd).
+   #
+   if [ ! -f "${mntpt}/${BOOTNAME}" ]; then
+   cp "$BSDINSTALL_CHROOT/boot/loader.efi" 
"${mntpt}/${BOOTNAME}"
+   fi
 
if [ "$num_esps" -gt 1 ]; then
bootlabel="FreeBSD (${esp})"
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366547 - in head/sys: i386/include x86/isa

2020-10-08 Thread Warner Losh
Author: imp
Date: Thu Oct  8 20:56:11 2020
New Revision: 366547
URL: https://svnweb.freebsd.org/changeset/base/366547

Log:
  timer_restore is now unused, remove it
  
  apm was the only consumer of timer_restore. Now that it's gone, this
  can be removed.

Modified:
  head/sys/i386/include/clock.h
  head/sys/x86/isa/clock.c

Modified: head/sys/i386/include/clock.h
==
--- head/sys/i386/include/clock.h   Thu Oct  8 20:56:06 2020
(r366546)
+++ head/sys/i386/include/clock.h   Thu Oct  8 20:56:11 2020
(r366547)
@@ -30,7 +30,6 @@ void  clock_init(void);
  */
 
 void   startrtclock(void);
-void   timer_restore(void);
 void   init_TSC(void);
 void   resume_TSC(void);
 

Modified: head/sys/x86/isa/clock.c
==
--- head/sys/x86/isa/clock.cThu Oct  8 20:56:06 2020(r366546)
+++ head/sys/x86/isa/clock.cThu Oct  8 20:56:11 2020(r366547)
@@ -388,26 +388,6 @@ i8254_restore(void)
set_i8254_freq(MODE_STOP, 0);
 }
 
-#ifndef __amd64__
-/*
- * Restore all the timers non-atomically (XXX: should be atomically).
- *
- * This function is called from pmtimer_resume() to restore all the timers.
- * This should not be necessary, but there are broken laptops that do not
- * restore all the timers on resume. The APM spec was at best vague on the
- * subject.
- * pmtimer is used only with the old APM power management, and not with
- * acpi, which is required for amd64, so skip it in that case.
- */
-void
-timer_restore(void)
-{
-
-   i8254_restore();/* restore i8254_freq and hz */
-   atrtc_restore();/* reenable RTC interrupts */
-}
-#endif
-
 /* This is separate from startrtclock() so that it can be called early. */
 void
 i8254_init(void)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366544 - in head/sys/modules: . apm

2020-10-08 Thread Warner Losh
Author: imp
Date: Thu Oct  8 20:55:55 2020
New Revision: 366544
URL: https://svnweb.freebsd.org/changeset/base/366544

Log:
  Remove apm module
  
  The apm code is about to be removed. Remove the module since it's
  about to be useless.

Deleted:
  head/sys/modules/apm/Makefile
Modified:
  head/sys/modules/Makefile

Modified: head/sys/modules/Makefile
==
--- head/sys/modules/Makefile   Thu Oct  8 18:29:17 2020(r366543)
+++ head/sys/modules/Makefile   Thu Oct  8 20:55:55 2020(r366544)
@@ -41,7 +41,6 @@ SUBDIR=   \
amr \
${_an} \
${_aout} \
-   ${_apm} \
${_arcmsr} \
${_allwinner} \
${_armv8crypto} \
@@ -744,7 +743,6 @@ _vmm=   vmm
 # XXX some of these can move now, but are untested on other architectures.
 _3dfx= 3dfx
 _3dfx_linux=   3dfx_linux
-_apm=  apm
 .if ${MK_SOURCELESS_HOST} != "no"
 _ce=   ce
 .endif
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366546 - in head/sys: conf dev/syscons/apm i386/bios i386/conf

2020-10-08 Thread Warner Losh
Author: imp
Date: Thu Oct  8 20:56:06 2020
New Revision: 366546
URL: https://svnweb.freebsd.org/changeset/base/366546

Log:
  Remove APM BIOS support
  
  APM BIOS was relevant only to early laptops (approximately P166 or
  P200 and slower). These have not been relevant for a long time, and
  this code has been untested for a long time (as far as I can
  tell). The APM compat code in ACPI and the apm(8) command is not being
  retired. Both of these items are still in use (apm(8) is more
  scriptable than the replacement acpiconf, for the most part). This has
  been commented out of i386 GENERIC since 2002. This code is not
  relevant to any other port.
  
  Discussed on: arch@

Deleted:
  head/sys/dev/syscons/apm/apm_saver.c
  head/sys/i386/bios/apm.c
  head/sys/i386/bios/apm.h
Modified:
  head/sys/conf/files.i386
  head/sys/i386/conf/GENERIC
  head/sys/i386/conf/NOTES

Modified: head/sys/conf/files.i386
==
--- head/sys/conf/files.i386Thu Oct  8 20:56:00 2020(r366545)
+++ head/sys/conf/files.i386Thu Oct  8 20:56:06 2020(r366546)
@@ -162,7 +162,6 @@ acpi_wakedata.h optional acpi   
\
no-obj no-implicit-rule before-depend   \
clean   "acpi_wakedata.h"
 #
-i386/bios/apm.coptional apm
 i386/bios/smapi.c  optional smapi
 i386/bios/smapi_bios.S optional smapi
 i386/cloudabi32/cloudabi32_sysvec.coptional compat_cloudabi32

Modified: head/sys/i386/conf/GENERIC
==
--- head/sys/i386/conf/GENERIC  Thu Oct  8 20:56:00 2020(r366545)
+++ head/sys/i386/conf/GENERIC  Thu Oct  8 20:56:06 2020(r366546)
@@ -198,9 +198,6 @@ device  vt_vga
 
 device agp # support several AGP chipsets
 
-# Power management support (see NOTES for more options)
-#deviceapm
-
 # PCCARD (PCMCIA) support
 # PCMCIA and cardbus bridge support
 device cbb # cardbus (yenta) bridge

Modified: head/sys/i386/conf/NOTES
==
--- head/sys/i386/conf/NOTESThu Oct  8 20:56:00 2020(r366545)
+++ head/sys/i386/conf/NOTESThu Oct  8 20:56:06 2020(r366546)
@@ -729,7 +729,6 @@ device  hyperv  # HyperV drivers
 #
 # Miscellaneous hardware:
 #
-# apm: Laptop Advanced Power Management (experimental)
 # ipmi: Intelligent Platform Management Interface
 # smapi: System Management Application Program Interface driver
 # smbios: DMI/SMBIOS entry point
@@ -739,10 +738,6 @@ device hyperv  # HyperV drivers
 # si: Specialix International SI/XIO or SX intelligent serial card driver
 # tpm: Trusted Platform Module
 
-# Notes on APM
-#  The flags takes the following meaning for apm0:
-#0x0020  Statclock is broken.
-
 # Notes on the Specialix SI/XIO driver:
 #  The host card is memory, not IO mapped.
 #  The Rev 1 host cards use a 64K chunk, on a 32K boundary.
@@ -761,8 +756,6 @@ device  hyperv  # HyperV drivers
 #  is the only thing truly supported, but apparently a fair percentage
 #  of the Vaio extra features are controlled by this device.
 
-device apm
-envvar hint.apm.0.flags="0x20"
 device ipmi
 device smapi
 device smbios
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366545 - in head/sys: conf i386/conf modules/syscons modules/syscons/apm

2020-10-08 Thread Warner Losh
Author: imp
Date: Thu Oct  8 20:56:00 2020
New Revision: 366545
URL: https://svnweb.freebsd.org/changeset/base/366545

Log:
  Remove apm screen saver.
  
  APM BIOS support is about to be removed. Remove the apm screen saver
  and its module. They are about to be irrelevant.

Deleted:
  head/sys/modules/syscons/apm/Makefile
Modified:
  head/sys/conf/files.i386
  head/sys/i386/conf/NOTES
  head/sys/modules/syscons/Makefile

Modified: head/sys/conf/files.i386
==
--- head/sys/conf/files.i386Thu Oct  8 20:55:55 2020(r366544)
+++ head/sys/conf/files.i386Thu Oct  8 20:56:00 2020(r366545)
@@ -119,7 +119,6 @@ dev/sbni/if_sbni_isa.c  optional sbni isa
 dev/sbni/if_sbni_pci.c optional sbni pci
 dev/speaker/spkr.c optional speaker
 dev/superio/superio.c  optional superio isa
-dev/syscons/apm/apm_saver.coptional apm_saver apm
 dev/syscons/scvesactl.coptional sc vga vesa
 dev/syscons/scvgarndr.coptional sc vga
 dev/tpm/tpm.c  optional tpm

Modified: head/sys/i386/conf/NOTES
==
--- head/sys/i386/conf/NOTESThu Oct  8 20:55:55 2020(r366544)
+++ head/sys/i386/conf/NOTESThu Oct  8 20:56:00 2020(r366545)
@@ -275,7 +275,6 @@ device  nvram   # Access to rtc cmos 
via /dev/nvram
 device speaker #Play IBM BASIC-style noises out your speaker
 envvar hint.speaker.0.at="isa"
 envvar hint.speaker.0.port="0x61"
-device apm_saver   # Requires APM
 
 
 #

Modified: head/sys/modules/syscons/Makefile
==
--- head/sys/modules/syscons/Makefile   Thu Oct  8 20:55:55 2020
(r366544)
+++ head/sys/modules/syscons/Makefile   Thu Oct  8 20:56:00 2020
(r366545)
@@ -1,7 +1,6 @@
 # $FreeBSD$
 
-SUBDIR=${_apm} \
-   beastie \
+SUBDIR= beastie \
blank \
daemon \
dragon \
@@ -14,9 +13,5 @@ SUBDIR=   ${_apm} \
snake \
star \
warp
-
-.if ${MACHINE_CPUARCH} == "i386"
-_apm=  apm
-.endif
 
 .include 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366541 - head

2020-10-08 Thread Warner Losh
Author: imp
Date: Thu Oct  8 17:30:05 2020
New Revision: 366541
URL: https://svnweb.freebsd.org/changeset/base/366541

Log:
  Race in 32-bit fixed
  
  Use install insteald of install.sh for 32-bit builds to fight races there.
  
  Reviewed by: markj

Modified:
  head/Makefile.libcompat

Modified: head/Makefile.libcompat
==
--- head/Makefile.libcompat Thu Oct  8 16:45:27 2020(r366540)
+++ head/Makefile.libcompat Thu Oct  8 17:30:05 2020(r366541)
@@ -10,7 +10,7 @@ __<${_this:T}>__:
 
 # Yes, the flags are redundant.
 LIBCOMPATWMAKEENV+= \
-   INSTALL="sh ${.CURDIR}/tools/install.sh" \
+   INSTALL="${INSTALL_CMD} -U" \
PATH=${TMPPATH} \
SYSROOT=${LIBCOMPATTMP} \
LIBDIR=/usr/lib${libcompat} \
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366511 - head/sbin/nvmecontrol/modules/wdc

2020-10-07 Thread Warner Losh
Author: imp
Date: Wed Oct  7 07:55:55 2020
New Revision: 366511
URL: https://svnweb.freebsd.org/changeset/base/366511

Log:
  Use intmax_t to print uint64_t values.
  
  This fixes the 32-bit build where the types are different.

Modified:
  head/sbin/nvmecontrol/modules/wdc/wdc.c

Modified: head/sbin/nvmecontrol/modules/wdc/wdc.c
==
--- head/sbin/nvmecontrol/modules/wdc/wdc.c Wed Oct  7 07:55:55 2020
(r366510)
+++ head/sbin/nvmecontrol/modules/wdc/wdc.c Wed Oct  7 07:55:55 2020
(r366511)
@@ -342,8 +342,8 @@ wdc_do_dump_dui(int fd, char *tmpl, uint8_t data_area,
if (first) {
hdr_ver = ((buf[len_off] & 0xF) != 0) ?
(buf[len_off]) : (le16dec(buf + len_off));
-   printf("Dumping %ld bytes of version %d log to %s\n", 
log_len,
-   hdr_ver, tmpl);
+   printf("Dumping %jd bytes of version %d log to %s\n",
+   (uintmax_t)log_len, hdr_ver, tmpl);
first = 0;
}
if (write(fd2, buf, resid) != (ssize_t)resid)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366508 - in head/sys: dev/rt geom/eli kern sys

2020-10-07 Thread Warner Losh
Author: imp
Date: Wed Oct  7 06:16:37 2020
New Revision: 366508
URL: https://svnweb.freebsd.org/changeset/base/366508

Log:
  Move kernel env global variables, etc to sys/kenv.h
  
  The kernel globals for kenv are confined to 2 files that need them and
  a few that likely shouldn't (but as written the code does). Move them
  from sys/systm.h to sys/kenv.h. This removed a XXX from systm.h and
  cleans it up a little bit...

Modified:
  head/sys/dev/rt/if_rt.c
  head/sys/geom/eli/g_eli.c
  head/sys/kern/kern_environment.c
  head/sys/kern/subr_hints.c
  head/sys/sys/kenv.h
  head/sys/sys/systm.h

Modified: head/sys/dev/rt/if_rt.c
==
--- head/sys/dev/rt/if_rt.c Wed Oct  7 05:44:35 2020(r366507)
+++ head/sys/dev/rt/if_rt.c Wed Oct  7 06:16:37 2020(r366508)
@@ -38,6 +38,8 @@ __FBSDID("$FreeBSD$");
 #include "if_rtvar.h"
 #include "if_rtreg.h"
 
+#include 
+
 #include 
 #include 
 #include 

Modified: head/sys/geom/eli/g_eli.c
==
--- head/sys/geom/eli/g_eli.c   Wed Oct  7 05:44:35 2020(r366507)
+++ head/sys/geom/eli/g_eli.c   Wed Oct  7 06:16:37 2020(r366508)
@@ -32,6 +32,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/kern/kern_environment.c
==
--- head/sys/kern/kern_environment.cWed Oct  7 05:44:35 2020
(r366507)
+++ head/sys/kern/kern_environment.cWed Oct  7 06:16:37 2020
(r366508)
@@ -46,6 +46,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/kern/subr_hints.c
==
--- head/sys/kern/subr_hints.c  Wed Oct  7 05:44:35 2020(r366507)
+++ head/sys/kern/subr_hints.c  Wed Oct  7 06:16:37 2020(r366508)
@@ -31,6 +31,7 @@ __FBSDID("$FreeBSD$");
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Modified: head/sys/sys/kenv.h
==
--- head/sys/sys/kenv.h Wed Oct  7 05:44:35 2020(r366507)
+++ head/sys/sys/kenv.h Wed Oct  7 06:16:37 2020(r366508)
@@ -42,4 +42,18 @@
 #define KENV_MNAMELEN  128 /* Maximum name length (for the syscall) */
 #define KENV_MVALLEN   128 /* Maximum value length (for the syscall) */
 
+#ifdef _KERNEL
+/*
+ * Most of these variables should be const.
+ */
+extern bool dynamic_kenv;
+extern struct mtx kenv_lock;
+extern char *kern_envp;
+extern char *md_envp;
+extern char static_env[];
+extern char static_hints[];/* by config for now */
+
+extern char **kenvp;
+#endif /* _KERNEL */
+
 #endif /* !_SYS_KENV_H_ */

Modified: head/sys/sys/systm.h
==
--- head/sys/sys/systm.hWed Oct  7 05:44:35 2020(r366507)
+++ head/sys/sys/systm.hWed Oct  7 06:16:37 2020(r366508)
@@ -204,21 +204,7 @@ void   kassert_panic(const char *fmt, ...)  
__printflike
 })
 #defineSCHEDULER_STOPPED() SCHEDULER_STOPPED_TD(curthread)
 
-/*
- * XXX the hints declarations are even more misplaced than most declarations
- * in this file, since they are needed in one file (per arch) and only used
- * in two files.
- * XXX most of these variables should be const.
- */
 extern int osreldate;
-extern bool dynamic_kenv;
-extern struct mtx kenv_lock;
-extern char *kern_envp;
-extern char *md_envp;
-extern char static_env[];
-extern char static_hints[];/* by config for now */
-
-extern char **kenvp;
 
 extern const void *zero_region;/* address space maps to a zeroed page  
*/
 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366507 - head/sys/cam/scsi

2020-10-06 Thread Warner Losh
Author: imp
Date: Wed Oct  7 05:44:35 2020
New Revision: 366507
URL: https://svnweb.freebsd.org/changeset/base/366507

Log:
  cam: Add quirk for Samsung MZ7* behind a SATA-to-SAS interposer
  
  Sometimes, this drive will be present in the system such that the the
  firmware identification string doesn't start with ATA, such as when
  it's behind a SATA-to-SAS interposer. Add another quirk for that.
  
  Submitted by: github user mr44er
  Github PR: 423

Modified:
  head/sys/cam/scsi/scsi_da.c

Modified: head/sys/cam/scsi/scsi_da.c
==
--- head/sys/cam/scsi/scsi_da.c Wed Oct  7 05:36:05 2020(r366506)
+++ head/sys/cam/scsi/scsi_da.c Wed Oct  7 05:44:35 2020(r366507)
@@ -1417,6 +1417,15 @@ static struct da_quirk_entry da_quirk_table[] =
},
{
/*
+ * Same as above but enable the quirks for SSD SAMSUNG MZ7*
+ * connected via SATA-to-SAS interposer and because of this
+ * starting without "ATA"
+*/
+   { T_DIRECT, SIP_MEDIA_FIXED, "SAMSUNG", "MZ7*", "*" },
+   /*quirks*/DA_Q_4K
+   },
+   {
+   /*
 * SuperTalent TeraDrive CT SSDs
 * 4k optimised & trim only works in 4k requests + 4k aligned
 */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366506 - head/sbin/nvmecontrol/modules/wdc

2020-10-06 Thread Warner Losh
Author: imp
Date: Wed Oct  7 05:36:05 2020
New Revision: 366506
URL: https://svnweb.freebsd.org/changeset/base/366506

Log:
  nvmecontrol: Update wdc module for newer WDC NVMe products
  
  Update the to log fetch operation for latest WDC NVMe products.
  
  Tested on HGST SN100 (a few years old) and WDC SN720 (more recent).
  
  Submitted by: Akhilesh Rn  (minor style tweak by me)
  Github PR: 435

Modified:
  head/sbin/nvmecontrol/modules/wdc/wdc.c

Modified: head/sbin/nvmecontrol/modules/wdc/wdc.c
==
--- head/sbin/nvmecontrol/modules/wdc/wdc.c Tue Oct  6 23:35:26 2020
(r366505)
+++ head/sbin/nvmecontrol/modules/wdc/wdc.c Wed Oct  7 05:36:05 2020
(r366506)
@@ -38,6 +38,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 
 #include "nvmecontrol.h"
 
@@ -61,14 +62,18 @@ static struct options 
 {
const char *template;
const char *dev;
+   uint8_t data_area;
 } opt = {
.template = NULL,
.dev = NULL,
+   .data_area = 0,
 };
 
 static const struct opts opts[] = {
OPT("template", 'o', arg_string, opt, template,
"Template for paths to use for different logs"),
+   OPT("data-area", 'd', arg_uint8, opt, data_area,
+   "Data-area to retrieve up to"),
OPT_END
 };
 
@@ -88,11 +93,27 @@ static struct cmd cap_diag_cmd = {
 
 CMD_SUBCOMMAND(wdc_cmd, cap_diag_cmd);
 
-#define WDC_NVME_TOC_SIZE  8
+#define WDC_NVME_VID   0x1c58
+#define WDC_NVME_VID_2 0x1b96
+#define WDC_NVME_VID_3 0x15b7
 
-#define WDC_NVME_CAP_DIAG_OPCODE   0xe6
-#define WDC_NVME_CAP_DIAG_CMD  0x
+#define WDC_NVME_TOC_SIZE  0x8
+#define WDC_NVME_LOG_SIZE_HDR_LEN  0x8
+#define WDC_NVME_CAP_DIAG_OPCODE_E60xe6
+#define WDC_NVME_CAP_DIAG_CMD  0x
+#define WDC_NVME_CAP_DIAG_OPCODE_FA0xfa
+#define WDC_NVME_DUI_MAX_SECTIONS_V0   0x3c
+#define WDC_NVME_DUI_MAX_SECTIONS_V1   0x3a
+#define WDC_NVME_DUI_MAX_SECTIONS_V2   0x26
+#define WDC_NVME_DUI_MAX_SECTIONS_V3   0x23
 
+typedef enum wdc_dui_header {
+   WDC_DUI_HEADER_VER_0 = 0,
+   WDC_DUI_HEADER_VER_1,
+   WDC_DUI_HEADER_VER_2,
+   WDC_DUI_HEADER_VER_3,
+} wdc_dui_header;
+
 static void
 wdc_append_serial_name(int fd, char *buf, size_t len, const char *suffix)
 {
@@ -108,25 +129,26 @@ wdc_append_serial_name(int fd, char *buf, size_t len, 
while (walker > sn && *walker == ' ')
walker--;
*++walker = '\0';
-   snprintf(buf, len, "%s%s.bin", sn, suffix);
+   snprintf(buf, len, "_%s_%s.bin", sn, suffix);
 }
 
 static void
 wdc_get_data(int fd, uint32_t opcode, uint32_t len, uint32_t off, uint32_t cmd,
-uint8_t *buffer, size_t buflen)
+uint8_t *buffer, size_t buflen, bool e6lg_flag)
 {
struct nvme_pt_command  pt;
 
memset(, 0, sizeof(pt));
pt.cmd.opc = opcode;
-   pt.cmd.cdw10 = htole32(len / sizeof(uint32_t)); /* - 1 like all the 
others ??? */
-   pt.cmd.cdw11 = htole32(off / sizeof(uint32_t));
+   pt.cmd.cdw10 = htole32(len / sizeof(uint32_t));
pt.cmd.cdw12 = htole32(cmd);
+   if (e6lg_flag)
+   pt.cmd.cdw11 = htole32(off / sizeof(uint32_t));
+   else
+   pt.cmd.cdw13 = htole32(off / sizeof(uint32_t));
pt.buf = buffer;
pt.len = buflen;
pt.is_read = 1;
-// printf("opcode %#x cdw10(len) %#x cdw11(offset?) %#x cdw12(cmd/sub) %#x 
buflen %zd\n",
-// (int)opcode, (int)cdw10, (int)cdw11, (int)cdw12, buflen);
 
if (ioctl(fd, NVME_PASSTHROUGH_CMD, ) < 0)
err(1, "wdc_get_data request failed");
@@ -135,17 +157,29 @@ wdc_get_data(int fd, uint32_t opcode, uint32_t len, ui
 }
 
 static void
-wdc_do_dump(int fd, char *tmpl, const char *suffix, uint32_t opcode,
+wdc_do_dump_e6(int fd, char *tmpl, const char *suffix, uint32_t opcode,
 uint32_t cmd, int len_off)
 {
int first;
int fd2;
-   uint8_t *buf;
+   uint8_t *buf, *hdr;
uint32_t len, offset;
size_t resid;
+   bool e6lg_flag = false;
 
wdc_append_serial_name(fd, tmpl, MAXPATHLEN, suffix);
 
+   /* Read Log Dump header */
+   len = WDC_NVME_LOG_SIZE_HDR_LEN;
+   offset = 0;
+   hdr = malloc(len);
+   if (hdr == NULL)
+   errx(1, "Can't get buffer to read dump");
+   wdc_get_data(fd, opcode, len, offset, cmd, hdr, len, false);
+   if (memcmp("E6LG", hdr, 4) == 0) {
+   e6lg_flag = true;
+   }
+
/* XXX overwrite protection? */
fd2 = open(tmpl, O_WRONLY | O_CREAT | O_TRUNC, 0644);
if (fd2 < 0)
@@ -159,15 +193,13 @@ wdc_do_dump(int fd, char *tmpl, const char *suffix, ui
 
do {
resid = len > NVME_MAX_XFER_SIZE ? NVME_MAX_XFER_SIZE : 

svn commit: r366505 - head/sys/cam/nvme

2020-10-06 Thread Warner Losh
Author: imp
Date: Tue Oct  6 23:35:26 2020
New Revision: 366505
URL: https://svnweb.freebsd.org/changeset/base/366505

Log:
  nvme: Note where the CCB was released for passthrough command

Modified:
  head/sys/cam/nvme/nvme_da.c

Modified: head/sys/cam/nvme/nvme_da.c
==
--- head/sys/cam/nvme/nvme_da.c Tue Oct  6 23:33:56 2020(r366504)
+++ head/sys/cam/nvme/nvme_da.c Tue Oct  6 23:35:26 2020(r366505)
@@ -1257,6 +1257,7 @@ ndadone(struct cam_periph *periph, union ccb *done_ccb
/* No-op.  We're polling */
return;
case NDA_CCB_PASS:
+   /* NVME_PASSTHROUGH_CMD runs this CCB and releases it */
return;
default:
break;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366504 - head/sys/cam

2020-10-06 Thread Warner Losh
Author: imp
Date: Tue Oct  6 23:33:56 2020
New Revision: 366504
URL: https://svnweb.freebsd.org/changeset/base/366504

Log:
  cam: Assert we have a reference when freeing sim
  
  Before we decrement refcount to sleep on the sim, assert that the
  refcount >= 1. If it were 0 here, we'd never wake up.

Modified:
  head/sys/cam/cam_sim.c

Modified: head/sys/cam/cam_sim.c
==
--- head/sys/cam/cam_sim.c  Tue Oct  6 23:16:56 2020(r366503)
+++ head/sys/cam/cam_sim.c  Tue Oct  6 23:33:56 2020(r366504)
@@ -134,6 +134,7 @@ cam_sim_free(struct cam_sim *sim, int free_devq)
mtx = sim->mtx;
mtx_assert(mtx, MA_OWNED);
}
+   KASSERT(sim->refcount >= 1, ("sim->refcount >= 1"));
sim->refcount--;
if (sim->refcount > 0) {
error = msleep(sim, mtx, PRIBIO, "simfree", 0);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366431 - head/sys/dev/usb/serial

2020-10-05 Thread Warner Losh
On Mon, Oct 5, 2020 at 5:46 AM Ronald Klop  wrote:

> Hi,
>
> I was interested by this commit. But the commit and commit message don't
> have much information. I was surprised that the "Differential Revision"
> link contains a lot of info about this. How permanent is this
> review.freebsd.org server? Wil it stay after the git migration?
>

Yes. It's anticipated that we'll keep it around forever.

Warner


> Ronald.
>
>
> *Van:* Hans Petter Selasky 
> *Datum:* zondag, 4 oktober 2020 19:17
> *Aan:* src-committ...@freebsd.org, svn-src-...@freebsd.org,
> svn-src-head@freebsd.org
> *Onderwerp:* svn commit: r366431 - head/sys/dev/usb/serial
>
> Author: hselasky
> Date: Sun Oct  4 17:17:16 2020
> New Revision: 366431
> URL: https://svnweb.freebsd.org/changeset/base/366431
>
> Log:
>   Add support for Google Cr50 (GSC) Closed Case Debugging UART interfaces
> to
>   the USB generic serial port driver, ugensa.
>
>   MFC after:1 week
>   Differential Revision:https://reviews.freebsd.org/D21863
>   Submitted by: greg_unrelenting.technology (Greg V)
>   Sponsored by: Mellanox Technologies // NVIDIA Networking
>
> Modified:
>   head/sys/dev/usb/serial/ugensa.c
>
> Modified: head/sys/dev/usb/serial/ugensa.c
>
> ==
> --- head/sys/dev/usb/serial/ugensa.cSun Oct  4 17:07:13 2020
>(r366430)
> +++ head/sys/dev/usb/serial/ugensa.cSun Oct  4 17:17:16 2020
>(r366431)
> @@ -161,6 +161,8 @@ static const STRUCT_USB_HOST_ID ugensa_devs[] = {
> {USB_VPI(USB_VENDOR_KYOCERA2, USB_PRODUCT_KYOCERA2_CDMA_MSM_K, 1)},
> {USB_VPI(USB_VENDOR_HP, USB_PRODUCT_HP_49GPLUS, 1)},
> {USB_VPI(USB_VENDOR_NOVATEL2, USB_PRODUCT_NOVATEL2_FLEXPACKGPS, 3)},
> +   {USB_VENDOR(USB_VENDOR_GOOGLE), USB_IFACE_CLASS(UICLASS_VENDOR),
> +   USB_IFACE_SUBCLASS(0x50), USB_IFACE_PROTOCOL(0x01),
> USB_DRIVER_INFO(10)},
>  };
>
>  DRIVER_MODULE(ugensa, uhub, ugensa_driver, ugensa_devclass, NULL, 0);
> ___
> svn-src-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
> --
>
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366265 - head/sys/sys

2020-09-29 Thread Warner Losh
On Tue, Sep 29, 2020, 1:00 PM Hans Petter Selasky  wrote:

> On 2020-09-29 20:06, Warner Losh wrote:
> > Author: imp
> > Date: Tue Sep 29 18:06:02 2020
> > New Revision: 366265
> > URL: https://svnweb.freebsd.org/changeset/base/366265
> >
> > Log:
> >Standalone SX shims
> >
> >Create a do-nothing version of SX locks. OpenZFS needs them. However,
> >since the boot loader is single threaded, they can be nops.
> >
> > Modified:
> >head/sys/sys/sx.h
> >
> > Modified: head/sys/sys/sx.h
> >
> ==
> > --- head/sys/sys/sx.h Tue Sep 29 17:52:15 2020(r366264)
> > +++ head/sys/sys/sx.h Tue Sep 29 18:06:02 2020(r366265)
> > @@ -300,4 +300,26 @@ __sx_xunlock(struct sx *sx, struct thread *td,
> const c
> >
> >   #endif /* _KERNEL */
> >
> > +#ifdef _STANDALONE
> > +/* since we have no threads in the boot loader, trivially implement
> no-op version */
> > +#define sx_xlock(s) (1)
> > +#define sx_try_xlock(s) (1)
> > +#define sx_xunlock(s) (1)
> > +#define SX_DUPOK 0
> > +#define SX_NEW 0
> > +#define SX_NOWITNESS 0
> > +
> > +static __inline void
> > +sx_init_flags(struct sx *sx, const char *description, int opts)
> > +{
> > +
> > +}
> > +
> > +static __inline void
> > +sx_destroy(struct sx *sx)
> > +{
> > +
> > +}
> > +#endif /* _STANDALONE */
> > +
> >   #endif /* !_SYS_SX_H_ */
> >
>
> You may want to use:
>
> bsd_kernel.c:sx_init_flags(struct sx *sx, const char *name, int flags)
> bsd_kernel.c:   sx->owned = 0;
> bsd_kernel.c:sx_destroy(struct sx *sx)
> bsd_kernel.c:sx_xlock(struct sx *sx)
> bsd_kernel.c:   sx->owned++;
> bsd_kernel.c:sx_xunlock(struct sx *sx)
> bsd_kernel.c:   sx->owned--;
> bsd_kernel.c:sx_xlocked(struct sx *sx)
> bsd_kernel.c:   return (sx->owned != 0);
> bsd_kernel.h:struct sx {
> bsd_kernel.h:#definesx_assert(...) do { } while (0)
> bsd_kernel.h:#definesx_init(...) sx_init_flags(__VA_ARGS__, 0)
> bsd_kernel.h:void   sx_init_flags(struct sx *, const char *, int);
> bsd_kernel.h:void   sx_destroy(struct sx *);
> bsd_kernel.h:void   sx_xlock(struct sx *);
> bsd_kernel.h:void   sx_xunlock(struct sx *);
> bsd_kernel.h:intsx_xlocked(struct sx *);
>
> from "src/stand/kshim"
>

Yea. This, and other parts of the shims, need to be integrated into stand...

Warner

>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366266 - head/lib/libc/sys

2020-09-29 Thread Warner Losh
Author: imp
Date: Tue Sep 29 18:13:54 2020
New Revision: 366266
URL: https://svnweb.freebsd.org/changeset/base/366266

Log:
  Updates to chroot(2) docs
  
  1. Note what settings give historic behavior
  2. Recommend jail under security considerations.

Modified:
  head/lib/libc/sys/chroot.2

Modified: head/lib/libc/sys/chroot.2
==
--- head/lib/libc/sys/chroot.2  Tue Sep 29 18:06:02 2020(r366265)
+++ head/lib/libc/sys/chroot.2  Tue Sep 29 18:13:54 2020(r366266)
@@ -28,7 +28,7 @@
 .\" @(#)chroot.2   8.1 (Berkeley) 6/4/93
 .\" $FreeBSD$
 .\"
-.Dd June 26, 2020
+.Dd September 29, 2020
 .Dt CHROOT 2
 .Os
 .Sh NAME
@@ -91,7 +91,10 @@ system call.
 .Pp
 Any other value for
 .Ql kern.chroot_allow_open_directories
-will bypass the check for open directories
+will bypass the check for open directories,
+mimicking the historic insecure behavior of
+.Fn chroot
+still present on other systems.
 .Sh RETURN VALUES
 .Rv -std
 .Sh ERRORS
@@ -156,3 +159,7 @@ root,
 for instance,
 setup the sandbox so that the sandboxed user will have no write
 access to any well-known system directories.
+.Pp
+For complete isolation from the rest of the system, use
+.Xr jail 2
+instead.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366265 - head/sys/sys

2020-09-29 Thread Warner Losh
Author: imp
Date: Tue Sep 29 18:06:02 2020
New Revision: 366265
URL: https://svnweb.freebsd.org/changeset/base/366265

Log:
  Standalone SX shims
  
  Create a do-nothing version of SX locks. OpenZFS needs them. However,
  since the boot loader is single threaded, they can be nops.

Modified:
  head/sys/sys/sx.h

Modified: head/sys/sys/sx.h
==
--- head/sys/sys/sx.h   Tue Sep 29 17:52:15 2020(r366264)
+++ head/sys/sys/sx.h   Tue Sep 29 18:06:02 2020(r366265)
@@ -300,4 +300,26 @@ __sx_xunlock(struct sx *sx, struct thread *td, const c
 
 #endif /* _KERNEL */
 
+#ifdef _STANDALONE
+/* since we have no threads in the boot loader, trivially implement no-op 
version */
+#define sx_xlock(s) (1)
+#define sx_try_xlock(s) (1)
+#define sx_xunlock(s) (1)
+#define SX_DUPOK 0
+#define SX_NEW 0
+#define SX_NOWITNESS 0
+
+static __inline void
+sx_init_flags(struct sx *sx, const char *description, int opts)
+{
+
+}
+
+static __inline void
+sx_destroy(struct sx *sx)
+{
+
+}
+#endif /* _STANDALONE */
+
 #endif /* !_SYS_SX_H_ */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366260 - head/stand/libsa

2020-09-29 Thread Warner Losh
Author: imp
Date: Tue Sep 29 16:29:50 2020
New Revision: 366260
URL: https://svnweb.freebsd.org/changeset/base/366260

Log:
  Implement some time variables from kernel
  
  OpenZFS will start using some of the kernel timekeeping bits
  shortly. This implements the bare minimum of that which currently
  is just the time_seconds variable.

Added:
  head/stand/libsa/time.c   (contents, props changed)
Modified:
  head/stand/libsa/Makefile

Modified: head/stand/libsa/Makefile
==
--- head/stand/libsa/Makefile   Tue Sep 29 15:37:57 2020(r366259)
+++ head/stand/libsa/Makefile   Tue Sep 29 16:29:50 2020(r366260)
@@ -160,6 +160,9 @@ SRCS+=  dosfs.c ext2fs.c
 SRCS+= splitfs.c
 SRCS+= pkgfs.c
 
+# Time support
+SRCS+= time.c
+
 # kernel ufs support
 .PATH: ${SRCTOP}/sys/ufs/ffs
 SRCS+=ffs_subr.c ffs_tables.c

Added: head/stand/libsa/time.c
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ head/stand/libsa/time.c Tue Sep 29 16:29:50 2020(r366260)
@@ -0,0 +1,35 @@
+/*-
+ * Copyright (c) 2020 M. Warner Losh 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * The parts of kern_tc.c and other timekeeping bits of the kernel.
+ */
+
+#include 
+__FBSDID("$FreeBSD$");
+
+#include 
+
+volatile time_t time_second = 1;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366228 - head/stand/lua

2020-09-28 Thread Warner Losh
Author: imp
Date: Mon Sep 28 16:19:21 2020
New Revision: 366228
URL: https://svnweb.freebsd.org/changeset/base/366228

Log:
  Report the kernel console on the boot screen
  
  Report what console the boot loader is telling the kernel to use:
o Dual (Serial Primary)
o Dual (Video Primary)
o Serial
o Video
  
  This allows the user to interrupt the boot and tweak the cosnole, if
  needed, in a trivial way. Useful for installs where the default
  selected may not be quite what you want, or when you are running a
  dual setup and need to toggle over to the other console being primary.
  The 'c'/'C' keys will do the cycling through the consoles.  Note:
  you'll still have to drop into the loader to set details about serial
  consoles. And this doesn't change the console the loader is using.
  
  Reviewed by: kevans@
  MFC After: 3 days
  Differential Revision: https://reviews.freebsd.org/D26573

Modified:
  head/stand/lua/core.lua
  head/stand/lua/menu.lua

Modified: head/stand/lua/core.lua
==
--- head/stand/lua/core.lua Mon Sep 28 14:47:36 2020(r366227)
+++ head/stand/lua/core.lua Mon Sep 28 16:19:21 2020(r366228)
@@ -451,6 +451,40 @@ function core.popFrontTable(tbl)
return first_value, new_tbl
 end
 
+function core.getConsoleName()
+   if loader.getenv("boot_multicons") ~= nil then
+   if loader.getenv("boot_serial") ~= nil then
+   return "Dual (Serial primary)"
+   else
+   return "Dual (Video primary)"
+   end
+   else
+   if loader.getenv("boot_serial") ~= nil then
+   return "Serial"
+   else
+   return "Video"
+   end
+   end
+end
+
+function core.nextConsoleChoice()
+   if loader.getenv("boot_multicons") ~= nil then
+   if loader.getenv("boot_serial") ~= nil then
+   loader.unsetenv("boot_serial")
+   else
+   loader.unsetenv("boot_multicons")
+   loader.setenv("boot_serial", "YES")
+   end
+   else
+   if loader.getenv("boot_serial") ~= nil then
+   loader.unsetenv("boot_serial")
+   else
+   loader.setenv("boot_multicons", "YES")
+   loader.setenv("boot_serial", "YES")
+   end
+   end
+end
+
 recordDefaults()
 hook.register("config.reloaded", core.clearCachedKernels)
 return core

Modified: head/stand/lua/menu.lua
==
--- head/stand/lua/menu.lua Mon Sep 28 14:47:36 2020(r366227)
+++ head/stand/lua/menu.lua Mon Sep 28 16:19:21 2020(r366228)
@@ -244,6 +244,7 @@ menu.welcome = {
boot_entry_2,
menu_entries.prompt,
menu_entries.reboot,
+   menu_entries.console,
{
entry_type = core.MENU_SEPARATOR,
},
@@ -283,6 +284,16 @@ menu.welcome = {
core.boot()
end,
alias = {"s", "S"},
+   },
+   console = {
+   entry_type = core.MENU_ENTRY,
+   name = function()
+   return color.highlight("C") .. "ons: " .. 
core.getConsoleName()
+   end,
+   func = function()
+   core.nextConsoleChoice()
+   end,
+   alias = {"c", "C"},
},
prompt = {
entry_type = core.MENU_RETURN,
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366229 - head/sys/kern

2020-09-28 Thread Warner Losh
Author: imp
Date: Mon Sep 28 16:19:29 2020
New Revision: 366229
URL: https://svnweb.freebsd.org/changeset/base/366229

Log:
  For mulitcons boot, report it and which console is primary
  
  Until we can do proper /etc/rc output on both consoles in multicons
  boot (or all of them if we ever generalize), report when we are
  booting multicons. Also report the primary console. This will be a big
  hint why output stops after this line (though some slow USB discovery
  still happens after mountroot / init starts).
  
  Reviewed by: scottl@, tsoome@
  Differential Revision: https://reviews.freebsd.org/D26574

Modified:
  head/sys/kern/init_main.c

Modified: head/sys/kern/init_main.c
==
--- head/sys/kern/init_main.c   Mon Sep 28 16:19:21 2020(r366228)
+++ head/sys/kern/init_main.c   Mon Sep 28 16:19:29 2020(r366229)
@@ -715,6 +715,14 @@ start_init(void *dummy)
/* Wipe GELI passphrase from the environment. */
kern_unsetenv("kern.geom.eli.passphrase");
 
+   /* For Multicons, report which console is primary to both */
+   if (boothowto & RB_MULTIPLE) {
+   if (boothowto & RB_SERIAL)
+   printf("Dual Console: Serial Primary, Video 
Secondary\n");
+   else
+   printf("Dual Console: Video Primary, Serial 
Secondary\n");
+   }
+
if ((var = kern_getenv("init_path")) != NULL) {
strlcpy(init_path, var, sizeof(init_path));
freeenv(var);
@@ -724,7 +732,7 @@ start_init(void *dummy)
while ((path = strsep(_init_path, ":")) != NULL) {
if (bootverbose)
printf("start_init: trying %s\n", path);
-   
+
memset(, 0, sizeof(args));
error = exec_alloc_args();
if (error != 0)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366217 - head/tools/boot

2020-09-28 Thread Warner Losh
Author: imp
Date: Mon Sep 28 06:00:56 2020
New Revision: 366217
URL: https://svnweb.freebsd.org/changeset/base/366217

Log:
  Speciy the dev in an easily changed variable
  
  Rather than hard coding ada0 everywhere, use ${dev}. Also, set
  dev=vtbd0 since both qemu and bhyve support this. More work
  should be done to use labels instead for fstab.
  
  qemu scripts likely need adjustment. And we should also
  likely generate byhve scripts too.

Modified:
  head/tools/boot/rootgen.sh

Modified: head/tools/boot/rootgen.sh
==
--- head/tools/boot/rootgen.sh  Mon Sep 28 06:00:39 2020(r366216)
+++ head/tools/boot/rootgen.sh  Mon Sep 28 06:00:56 2020(r366217)
@@ -7,6 +7,7 @@ iterations=5
 
 # The smallest FAT32 filesystem is 33292 KB
 espsize=33292
+dev=vtbd0
 
 #
 # Builds all the bat-shit crazy combinations we support booting from,
@@ -20,7 +21,7 @@ espsize=33292
 # This assumes an external program install-boot.sh which will install
 # the appropriate boot files in the appropriate locations.
 #
-# These images assume ada0 will be the root image. We should likely
+# These images assume ${dev} will be the root image. We should likely
 # use labels, but we don't.
 #
 # Assumes you've already rebuilt... maybe bad? Also maybe bad: the env
@@ -42,7 +43,7 @@ mk_nogeli_gpt_ufs_legacy() {
 img=$2
 
 cat > ${src}/etc/fstab < ${src}/etc/fstab < ${src}/etc/fstab < ${src}/etc/fstab < ${src}/etc/fstab < ${src}/etc/fstab < ${mntpt}/etc/fstab < ${mntpt}/etc/fstab < ${mntpt}/etc/fstab < ${src}/etc/fstab < ${DESTDIR}/boot.config
 cat > ${DESTDIR}/boot/loader.conf 

svn commit: r366216 - head/stand/efi/loader

2020-09-28 Thread Warner Losh
Author: imp
Date: Mon Sep 28 06:00:39 2020
New Revision: 366216
URL: https://svnweb.freebsd.org/changeset/base/366216

Log:
  Fix video on PCI heuristic
  
  The video on PCI heuristic was broken. It was supposed to infer a
  video device when the last element of the path was a PCI DEVICE PATH
  node. However, the last node in the device path is an END node, so
  this heuristic never fired.
  
  This leads, among other things, to bhyve only producing output in the
  serial connection once we leave the boot loader. This restores the
  dual headed boot on bhyve + UEFI (as we did in 11.2), but will favor
  serial in the absence of other config which may be a change from 11.2.
  
  MFC After: 3 days
  Differential Revision: https://reviews.freebsd.org/D26572

Modified:
  head/stand/efi/loader/main.c

Modified: head/stand/efi/loader/main.c
==
--- head/stand/efi/loader/main.cMon Sep 28 04:30:31 2020
(r366215)
+++ head/stand/efi/loader/main.cMon Sep 28 06:00:39 2020
(r366216)
@@ -739,6 +739,10 @@ parse_uefi_con_out(void)
ep = buf + sz;
node = (EFI_DEVICE_PATH *)buf;
while ((char *)node < ep) {
+   if (IsDevicePathEndType(node)) {
+   if (pci_pending && vid_seen == 0)
+   vid_seen = ++seen;
+   }
pci_pending = false;
if (DevicePathType(node) == ACPI_DEVICE_PATH &&
(DevicePathSubType(node) == ACPI_DP ||
@@ -772,8 +776,6 @@ parse_uefi_con_out(void)
}
node = NextDevicePathNode(node);
}
-   if (pci_pending && vid_seen == 0)
-   vid_seen = ++seen;
 
/*
 * Truth table for RB_MULTIPLE | RB_SERIAL
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r365643 - head/bin/cp

2020-09-26 Thread Warner Losh
On Sat, Sep 26, 2020, 1:50 PM Benjamin Kaduk  wrote:

> On Sat, Sep 26, 2020 at 12:35 PM Warner Losh  wrote:
>
>>
>>
>> On Sat, Sep 26, 2020 at 12:58 PM Benjamin Kaduk 
>> wrote:
>>
>>> On Sat, Sep 26, 2020 at 11:55 AM Warner Losh  wrote:
>>>
>>>> And there's the rub: how did this file come to exist? I'm certain it
>>>> isn't
>>>> booting or shutting down the system based on when devfs is mounted
>>>> (before
>>>> init) and unmounted (it's not done by the shutdown scripts). Now, it's
>>>> always possible there's a hole in my understanding of the sequence of
>>>> events. But given the examination of code, it's crazy to think this
>>>> could
>>>> be created by anything but some weird bug. That's why a step-by-step
>>>> from
>>>> scratch guide is needed. Im happy to look into it, but I need a bit
>>>> more to
>>>> go on.
>>>>
>>>>
>>> I don't think it's terribly complicated; either set up a multi-boot
>>> system or
>>> pull the physical drive with / from one machine, and mount it while
>>> booted
>>> into a different environment.  Then, chroot into it and do ... just
>>> about anything.
>>> If you didn't mount devfs before chrooting, then you get a file
>>> /dev/null (and some
>>> really confused errors from, e.g., buildworld!).
>>>
>>
>> I think there's two different things that are being talked about here.
>> Let's not confuse the two.
>>
>>
> I agree there are two different things going on here.  My apologies for
> using buildworld as an example of "something that writes to /dev/null" when
> any other example would have done just as well.
>
>
>> The first is making the build system not depend on /dev/null. You'll find
>> that's hard to do if you and try to do it since /dev/null is used about 200
>> times in the current build system in about a dozen different ways. Some are
>> easy, most are a bit tricky since you can't just close stdout/stderr
>> because then any files opened by the program will get those FDs and
>> printf/fprint(stderr, will collide.  This dependency won't be fixed any
>> time soon, though I could add a seatbelt to buildworld/buildkernel that
>> ensures that /dev/null is a character device.
>>
>> The second is a report that /dev/null is created all the time through
>> normal means before devfs can be mounted.  However, several people have
>> looked and found no evidence on their system. This means there's something
>> special / unique to Rod's setup that's generating them (assuming it isn't a
>> simple chroot without devfs). What that is, and how they come to be, hasn't
>> been explained in enough detail to reproduce. That's what people are asking
>> Rod about: how do we get there? How did it happen? Once we know those
>> answers, we can fix it.
>>
>>
> I was reading the thread differently than that.  In particular, I saw
> observations that some people had a file /dev/null on their root
> filesystem, and speculation that it appeared during early boot or
> shutdown.  In particular, I did not see specific reports that it was
> created during early shutdown, just speculation.  Such speculation has
> since been thoroughly debunked, but the observations of a /dev/null file
> remain.  It is easy to get such a /dev/null file on your root filesystem,
> you just have to arrange for that filesystem to not actually *be* the root
> filesystem when the file is created.  So ... "nothing to see here"?
>

Yes. The file is presented, but no scenario has been given to create it.
So, if there is a common way to get this file, that would be good to know..
Even if the answer is something like bsdinstall has a bug, or something
like that...

Warner

-Ben
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r365643 - head/bin/cp

2020-09-26 Thread Warner Losh
On Sat, Sep 26, 2020 at 12:58 PM Benjamin Kaduk  wrote:

> On Sat, Sep 26, 2020 at 11:55 AM Warner Losh  wrote:
>
>> And there's the rub: how did this file come to exist? I'm certain it isn't
>> booting or shutting down the system based on when devfs is mounted (before
>> init) and unmounted (it's not done by the shutdown scripts). Now, it's
>> always possible there's a hole in my understanding of the sequence of
>> events. But given the examination of code, it's crazy to think this could
>> be created by anything but some weird bug. That's why a step-by-step from
>> scratch guide is needed. Im happy to look into it, but I need a bit more
>> to
>> go on.
>>
>>
> I don't think it's terribly complicated; either set up a multi-boot system
> or
> pull the physical drive with / from one machine, and mount it while booted
> into a different environment.  Then, chroot into it and do ... just about
> anything.
> If you didn't mount devfs before chrooting, then you get a file /dev/null
> (and some
> really confused errors from, e.g., buildworld!).
>

I think there's two different things that are being talked about here.
Let's not confuse the two.

The first is making the build system not depend on /dev/null. You'll find
that's hard to do if you and try to do it since /dev/null is used about 200
times in the current build system in about a dozen different ways. Some are
easy, most are a bit tricky since you can't just close stdout/stderr
because then any files opened by the program will get those FDs and
printf/fprint(stderr, will collide.  This dependency won't be fixed any
time soon, though I could add a seatbelt to buildworld/buildkernel that
ensures that /dev/null is a character device.

The second is a report that /dev/null is created all the time through
normal means before devfs can be mounted.  However, several people have
looked and found no evidence on their system. This means there's something
special / unique to Rod's setup that's generating them (assuming it isn't a
simple chroot without devfs). What that is, and how they come to be, hasn't
been explained in enough detail to reproduce. That's what people are asking
Rod about: how do we get there? How did it happen? Once we know those
answers, we can fix it.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366186 - in head/usr.sbin: bsdconfig/share/media bsdinstall/scripts

2020-09-26 Thread Warner Losh
On Sat, Sep 26, 2020 at 12:54 PM Niclas Zeising  wrote:

> On 2020-09-26 20:28, Rodney W. Grimes wrote:
> >> On 2020-09-26 20:12, Rodney W. Grimes wrote:
>  Author: zeising (doc,ports committer)
>  Date: Sat Sep 26 16:27:09 2020
>  New Revision: 366186
>  URL: https://svnweb.freebsd.org/changeset/base/366186
> 
>  Log:
>  bsdconfig, bsdinstall: Prune dead mirrors
> 
>  Prune dead mirrors from the list of mirrors in bsdconfig and
> bsdinstall.
>  All these return NXDOMAIN when trying to resolve them.
> >>>
> >>> This seems like the wrong place to fix it, as this does
> >>> nothing for all the "shipped" releases that contain the
> >>> old values.  Shouldnt these all just be CNAMED in dns
> >>> to a nearest replacement resource?
> >>>
> >>>
> >>
> >> Considering that we don't actually have control of the subdomans
> >> (CC.freebsd.org) ourselves, that is trickier than it might sound.
> >
> > How can freebsd.org NOT have ultimate control over deligations?
> > If things have become "lame" in a deligated zone the deligation
> > can and should be pulled and replaced with local data.
> >
> > This is cc.freebsd.org, not freebsd.org.cc!
>
> I am the wrong person to answer that question.
>
> In this case, things have not become lame.  For instance, the names
> ervers for se.freebsd.org work fine, but ftp3.se and ftp6.se records are
> removed.  Same for ru.freebsd.org and ftp4.ru.
> I'm merely pointing out that changing ftp.CC.freebsd.org usually
> requires contacting the person(s) maintaining the CC.freebsd.org zone,
> which is usually not the project.
>

It's usually people associated with the project in some way, but who might
not be as responsive as cluster admin. These domains have been delegated,
so we have to get the delegated admin to make the changes, which can take a
bit of time to chase down and doesn't lend itself to easy / automated
coping with this situation.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r365643 - head/bin/cp

2020-09-26 Thread Warner Losh
On Sat, Sep 26, 2020 at 11:02 AM Rodney W. Grimes 
wrote:

>
> > On Fri, 2020-09-25 at 10:55 -0700, Rodney W. Grimes wrote:
> > > > I was under the impression from previous reading and kib's response
> > > > that this is a complete non-issue, there's no way you can go
> > > > multi-user without a mounted /dev and we go to somewhat great
> > > > lengths to make sure we're good.
> > >
> > > Though kib can assert that, it does not change the fact that I
> > > frequently find /dev/null FILES on unmounted root file systems.
> > >
> > > But lets not mix the 2 separate things of boot time /dev dependency
> > > and build time /dev dependency.
> >
> > If you look in sys/kern/vfs_mountroot.c you can see that the code to
> > mount /dev is invoked unconditionally as the first step of mounting
> > root, and that all the calls it makes to get devfs mounted have their
> > results checked with KASSERTs.
> >
> > That's pretty strong evidence that devfs is mounted before rc scripts
> > run.  That creates a situation where you are making an extraordinary
> > claim, so you need to provide extraordinary evidence to support it.  A
> > sequence of actions that allows others to recreate the situation would
> > do the trick.
>
> I have provided ways one can look for this file in
> other messages of the threads.  A dump of a UFS root
> can show it up, and iirc you can find it in a
> zfs send of a boot dataset.
>

You've not provided a step-by-step way to recreate the issue leading to the
/dev/null file, however. Absent that, it's going to be really hard to fix
it.

> (A question that occurs to me:  could it be that the files you've seen
> > got created at shutdown after devfs was unmounted, rather than at
> > startup?  I don't know enough about the shutdown sequence to know
> > whether that's possible.)
>
> Its not "the files" it is "a file, /dev/null".  And yes, it could
> be very possible that it is during shutdown.  Sadly the files is
> usually of 0 length so leave little clue as to what is creating them.
>

And there's the rub: how did this file come to exist? I'm certain it isn't
booting or shutting down the system based on when devfs is mounted (before
init) and unmounted (it's not done by the shutdown scripts). Now, it's
always possible there's a hole in my understanding of the sequence of
events. But given the examination of code, it's crazy to think this could
be created by anything but some weird bug. That's why a step-by-step from
scratch guide is needed. Im happy to look into it, but I need a bit more to
go on.

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r366169 - head/sys/mips/include

2020-09-25 Thread Warner Losh
On Fri, Sep 25, 2020 at 5:05 PM Jessica Clarke  wrote:

> On 26 Sep 2020, at 00:01, Alexander Richardson 
> wrote:
> >
> >
> > On Fri, 25 Sep 2020, 20:04 Justin Hibbits,  wrote:
> > Author: jhibbits
> > Date: Fri Sep 25 19:04:03 2020
> > New Revision: 366169
> > URL: https://svnweb.freebsd.org/changeset/base/366169
> >
> > Log:
> >   mips: Fix compat32 library builds from r366162
> >
> >   Re-add the a_ptr and a_fcn fields to Elf32_Auxinfo.
> >
> >   MFC after:1 week
> >   Sponsored by: Juniper Networks, Inc.
> >
> > Modified:
> >   head/sys/mips/include/elf.h
> >
> > Modified: head/sys/mips/include/elf.h
> >
> ==
> > --- head/sys/mips/include/elf.h Fri Sep 25 19:02:49 2020(r366168)
> > +++ head/sys/mips/include/elf.h Fri Sep 25 19:04:03 2020(r366169)
> > @@ -105,6 +105,10 @@ typedef struct {   /* Auxiliary vector entry on
> initial
> > int a_type; /* Entry type. */
> > union {
> > int a_val;  /* Integer value. */
> > +#ifndef __mips_n64
> > +   void*a_ptr; /* Address. */
> > +   void(*a_fcn)(void); /* Function pointer (not used).
> */
> > +#endif
> > } a_un;
> >  } Elf32_Auxinfo;
> >
> > Not sure what the current minimal compiler versions are, but maybe this
> should be #if __SIZEOF_POINTER__ == 4 instead of checking the ABI? This
> would break CHERI-MIPS kernels since we don't define __mips_n64 for the
> pure-capability ABI (128-bit pointers). However, we don't really do compat
> 32 right now so it probably doesn't matter much.
>
> Or why not just #if defined(__mips_o32) || defined(__mips_n32)?


I think we use that in other places for just this issue

Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366181 - head

2020-09-25 Thread Warner Losh
Author: imp
Date: Sat Sep 26 04:06:16 2020
New Revision: 366181
URL: https://svnweb.freebsd.org/changeset/base/366181

Log:
  fix typo imorted -> imported.
  
  Noticed by: Maigurs Stalidzans

Modified:
  head/UPDATING

Modified: head/UPDATING
==
--- head/UPDATING   Sat Sep 26 02:50:28 2020(r366180)
+++ head/UPDATING   Sat Sep 26 04:06:16 2020(r366181)
@@ -89,7 +89,7 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
successful or not) and run installworld once more.
 
 20200627:
-   A new implementation of bc and dc has been imorted in r362681. This
+   A new implementation of bc and dc has been imported in r362681. This
implementation corrects non-conformant behavior of the previous bc
and adds GNU bc compatible options. It offers a number of extensions,
is much faster on large values, and has support for message catalogs
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366173 - head/sys/sys

2020-09-25 Thread Warner Losh
Author: imp
Date: Fri Sep 25 20:51:07 2020
New Revision: 366173
URL: https://svnweb.freebsd.org/changeset/base/366173

Log:
  Adjustments to includes for openzfs in _STANDALONE
  
  Allow the necessary parts of systm.h to be visible in the _STANDALONE
  environnment. Limit the reset to only being visible for _KERNEL
  builds.  Map KASSERT, etc to printf on failure in the bootloader until
  we have more confidence things won't break and leave systems
  unbootable. Eventually, this should map to a full panic in the
  bootloader, but that also needs some enhancement to be more useful.
  
  Reviewed by: tsoome, jhb
  Differential Revision:  https://reviews.freebsd.org/D26543

Modified:
  head/sys/sys/systm.h

Modified: head/sys/sys/systm.h
==
--- head/sys/sys/systm.hFri Sep 25 20:39:20 2020(r366172)
+++ head/sys/sys/systm.hFri Sep 25 20:51:07 2020(r366173)
@@ -49,6 +49,7 @@
 
 __NULLABILITY_PRAGMA_PUSH
 
+#ifdef _KERNEL
 extern int cold;   /* nonzero if we are doing a cold boot */
 extern int suspend_blocked;/* block suspend due to pending shutdown */
 extern int rebooting;  /* kern_reboot() has been called. */
@@ -83,28 +84,7 @@ enum VM_GUEST { VM_GUEST_NO = 0, VM_GUEST_VM, VM_GUEST
VM_GUEST_VMWARE, VM_GUEST_KVM, VM_GUEST_BHYVE, VM_GUEST_VBOX,
VM_GUEST_PARALLELS, VM_LAST };
 
-/*
- * These functions need to be declared before the KASSERT macro is invoked in
- * !KASSERT_PANIC_OPTIONAL builds, so their declarations are sort of out of
- * place compared to other function definitions in this header.  On the other
- * hand, this header is a bit disorganized anyway.
- */
-void   panic(const char *, ...) __dead2 __printflike(1, 2);
-void   vpanic(const char *, __va_list) __dead2 __printflike(1, 0);
-
-#if defined(WITNESS) || defined(INVARIANT_SUPPORT)
-#ifdef KASSERT_PANIC_OPTIONAL
-void   kassert_panic(const char *fmt, ...)  __printflike(1, 2);
-#else
-#define kassert_panic  panic
-#endif
-#endif
-
 #ifdef INVARIANTS  /* The option is always available */
-#defineKASSERT(exp,msg) do {   
\
-   if (__predict_false(!(exp)))\
-   kassert_panic msg;  \
-} while (0)
 #defineVNASSERT(exp, vp, msg) do { 
\
if (__predict_false(!(exp))) {  \
vn_printf(vp, "VNASSERT failed: %s not true at %s:%d (%s)\n",\
@@ -121,9 +101,6 @@ voidkassert_panic(const char *fmt, ...)  
__printflike
panic("executing segment marked as unreachable at %s:%d (%s)\n", \
__FILE__, __LINE__, __func__)
 #else
-#defineKASSERT(exp,msg) do { \
-} while (0)
-
 #defineVNASSERT(exp, vp, msg) do { \
 } while (0)
 #defineVNPASS(exp, vp) do { \
@@ -134,14 +111,49 @@ void  kassert_panic(const char *fmt, ...)  
__printflike
 #ifndef CTASSERT   /* Allow lint to override */
 #defineCTASSERT(x) _Static_assert(x, "compile-time assertion 
failed")
 #endif
+#endif /* KERNEL */
 
-#if defined(_KERNEL)
-#include  /* MAXCPU */
-#include   /* curthread */
-#include 
-#endif
+/*
+ * These functions need to be declared before the KASSERT macro is invoked in
+ * !KASSERT_PANIC_OPTIONAL builds, so their declarations are sort of out of
+ * place compared to other function definitions in this header.  On the other
+ * hand, this header is a bit disorganized anyway.
+ */
+void   panic(const char *, ...) __dead2 __printflike(1, 2);
+void   vpanic(const char *, __va_list) __dead2 __printflike(1, 0);
 
+
+#if defined(_STANDALONE)
 /*
+ * Until we have more experience with KASSERTS that are called
+ * from the boot loader, they are off. The bootloader does this
+ * a little differently than the kernel (we just call printf atm).
+ * we avoid most of the common functions in the boot loader, so
+ * declare printf() here too.
+ */
+intprintf(const char *, ...) __printflike(1, 2);
+#  define kassert_panic printf
+#else /* !_STANDALONE */
+#  if defined(WITNESS) || defined(INVARIANT_SUPPORT)
+#ifdef KASSERT_PANIC_OPTIONAL
+void   kassert_panic(const char *fmt, ...)  __printflike(1, 2);
+#else
+#  define kassert_panicpanic
+#endif /* KASSERT_PANIC_OPTIONAL */
+#  endif /* defined(WITNESS) || defined(INVARIANT_SUPPORT) */
+#endif /* _STANDALONE */
+
+#if defined(INVARIANTS) || defined(_STANDALONE)
+#defineKASSERT(exp,msg) do {   
\
+   if (__predict_false(!(exp)))\
+   kassert_panic msg;  \
+} while (0)
+#else /* !INVARIANTS && !_STANDALONE */
+#defineKASSERT(exp,msg) do { \
+} while (0)
+#endif /* INVARIANTS || _STANDALONE */
+
+/*
  * 

svn commit: r366168 - head/sys/sys

2020-09-25 Thread Warner Losh
Author: imp
Date: Fri Sep 25 19:02:49 2020
New Revision: 366168
URL: https://svnweb.freebsd.org/changeset/base/366168

Log:
  Dont let kernel and standalone both be defined at the same time
  
  _KERNEL and _STANDALONE are different things. They cannot both be true
  at the same time. If things that are normally visible only to _KERNEL
  are needed for the _STANDALONE environment, you need to also make them
  visible to _STANDALONE. Often times, this will be just a subset of the
  required things for _KERNEL (eg global variables are but one example).
  
  sys/cdefs.h is included by pretty much everything in both the loader
  and the kernel, so is the ideal choke point.

Modified:
  head/sys/sys/cdefs.h

Modified: head/sys/sys/cdefs.h
==
--- head/sys/sys/cdefs.hFri Sep 25 18:55:50 2020(r366167)
+++ head/sys/sys/cdefs.hFri Sep 25 19:02:49 2020(r366168)
@@ -38,6 +38,10 @@
 #ifndef_SYS_CDEFS_H_
 #define_SYS_CDEFS_H_
 
+#if defined(_KERNEL) && defined(_STANDALONE)
+#error "_KERNEL and _STANDALONE are mutually exclusive"
+#endif
+
 /*
  * Testing against Clang-specific extensions.
  */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366164 - head/usr.sbin/efivar

2020-09-25 Thread Warner Losh
Author: imp
Date: Fri Sep 25 18:20:41 2020
New Revision: 366164
URL: https://svnweb.freebsd.org/changeset/base/366164

Log:
  Tweak output of the loader variable
  
  When the DEVICE_PATH is <= 4 that means it's effectively empty. I have
  a laptop that has a BIOS that likes to generate these:
  
  8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot2001
  : 01 00 00 00 04 00 45 00 46 00 49 00 20 00 55 00
  0010: 53 00 42 00 20 00 44 00 65 00 76 00 69 00 63 00
  0020: 65 00 00 00 7f ff 04 00 52 43
  
  which now decodes as
  8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot2001
  * EFI USB Device
  Empty path
  Option:
  : 52 43
  
  which matches my hand-decode.
  
  Add an extra newline after Option: to make it look nice.
  
  I suspect that these entries really should be VenHw entries instead,
  but my ability to change that is NIL, so cope with them as best we can.
  
  efibootmgr(8)'s output is fine and doesn't need adjusting.

Modified:
  head/usr.sbin/efivar/efiutil.c

Modified: head/usr.sbin/efivar/efiutil.c
==
--- head/usr.sbin/efivar/efiutil.c  Fri Sep 25 17:14:35 2020
(r366163)
+++ head/usr.sbin/efivar/efiutil.c  Fri Sep 25 18:20:41 2020
(r366164)
@@ -160,23 +160,27 @@ efi_print_load_option(uint8_t *data, size_t datalen, i
// We got to here, everything is good
printf("%c ", attr & LOAD_OPTION_ACTIVE ? '*' : ' ');
ucs2_to_utf8(descr, );
-   printf("%s", str);
+   printf("%s\n", str);
free(str);
-   while (dp < edp && SIZE(dp, edp) > sizeof(efidp_header)) {
-   efidp_format_device_path(buf, sizeof(buf), dp, SIZE(dp, edp));
-   rv = efivar_device_path_to_unix_path(dp, , , 
);
-   dp = (efidp)((char *)dp + efidp_size(dp));
-   printf(" %s\n", buf);
-   if (rv == 0) {
-   printf("  %*s:%s\n", len + (int)strlen(dev), dev, 
relpath);
-   free(dev);
-   free(relpath);
-   free(abspath);
+   if (fplen <= 4) {
+   printf("Empty path\n");
+   } else {
+   while (dp < edp && SIZE(dp, edp) > sizeof(efidp_header)) {
+   efidp_format_device_path(buf, sizeof(buf), dp, SIZE(dp, 
edp));
+   rv = efivar_device_path_to_unix_path(dp, , 
, );
+   dp = (efidp)((char *)dp + efidp_size(dp));
+   printf(" %s\n", buf);
+   if (rv == 0) {
+   printf("  %*s:%s\n", len + 
(int)strlen(dev), dev, relpath);
+   free(dev);
+   free(relpath);
+   free(abspath);
+   }
}
}
if (optlen == 0)
return;
-   printf("Options: ");
+   printf("Option:\n");
if (Aflag)
asciidump(opt, optlen);
else if (bflag)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r366165 - head/usr.sbin/efivar

2020-09-25 Thread Warner Losh
Author: imp
Date: Fri Sep 25 18:20:45 2020
New Revision: 366165
URL: https://svnweb.freebsd.org/changeset/base/366165

Log:
  Comment out bogus command line entry
  
  Linux implements -d to mean --print-decimal. We don't implement that
  and use -d for --device-path. Note that.

Modified:
  head/usr.sbin/efivar/efivar.c

Modified: head/usr.sbin/efivar/efivar.c
==
--- head/usr.sbin/efivar/efivar.c   Fri Sep 25 18:20:41 2020
(r366164)
+++ head/usr.sbin/efivar/efivar.c   Fri Sep 25 18:20:45 2020
(r366165)
@@ -59,7 +59,7 @@ static struct option longopts[] = {
{ "name",   required_argument,  NULL,   'n' },
{ "no-name",no_argument,NULL,   'N' },
{ "print",  no_argument,NULL,   'p' },
-   { "print-decimal",  no_argument,NULL,   'd' },
+// { "print-decimal",  no_argument,NULL,   'd' }, /* 
unimplemnted clash with linux version */
{ "raw-guid",   no_argument,NULL,   'R' },
{ "utf8",   no_argument,NULL,   'u' },
{ "write",  no_argument,NULL,   'w' },
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


  1   2   3   4   5   6   7   8   9   10   >