Re: get rid of pmap_copy()
On Sun, Apr 02, 2023 at 07:29:02PM +, Miod Vallat wrote:
> pmap_copy() is an optional pmap interface which has never been
> implemented. In pure Mary Kondo style, we should thank it for the joy it
> brought to CSRG people, and move it to the recycling bin - it's not
> going to be implemented anytime soon.
In Mach (Tevanian's thesis) it was described as:
"This routine is only advisory and need not do anything"
ok jsg@
>
> Index: share/man/man9/pmap.9
> ===
> RCS file: /OpenBSD/src/share/man/man9/pmap.9,v
> retrieving revision 1.19
> diff -u -p -r1.19 pmap.9
> --- share/man/man9/pmap.9 16 Dec 2019 10:34:04 - 1.19
> +++ share/man/man9/pmap.9 2 Apr 2023 19:23:11 -
> @@ -49,8 +49,7 @@
> .Nm pmap_growkernel ,
> .Nm pmap_update ,
> .Nm pmap_collect ,
> -.Nm pmap_virtual_space ,
> -.Nm pmap_copy
> +.Nm pmap_virtual_space
> .Nd machine dependent interface to the MMU
> .Sh SYNOPSIS
> .In machine/pmap.h
> @@ -366,9 +365,6 @@ it contains no valid mappings.
> .Fn pmap_collect "pmap_t pmap"
> .Ft void
> .Fn pmap_virtual_space "vaddr_t *vstartp" "vaddr_t *vendp"
> -.Ft void
> -.Fn pmap_copy "pmap_t dst_pmap" "pmap_t src_pmap" "vaddr_t dst_addr" \
> - "vsize_t len" "vaddr_t src_addr"
> .nr nS 0
> .Pp
> Wired memory allocation before the virtual memory system is bootstrapped
> @@ -398,26 +394,6 @@ is not expected to be used for some time
> module a chance to prioritize.
> The initial bounds of the kernel virtual address space are returned by
> .Fn pmap_virtual_space .
> -.Pp
> -The
> -.Fn pmap_copy
> -function copies the range specified by
> -.Fa src_addr
> -and
> -.Fa src_len
> -from
> -.Fa src_pmap
> -to the range described by
> -.Fa dst_addr
> -and
> -.Fa dst_len
> -in
> -.Fa dst_map .
> -.Fn pmap_copy
> -is called during a
> -.Xr fork 2
> -operation to give the child process an initial set of low-level
> -mappings.
> .Sh SEE ALSO
> .Xr fork 2 ,
> .Xr uvm_init 9
> Index: sys/arch/alpha/alpha/pmap.c
> ===
> RCS file: /OpenBSD/src/sys/arch/alpha/alpha/pmap.c,v
> retrieving revision 1.89
> diff -u -p -r1.89 pmap.c
> --- sys/arch/alpha/alpha/pmap.c 6 Feb 2023 11:16:22 - 1.89
> +++ sys/arch/alpha/alpha/pmap.c 2 Apr 2023 19:23:11 -
> @@ -2017,17 +2017,6 @@ pmap_extract(pmap_t pmap, vaddr_t va, pa
> }
>
> /*
> - * pmap_copy:[ INTERFACE ]
> - *
> - * Copy the mapping range specified by src_addr/len
> - * from the source map to the range dst_addr/len
> - * in the destination map.
> - *
> - * This routine is only advisory and need not do anything.
> - */
> -/* call deleted in */
> -
> -/*
> * pmap_collect: [ INTERFACE ]
> *
> * Garbage collects the physical map system for pages which are no
> Index: sys/arch/alpha/include/pmap.h
> ===
> RCS file: /OpenBSD/src/sys/arch/alpha/include/pmap.h,v
> retrieving revision 1.44
> diff -u -p -r1.44 pmap.h
> --- sys/arch/alpha/include/pmap.h 6 Feb 2023 11:16:22 - 1.44
> +++ sys/arch/alpha/include/pmap.h 2 Apr 2023 19:23:11 -
> @@ -155,7 +155,6 @@ void pmap_do_tlb_shootdown(struct cpu_in
> #define pmap_resident_count(pmap)
> ((pmap)->pm_stats.resident_count)
> #define pmap_wired_count(pmap) ((pmap)->pm_stats.wired_count)
>
> -#define pmap_copy(dp, sp, da, l, sa) /* nothing */
> #define pmap_update(pmap)/* nothing (yet) */
>
> #define pmap_proc_iflush(p, va, len) /* nothing */
> Index: sys/arch/amd64/amd64/pmap.c
> ===
> RCS file: /OpenBSD/src/sys/arch/amd64/amd64/pmap.c,v
> retrieving revision 1.162
> diff -u -p -r1.162 pmap.c
> --- sys/arch/amd64/amd64/pmap.c 30 Jan 2023 11:21:26 - 1.162
> +++ sys/arch/amd64/amd64/pmap.c 2 Apr 2023 19:23:11 -
> @@ -2257,17 +2257,6 @@ pmap_collect(struct pmap *pmap)
> }
> #endif
>
> -/*
> - * pmap_copy: copy mappings from one pmap to another
> - *
> - * => optional function
> - * void pmap_copy(dst_pmap, src_pmap, dst_addr, len, src_addr)
> - */
> -
> -/*
> - * defined as macro in pmap.h
> - */
> -
> void
> pmap_enter_special(vaddr_t va, paddr_t pa, vm_prot_t prot)
> {
> Index: sys/arch/amd64/include/pmap.h
> ===
> RCS file: /OpenBSD/src/sys/arch/amd64/include/pmap.h,v
> retrieving revision 1.85
> diff -u -p -r1.85 pmap.h
> --- sys/arch/amd64/include/pmap.h 31 Jan 2023 15:18:54 - 1.85
> +++ sys/arch/amd64/include/pmap.h 2 Apr 2023 19:23:11 -
> @@ -369,7 +369,6 @@ extern const long nbpd[], nkptpmax[];
>
> #define pmap_clear_modify(pg)pmap_clear_attrs(pg, PG_M)
> #define pmap_clear_reference(pg) pmap_clear_attrs(pg, PG_U)
> -#define pmap_copy(DP,SP,D,L,S)
> #d
Re: installer: disk crypto: always correct root disk default
On Sun, 2 Apr 2023 at 1:52 PM, Klemens Nanni wrote:
> For install, the root disk defaults to the first available [sw]d* disk.
>
> The new encryption question creates a softraid volume for you, which is
> obviously to be used as root disk.
>
> But on systems with multiple disks, the next one available may be another.
>
> Available disks are: sd0 sd1.
> Encrypt the root disk? (disk, 'no' or '?' for details) [no] sd0
> ...
> Available disks are: sd1 sd2.
> Which disk is the root disk? ('?' for details) [sd1] ?
> sd0: VirtIO, Block Device (5.0G)
> sd1: VirtIO, Block Device (5.0G)
> sd2: OPENBSD, SR CRYPTO, 006 (5.0G)
> Available disks are: sd1 sd2.
> Which disk is the root disk? ('?' for details) [sd1] sd1
>
> 'Encrypt the root disk?' is asked if and only if no softraid volume is
> assembled at that time, which means whatever volume exists afterwards is
> the intended root disk.
>
> Save and use it as default for the root question if set.
>
> This is nicely contained and has no behaviour change except for interactive
> crypto installs which now nail the default regardless of disk setup:
>
> Available disks are: sd1 sd2.
> Which disk is the root disk? ('?' for details) [sd2]
>
> OK?
>
> Index: install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.1239
> diff -u -p -r1.1239 install.sub
> --- install.sub 2 Apr 2023 00:58:07 - 1.1239
> +++ install.sub 2 Apr 2023 01:20:18 -
> @@ -310,6 +310,11 @@ get_softraid_chunks() {
> bioctl $_device 2>/dev/null | sed -n 's/.*<\(.*\).>$/\1/p'
> }
>
> +# Return list of softraid volumes.
> +get_softraid_volumes() {
> + bioctl softraid0 | sed -n 's/^softraid0.*\(sd[0-9]*\).*/\1/p'
> +}
> +
> # Return disk devices found in hw.disknames.
> get_dkdevs() {
> scan_disknames "${MDDKDEVS:-/^[sw]d[0-9][0-9]* /s/ .*//p}"
> @@ -2398,7 +2403,7 @@ is_rootdisk() {
>
> # Get global root information. ie. ROOTDISK, ROOTDEV and SWAPDEV.
> get_rootinfo() {
> - local _default=$(get_dkdevs_root) _dkdev
> + local _default=${CRYPTOVOLUME:-$(get_dkdevs_root)} _dkdev ml
> local _q="Which disk is the root disk? ('?' for details)"
>
> while :; do
> @@ -3078,7 +3083,7 @@ encrypt_root() {
>
> # Do not even try if softraid is in use already,
> # e.g. auto-assembled at boot or done in (S)hell.
> - [[ -z $(get_softraid_chunks) ]] || return
> + [[ -z $(get_softraid_volumes) ]] || return
>
> while :; do
> echo "Available disks are: $(get_dkdevs | sed
> 's/^$/none/')."
> @@ -3109,6 +3114,9 @@ __EOT
> done
>
> CRYPTOCHUNK=$_chunk
> + # No volumes existed before asking, but we just created one.
> + # Save it for later as sane root disk default.
> + CRYPTOVOLUME=$(get_softraid_volumes)
> }
>
> do_install() {
> @@ -3581,6 +3589,7 @@ NIFS=0
> export PS1="$MODE# "
> PUB_KEY=/etc/signify/openbsd-${VERSION}-base.pub
> CRYPTOCHUNK=
> +CRYPTOVOLUME=
> ROOTDEV=
> ROOTDISK=
> SETDIR="$VNAME/$ARCH"
>
>
Re: remove pci_{io,mem}_find
On Sun, Apr 02, 2023 at 07:09:40PM +, Miod Vallat wrote:
> pci_{io,mem}_find() have intentionally been left undocumented,
> developers being (rightfully) advised to use pci_mapreg_info() instead.
>
> The following diff removes these undocumented functions and converts
> their last few users.
>
> Bonus changes introduced while looking into this:
> - correctly cope with 64-bit memory bars in ppb, should there ever
> exist (I honestly believe that, should that be the case, this would
> have been noticed with failures to detect or attach devices in the
> past).
> - do not hardcode memory type for rtsx (although the fact the driver
> works implies that this isn't likely to ever be an I/O bar).
pci.c part should be a different commit
ok jsg@
>
> Index: share/man/man9/pci_mapreg_map.9
> ===
> RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v
> retrieving revision 1.1
> diff -u -p -u -p -r1.1 pci_mapreg_map.9
> --- share/man/man9/pci_mapreg_map.9 23 Feb 2019 04:54:25 - 1.1
> +++ share/man/man9/pci_mapreg_map.9 1 Apr 2023 17:15:36 -
> @@ -23,8 +23,6 @@
> .Nm pci_mapreg_info ,
> .Nm pci_mapreg_probe ,
> .Nm pci_mapreg_type
> -.\" .Nm pci_mem_find ,
> -.\" .Nm pci_io_find
> .Nd PCI register mappings
> .Sh SYNOPSIS
> .In dev/pci/pcivar.h
> @@ -63,24 +61,6 @@
> .Fa "pcitag_t tag"
> .Fa "int reg"
> .Fc
> -.\" .Ft int
> -.\" .Fo pci_mem_find
> -.\" .Fa "pci_chipset_tag_t pc"
> -.\" .Fa "pcitag_t pcitag"
> -.\" .Fa "int reg"
> -.\" .Fa "bus_addr_t *basep"
> -.\" .Fa "bus_size_t *sizep"
> -.\" .Fa "int *cacheablep"
> -.\" .Fc
> -.\" .Ft int
> -.\" .Fo pci_io_find
> -.\" .Fa "pci_chipset_tag_t pc"
> -.\" .Fa "pcitag_t pcitag"
> -.\" .Fa "int reg"
> -.\" .Fa "bus_addr_t *basep"
> -.\" .Fa "bus_size_t *sizep"
> -.\" .Fa "int *cacheablep"
> -.\" .Fc
> .Sh DESCRIPTION
> These functions provide wrappers and helpers around
> .Xr bus_space 9
> Index: sys/arch/hppa/dev/sti_pci_machdep.c
> ===
> RCS file: /cvs/src/sys/arch/hppa/dev/sti_pci_machdep.c,v
> retrieving revision 1.2
> diff -u -p -u -p -r1.2 sti_pci_machdep.c
> --- sys/arch/hppa/dev/sti_pci_machdep.c 10 Apr 2009 17:11:27 -
> 1.2
> +++ sys/arch/hppa/dev/sti_pci_machdep.c 1 Apr 2023 17:15:37 -
> @@ -51,22 +51,13 @@ sti_pci_is_console(struct pci_attach_arg
>* matches what PAGE0 says, then we are the console, and it
>* doesn't matter which BAR matched.
>*/
> - for (bar = PCI_MAPREG_START; bar <= PCI_MAPREG_PPB_END; ) {
> + for (bar = PCI_MAPREG_START; bar <= PCI_MAPREG_PPB_END; bar += 4) {
> cf = pci_conf_read(paa->pa_pc, paa->pa_tag, bar);
> -
> - if (PCI_MAPREG_TYPE(cf) == PCI_MAPREG_TYPE_IO) {
> - rc = pci_io_find(paa->pa_pc, paa->pa_tag, bar, &addr,
> - NULL);
> + rc = pci_mapreg_info(paa->pa_pc, paa->pa_tag, bar,
> + _PCI_MAPREG_TYPEBITS(cf), &addr, NULL, NULL);
> + if (PCI_MAPREG_TYPE(cf) == PCI_MAPREG_TYPE_MEM &&
> + PCI_MAPREG_MEM_TYPE(cf) == PCI_MAPREG_MEM_TYPE_64BIT)
> bar += 4;
> - } else {
> - rc = pci_mem_find(paa->pa_pc, paa->pa_tag, bar, &addr,
> - NULL, NULL);
> - if (PCI_MAPREG_MEM_TYPE(cf) ==
> - PCI_MAPREG_MEM_TYPE_64BIT)
> - bar += 8;
> - else
> - bar += 4;
> - }
>
> if (rc == 0 &&
> (hppa_hpa_t)addr == (hppa_hpa_t)PAGE0->mem_cons.pz_hpa)
> Index: sys/arch/macppc/pci/vgafb.c
> ===
> RCS file: /cvs/src/sys/arch/macppc/pci/vgafb.c,v
> retrieving revision 1.64
> diff -u -p -u -p -r1.64 vgafb.c
> --- sys/arch/macppc/pci/vgafb.c 31 Dec 2022 05:06:18 - 1.64
> +++ sys/arch/macppc/pci/vgafb.c 1 Apr 2023 17:15:37 -
> @@ -508,7 +508,7 @@ vgafb_mapregs(struct vgafb_softc *sc, st
> bus_addr_t ba;
> bus_size_t bs;
> int hasmem = 0, hasmmio = 0;
> - uint32_t i, cf;
> + uint32_t bar, cf;
> int rv;
>
> /*
> @@ -517,12 +517,12 @@ vgafb_mapregs(struct vgafb_softc *sc, st
>* For nvidia, this finds mmio 0x10 and frame memory 0x14.
>* Some nvidias have a 3rd mem region 0x18, which we ignore.
>*/
> - for (i = PCI_MAPREG_START; i <= PCI_MAPREG_PPB_END; i += 4) {
> - cf = pci_conf_read(pa->pa_pc, pa->pa_tag, i);
> + for (bar = PCI_MAPREG_START; bar <= PCI_MAPREG_PPB_END; bar += 4) {
> + cf = pci_conf_read(pa->pa_pc, pa->pa_tag, bar);
> if (PCI_MAPREG_TYPE(cf) == PCI_MAPREG_TYPE_MEM) {
> /* Memory mapping... frame memory or mmio? */
> - rv = pci_mem_f
get rid of pmap_copy()
pmap_copy() is an optional pmap interface which has never been
implemented. In pure Mary Kondo style, we should thank it for the joy it
brought to CSRG people, and move it to the recycling bin - it's not
going to be implemented anytime soon.
Index: share/man/man9/pmap.9
===
RCS file: /OpenBSD/src/share/man/man9/pmap.9,v
retrieving revision 1.19
diff -u -p -r1.19 pmap.9
--- share/man/man9/pmap.9 16 Dec 2019 10:34:04 - 1.19
+++ share/man/man9/pmap.9 2 Apr 2023 19:23:11 -
@@ -49,8 +49,7 @@
.Nm pmap_growkernel ,
.Nm pmap_update ,
.Nm pmap_collect ,
-.Nm pmap_virtual_space ,
-.Nm pmap_copy
+.Nm pmap_virtual_space
.Nd machine dependent interface to the MMU
.Sh SYNOPSIS
.In machine/pmap.h
@@ -366,9 +365,6 @@ it contains no valid mappings.
.Fn pmap_collect "pmap_t pmap"
.Ft void
.Fn pmap_virtual_space "vaddr_t *vstartp" "vaddr_t *vendp"
-.Ft void
-.Fn pmap_copy "pmap_t dst_pmap" "pmap_t src_pmap" "vaddr_t dst_addr" \
- "vsize_t len" "vaddr_t src_addr"
.nr nS 0
.Pp
Wired memory allocation before the virtual memory system is bootstrapped
@@ -398,26 +394,6 @@ is not expected to be used for some time
module a chance to prioritize.
The initial bounds of the kernel virtual address space are returned by
.Fn pmap_virtual_space .
-.Pp
-The
-.Fn pmap_copy
-function copies the range specified by
-.Fa src_addr
-and
-.Fa src_len
-from
-.Fa src_pmap
-to the range described by
-.Fa dst_addr
-and
-.Fa dst_len
-in
-.Fa dst_map .
-.Fn pmap_copy
-is called during a
-.Xr fork 2
-operation to give the child process an initial set of low-level
-mappings.
.Sh SEE ALSO
.Xr fork 2 ,
.Xr uvm_init 9
Index: sys/arch/alpha/alpha/pmap.c
===
RCS file: /OpenBSD/src/sys/arch/alpha/alpha/pmap.c,v
retrieving revision 1.89
diff -u -p -r1.89 pmap.c
--- sys/arch/alpha/alpha/pmap.c 6 Feb 2023 11:16:22 - 1.89
+++ sys/arch/alpha/alpha/pmap.c 2 Apr 2023 19:23:11 -
@@ -2017,17 +2017,6 @@ pmap_extract(pmap_t pmap, vaddr_t va, pa
}
/*
- * pmap_copy: [ INTERFACE ]
- *
- * Copy the mapping range specified by src_addr/len
- * from the source map to the range dst_addr/len
- * in the destination map.
- *
- * This routine is only advisory and need not do anything.
- */
-/* call deleted in */
-
-/*
* pmap_collect: [ INTERFACE ]
*
* Garbage collects the physical map system for pages which are no
Index: sys/arch/alpha/include/pmap.h
===
RCS file: /OpenBSD/src/sys/arch/alpha/include/pmap.h,v
retrieving revision 1.44
diff -u -p -r1.44 pmap.h
--- sys/arch/alpha/include/pmap.h 6 Feb 2023 11:16:22 - 1.44
+++ sys/arch/alpha/include/pmap.h 2 Apr 2023 19:23:11 -
@@ -155,7 +155,6 @@ voidpmap_do_tlb_shootdown(struct cpu_in
#definepmap_resident_count(pmap)
((pmap)->pm_stats.resident_count)
#definepmap_wired_count(pmap) ((pmap)->pm_stats.wired_count)
-#define pmap_copy(dp, sp, da, l, sa) /* nothing */
#define pmap_update(pmap) /* nothing (yet) */
#define pmap_proc_iflush(p, va, len) /* nothing */
Index: sys/arch/amd64/amd64/pmap.c
===
RCS file: /OpenBSD/src/sys/arch/amd64/amd64/pmap.c,v
retrieving revision 1.162
diff -u -p -r1.162 pmap.c
--- sys/arch/amd64/amd64/pmap.c 30 Jan 2023 11:21:26 - 1.162
+++ sys/arch/amd64/amd64/pmap.c 2 Apr 2023 19:23:11 -
@@ -2257,17 +2257,6 @@ pmap_collect(struct pmap *pmap)
}
#endif
-/*
- * pmap_copy: copy mappings from one pmap to another
- *
- * => optional function
- * void pmap_copy(dst_pmap, src_pmap, dst_addr, len, src_addr)
- */
-
-/*
- * defined as macro in pmap.h
- */
-
void
pmap_enter_special(vaddr_t va, paddr_t pa, vm_prot_t prot)
{
Index: sys/arch/amd64/include/pmap.h
===
RCS file: /OpenBSD/src/sys/arch/amd64/include/pmap.h,v
retrieving revision 1.85
diff -u -p -r1.85 pmap.h
--- sys/arch/amd64/include/pmap.h 31 Jan 2023 15:18:54 - 1.85
+++ sys/arch/amd64/include/pmap.h 2 Apr 2023 19:23:11 -
@@ -369,7 +369,6 @@ extern const long nbpd[], nkptpmax[];
#define pmap_clear_modify(pg) pmap_clear_attrs(pg, PG_M)
#define pmap_clear_reference(pg) pmap_clear_attrs(pg, PG_U)
-#define pmap_copy(DP,SP,D,L,S)
#define pmap_is_modified(pg) pmap_test_attrs(pg, PG_M)
#define pmap_is_referenced(pg) pmap_test_attrs(pg, PG_U)
#define pmap_move(DP,SP,D,L,S)
Index: sys/arch/arm/include/pmap.h
===
RCS file: /OpenBSD/src/sys/arch/arm/include/pmap.h,v
retrieving revision 1.53
diff -u -p -r1.53 pmap.h
--- sys/arch/arm/include/pmap.h 31 Jan 2023 15:18:54 - 1.53
+++ sys/arch/arm
remove pci_{io,mem}_find
pci_{io,mem}_find() have intentionally been left undocumented,
developers being (rightfully) advised to use pci_mapreg_info() instead.
The following diff removes these undocumented functions and converts
their last few users.
Bonus changes introduced while looking into this:
- correctly cope with 64-bit memory bars in ppb, should there ever
exist (I honestly believe that, should that be the case, this would
have been noticed with failures to detect or attach devices in the
past).
- do not hardcode memory type for rtsx (although the fact the driver
works implies that this isn't likely to ever be an I/O bar).
Index: share/man/man9/pci_mapreg_map.9
===
RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 pci_mapreg_map.9
--- share/man/man9/pci_mapreg_map.9 23 Feb 2019 04:54:25 - 1.1
+++ share/man/man9/pci_mapreg_map.9 1 Apr 2023 17:15:36 -
@@ -23,8 +23,6 @@
.Nm pci_mapreg_info ,
.Nm pci_mapreg_probe ,
.Nm pci_mapreg_type
-.\" .Nm pci_mem_find ,
-.\" .Nm pci_io_find
.Nd PCI register mappings
.Sh SYNOPSIS
.In dev/pci/pcivar.h
@@ -63,24 +61,6 @@
.Fa "pcitag_t tag"
.Fa "int reg"
.Fc
-.\" .Ft int
-.\" .Fo pci_mem_find
-.\" .Fa "pci_chipset_tag_t pc"
-.\" .Fa "pcitag_t pcitag"
-.\" .Fa "int reg"
-.\" .Fa "bus_addr_t *basep"
-.\" .Fa "bus_size_t *sizep"
-.\" .Fa "int *cacheablep"
-.\" .Fc
-.\" .Ft int
-.\" .Fo pci_io_find
-.\" .Fa "pci_chipset_tag_t pc"
-.\" .Fa "pcitag_t pcitag"
-.\" .Fa "int reg"
-.\" .Fa "bus_addr_t *basep"
-.\" .Fa "bus_size_t *sizep"
-.\" .Fa "int *cacheablep"
-.\" .Fc
.Sh DESCRIPTION
These functions provide wrappers and helpers around
.Xr bus_space 9
Index: sys/arch/hppa/dev/sti_pci_machdep.c
===
RCS file: /cvs/src/sys/arch/hppa/dev/sti_pci_machdep.c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 sti_pci_machdep.c
--- sys/arch/hppa/dev/sti_pci_machdep.c 10 Apr 2009 17:11:27 - 1.2
+++ sys/arch/hppa/dev/sti_pci_machdep.c 1 Apr 2023 17:15:37 -
@@ -51,22 +51,13 @@ sti_pci_is_console(struct pci_attach_arg
* matches what PAGE0 says, then we are the console, and it
* doesn't matter which BAR matched.
*/
- for (bar = PCI_MAPREG_START; bar <= PCI_MAPREG_PPB_END; ) {
+ for (bar = PCI_MAPREG_START; bar <= PCI_MAPREG_PPB_END; bar += 4) {
cf = pci_conf_read(paa->pa_pc, paa->pa_tag, bar);
-
- if (PCI_MAPREG_TYPE(cf) == PCI_MAPREG_TYPE_IO) {
- rc = pci_io_find(paa->pa_pc, paa->pa_tag, bar, &addr,
- NULL);
+ rc = pci_mapreg_info(paa->pa_pc, paa->pa_tag, bar,
+ _PCI_MAPREG_TYPEBITS(cf), &addr, NULL, NULL);
+ if (PCI_MAPREG_TYPE(cf) == PCI_MAPREG_TYPE_MEM &&
+ PCI_MAPREG_MEM_TYPE(cf) == PCI_MAPREG_MEM_TYPE_64BIT)
bar += 4;
- } else {
- rc = pci_mem_find(paa->pa_pc, paa->pa_tag, bar, &addr,
- NULL, NULL);
- if (PCI_MAPREG_MEM_TYPE(cf) ==
- PCI_MAPREG_MEM_TYPE_64BIT)
- bar += 8;
- else
- bar += 4;
- }
if (rc == 0 &&
(hppa_hpa_t)addr == (hppa_hpa_t)PAGE0->mem_cons.pz_hpa)
Index: sys/arch/macppc/pci/vgafb.c
===
RCS file: /cvs/src/sys/arch/macppc/pci/vgafb.c,v
retrieving revision 1.64
diff -u -p -u -p -r1.64 vgafb.c
--- sys/arch/macppc/pci/vgafb.c 31 Dec 2022 05:06:18 - 1.64
+++ sys/arch/macppc/pci/vgafb.c 1 Apr 2023 17:15:37 -
@@ -508,7 +508,7 @@ vgafb_mapregs(struct vgafb_softc *sc, st
bus_addr_t ba;
bus_size_t bs;
int hasmem = 0, hasmmio = 0;
- uint32_t i, cf;
+ uint32_t bar, cf;
int rv;
/*
@@ -517,12 +517,12 @@ vgafb_mapregs(struct vgafb_softc *sc, st
* For nvidia, this finds mmio 0x10 and frame memory 0x14.
* Some nvidias have a 3rd mem region 0x18, which we ignore.
*/
- for (i = PCI_MAPREG_START; i <= PCI_MAPREG_PPB_END; i += 4) {
- cf = pci_conf_read(pa->pa_pc, pa->pa_tag, i);
+ for (bar = PCI_MAPREG_START; bar <= PCI_MAPREG_PPB_END; bar += 4) {
+ cf = pci_conf_read(pa->pa_pc, pa->pa_tag, bar);
if (PCI_MAPREG_TYPE(cf) == PCI_MAPREG_TYPE_MEM) {
/* Memory mapping... frame memory or mmio? */
- rv = pci_mem_find(pa->pa_pc, pa->pa_tag, i,
- &ba, &bs, NULL);
+ rv = pci_mapreg_info(pa->pa_pc, pa->pa_tag, bar,
+ _PCI_MAPREG_TYPEBITS(cf), &ba, &bs, NULL);
if (rv != 0)
Re: [PATCH] Add -executable, -readable, and -writable options to /usr/bin/find
On Sun, Apr 02, 2023 at 10:39:00AM +0200, Kusalananda Kähäri wrote: > On Sat, Apr 01, 2023 at 08:18:56AM +0200, Solène Rapenne wrote: > > Le Fri, 31 Mar 2023 19:40:45 -0700, > > Jared Harper a écrit : > > > > > I have put together a patch that adds -executable, -readable, and > > > -writable to /usr/bin/find. > > > > > > When I first started working on this patch, I implemented the access > > > check by checking the stat of the file like so: > > > > > > > this doesn't add much value IMO, we already have -perm that can be used > > to return paths matching the permission, or only a bit. > > > > find . -executable can be written find . -type f -perm -100 > > find . -writable can be written find . -type f -perm -200 > > find . -readable can be written find . -type f -perm -400 > > > > on linux, those flags make sense to have because they also take care of > > ACLs, while their -perm doesn't. OpenBSD doesn't have ACLs. > > > Note that e.g. -executable tests whether the current item is readable s/readable/executable duh -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: [installer] default answer to "Is the disk partition already mounted?"
On Sat, Apr 01, 2023 at 04:31:59PM +, Klemens Nanni wrote:
> 01.04.2023 13:33, Mikhail пишет:
> $_answer may be unset, but you still pass it and thus rely on ask_yn()'s
> default 'no' answer.
>
> I'd just default-initialise up front and flip if conditions are met.
> This should read and reflect your intentions more clearly:
>
> local _answer=no
>
> [[ $MODE == upgrade ]] && _answer=yes
I agree with your and Omar's comments regarding the logic, here is
revised patch:
diff /usr/src
commit - 05633f8622c7ca2ec993bbb49b8324988d6be874
path + /usr/src
blob - 537a9ae361201fb685525ac31c6ab7cf374799a4
file + distrib/miniroot/install.sub
--- distrib/miniroot/install.sub
+++ distrib/miniroot/install.sub
@@ -2042,7 +2042,12 @@ install_disk() {
# Install sets from disk.
# Ask for the disk device containing the set files.
install_disk() {
- if ! ask_yn "Is the disk partition already mounted?" yes; then
+ local _answer=no
+
+ # In upgrade mode root disk's /etc/fstab are automounted
+ [[ $MODE == upgrade ]] && _answer=yes
+
+ if ! ask_yn "Is the disk partition already mounted?" $_answer; then
ask_which "disk" "contains the $MODE media" \
'$(bsort $(get_dkdevs))' \
'$(get_dkdevs_uninitialized)'
Re: [PATCH] Add -executable, -readable, and -writable options to /usr/bin/find
On Sat, Apr 01, 2023 at 08:18:56AM +0200, Solène Rapenne wrote:
> Le Fri, 31 Mar 2023 19:40:45 -0700,
> Jared Harper a écrit :
>
> > I have put together a patch that adds -executable, -readable, and
> > -writable to /usr/bin/find.
> >
> > When I first started working on this patch, I implemented the access
> > check by checking the stat of the file like so:
> >
>
> this doesn't add much value IMO, we already have -perm that can be used
> to return paths matching the permission, or only a bit.
>
> find . -executable can be written find . -type f -perm -100
> find . -writable can be written find . -type f -perm -200
> find . -readable can be written find . -type f -perm -400
>
> on linux, those flags make sense to have because they also take care of
> ACLs, while their -perm doesn't. OpenBSD doesn't have ACLs.
Note that e.g. -executable tests whether the current item is readable
by the current user, a test that is quite difficult to implement using
-perm (you would have to involve -user and possibly -group too, as well
as $LOGNAME).
With -executable as an example, you could avoid entering directories
that you don't have access to in a convenient way
find . -type d ! -executable -prune -o ...
GNU extensions to standard utilities are almost exclusively about
providing convenient shortcuts and convinient functionality to the lazy
user. Usually, this extra functionality is found in other standard
tools, or it can trivially be implemented by a short script written
in the shell or using awk etc., so their extensions often seems to be
running counter to the Unix philsophy of "do one thing and do it well".
But then again, "GNU is not Unix".
However, in this particular case, the extension is *useful* and not
at all trivial to implement with existing predicates in find(1) or by
calling other utilities. The above example could be implemented with
"find . -type d ! -exec cd {} \; -prune -o ..." on systems where cd(1)
is an external utility, which it is not on OpenBSD, so we would use
something silly like "! -exec sh -c 'cd "$1"' sh {} \;" instead, unless
we got either really creative or just ignored the fact that we can't
enter that directory and redirect all diagnostic messages to /dev/null.
Cheers,
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: [PATCH] Add -executable, -readable, and -writable options to /usr/bin/find
Stuart Henderson writes: > On 2023/04/01 11:27, Jared Harper wrote: > > For some reason I haven't received the email from Solène (even after > > requesting it re-sent on lists.openbsd.org; nor is it in spam; I will > > look further into this issue), so I'm adding my reply in-line here: > > Solène's domain publishes a DMARC p=reject record, so sites doing > strict DMARC checks will reject it when sent via mailing lists, > unless those lists rewrite the From address. I don't think that alone necessarily results in a DMARC failure, but combined with the list server stripping out the original DKIM signature it definitely does.
Re: [PATCH] Add -executable, -readable, and -writable options to /usr/bin/find
On 2023/03/31 19:40, Jared Harper wrote: > However, I had some difficulty finding the source of access(2) so I could not > vet by assumptions. see sys_access() in sys/kern/vfs_syscalls.c
Re: [PATCH] Add -executable, -readable, and -writable options to /usr/bin/find
On 2023/04/01 11:27, Jared Harper wrote: > For some reason I haven't received the email from Solène (even after > requesting it re-sent on lists.openbsd.org; nor is it in spam; I will > look further into this issue), so I'm adding my reply in-line here: Solène's domain publishes a DMARC p=reject record, so sites doing strict DMARC checks will reject it when sent via mailing lists, unless those lists rewrite the From address. > I suppose then that this point of confusion (the ambiguous nature of > what -executable, et al, actually does) is a good reason not to continue > on this patch. fwiw I didn't find it ambiguous, and it seems like it could be useful, although I don't think it's something I've ever tried to do myself. We have one patch in ports for -executable (in munin; the patch makes it use GNU find instead).
