Re: make arm64 can boot from partitions other than "a"
On Wed, 09 Jan 2019 16:47:32 +0900 (JST)
YASUOKA Masahiko wrote:
> The diff makes it can boot from paritions other than "a".
Let me explain the diff.
> Index: sys/arch/arm64/arm64/autoconf.c
> ===
> RCS file: /disk/cvs/openbsd/src/sys/arch/arm64/arm64/autoconf.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 autoconf.c
> --- sys/arch/arm64/arm64/autoconf.c 6 Feb 2018 20:35:21 - 1.9
> +++ sys/arch/arm64/arm64/autoconf.c 4 Jan 2019 13:40:58 -
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -68,7 +69,8 @@ diskconf(void)
> {
> size_t len;
> char*p;
> - dev_t tmpdev;
> + dev_t tmpdev = NODEV;
> + int part = 0;
> extern uint8_t *bootmac;
>
> if (*boot_file != '\0')
> @@ -82,6 +84,8 @@ diskconf(void)
> else
> len = strlen(boot_file);
> bootdv = parsedisk(boot_file, len, 0, &tmpdev);
> + if (tmpdev != NODEV)
> + part = DISKPART(tmpdev);
> }
>
parsedisk() parses the parition part. The diff is to keep it.
> #if defined(NFSCLIENT)
> @@ -105,7 +109,7 @@ diskconf(void)
> else
> printf("boot device: lookup %s failed \n", boot_file);
>
> - setroot(bootdv, 0, RB_USERREQ);
> + setroot(bootdv, part, RB_USERREQ);
> dumpconf();
>
> #ifdef HIBERNATE
Previously 0 ("a" partition) is passed to setroot() always.
By the diff, the partition kept above will be passed to setroot().
Then the kernel will use the partition specified by the bootargs for
the default root.
> Index: sys/arch/arm64/stand/efiboot/efidev.c
> ===
> RCS file: /disk/cvs/openbsd/src/sys/arch/arm64/stand/efiboot/efidev.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 efidev.c
> --- sys/arch/arm64/stand/efiboot/efidev.c 25 Aug 2018 20:43:39 -
> 1.2
> +++ sys/arch/arm64/stand/efiboot/efidev.c 4 Jan 2019 13:40:58 -
> @@ -484,7 +484,7 @@ efiopen(struct open_file *f, ...)
> part = va_arg(ap, u_int);
> va_end(ap);
>
> - if (unit != 0)
> + if (unit != 0 || MAXPARTITIONS <= part)
> return (ENXIO);
>
> diskinfo.ed.blkio = disk;
> @@ -512,7 +512,7 @@ efistrategy(void *devdata, int rw, daddr
>
> nsect = (size + DEV_BSIZE - 1) / DEV_BSIZE;
> blk += DL_SECTOBLK(&dip->disklabel,
> - dip->disklabel.d_partitions[B_PARTITION(dip->sc_part)].p_offset);
> + dip->disklabel.d_partitions[dip->sc_part].p_offset);
>
> if (blk < 0)
> error = EINVAL;
Second chunk is to fix a misuse of B_PARTITION(). B_PARTITION()'s
argument must be a "boot-style device number". dip->sc_part is usable
just as it is. First chunk is to check the value more strict since
it's used just as it is.
> Index: sys/arch/arm64/stand/efiboot/exec.c
> ===
> RCS file: /disk/cvs/openbsd/src/sys/arch/arm64/stand/efiboot/exec.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 exec.c
> --- sys/arch/arm64/stand/efiboot/exec.c 8 Feb 2017 09:18:24 -
> 1.5
> +++ sys/arch/arm64/stand/efiboot/exec.c 4 Jan 2019 13:40:58 -
> @@ -94,7 +94,7 @@ run_loadfile(u_long *marks, int howto)
> char *cp;
> void *fdt;
>
> - snprintf(args, sizeof(args) - 8, "%s:%s", cmd.bootdev, cmd.image);
> + strlcpy(args, cmd.path, sizeof(args));
> cp = args + strlen(args);
>
> *cp++ = ' ';
cmd.bootdev is the "device" variable and cmd.image is the "image"
variable of boot(8). They are used as defaults, but if a kernel is
specified as an argument for "boot" command, they are not used.
cmd.path is the real path that is used for loading a kernel. The diff
is to use it as the bootargs as it is.
Re: trunk shouldnt care if it's stacked
On Wed, Jan 09, 2019 at 01:12:31PM +1000, David Gwynne wrote: > -#define TRUNK_MAX_STACKING 4 /* maximum number of stacked trunks */ Is this an arbitrary limit or does it conceal other limitiations? The commit that added it lacks this information: revision 1.2 date: 2005/05/24 07:51:53; author: reyk; state: Exp; lines: +44 -10; support trunk stacking (trunks as trunk ports) and some fixes ok brad@ Since the flag TRUNK_PORT_STACK in if_trunk.h:33 is now unused, maybe add a comment to it for clarity?
Re: make arm64 can boot from partitions other than "a"
> Date: Wed, 09 Jan 2019 17:25:12 +0900 (JST)
> From: YASUOKA Masahiko
>
> On Wed, 09 Jan 2019 16:47:32 +0900 (JST)
> YASUOKA Masahiko wrote:
> > The diff makes it can boot from paritions other than "a".
>
> Let me explain the diff.
>
> > Index: sys/arch/arm64/arm64/autoconf.c
> > ===
> > RCS file: /disk/cvs/openbsd/src/sys/arch/arm64/arm64/autoconf.c,v
> > retrieving revision 1.9
> > diff -u -p -r1.9 autoconf.c
> > --- sys/arch/arm64/arm64/autoconf.c 6 Feb 2018 20:35:21 - 1.9
> > +++ sys/arch/arm64/arm64/autoconf.c 4 Jan 2019 13:40:58 -
> > @@ -19,6 +19,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -68,7 +69,8 @@ diskconf(void)
> > {
> > size_t len;
> > char*p;
> > - dev_t tmpdev;
> > + dev_t tmpdev = NODEV;
> > + int part = 0;
> > extern uint8_t *bootmac;
> >
> > if (*boot_file != '\0')
> > @@ -82,6 +84,8 @@ diskconf(void)
> > else
> > len = strlen(boot_file);
> > bootdv = parsedisk(boot_file, len, 0, &tmpdev);
> > + if (tmpdev != NODEV)
> > + part = DISKPART(tmpdev);
> > }
> >
>
> parsedisk() parses the parition part. The diff is to keep it.
>
> > #if defined(NFSCLIENT)
> > @@ -105,7 +109,7 @@ diskconf(void)
> > else
> > printf("boot device: lookup %s failed \n", boot_file);
> >
> > - setroot(bootdv, 0, RB_USERREQ);
> > + setroot(bootdv, part, RB_USERREQ);
> > dumpconf();
> >
> > #ifdef HIBERNATE
>
> Previously 0 ("a" partition) is passed to setroot() always.
> By the diff, the partition kept above will be passed to setroot().
>
> Then the kernel will use the partition specified by the bootargs for
> the default root.
>
> > Index: sys/arch/arm64/stand/efiboot/efidev.c
> > ===
> > RCS file: /disk/cvs/openbsd/src/sys/arch/arm64/stand/efiboot/efidev.c,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 efidev.c
> > --- sys/arch/arm64/stand/efiboot/efidev.c 25 Aug 2018 20:43:39 -
> > 1.2
> > +++ sys/arch/arm64/stand/efiboot/efidev.c 4 Jan 2019 13:40:58 -
> > @@ -484,7 +484,7 @@ efiopen(struct open_file *f, ...)
> > part = va_arg(ap, u_int);
> > va_end(ap);
> >
> > - if (unit != 0)
> > + if (unit != 0 || MAXPARTITIONS <= part)
> > return (ENXIO);
Can you make that "part >= MAXPARTITIONS". Easier to understand for
my brain!
> >
> > diskinfo.ed.blkio = disk;
> > @@ -512,7 +512,7 @@ efistrategy(void *devdata, int rw, daddr
> >
> > nsect = (size + DEV_BSIZE - 1) / DEV_BSIZE;
> > blk += DL_SECTOBLK(&dip->disklabel,
> > - dip->disklabel.d_partitions[B_PARTITION(dip->sc_part)].p_offset);
> > + dip->disklabel.d_partitions[dip->sc_part].p_offset);
> >
> > if (blk < 0)
> > error = EINVAL;
>
> Second chunk is to fix a misuse of B_PARTITION(). B_PARTITION()'s
> argument must be a "boot-style device number". dip->sc_part is usable
> just as it is. First chunk is to check the value more strict since
> it's used just as it is.
>
> > Index: sys/arch/arm64/stand/efiboot/exec.c
> > ===
> > RCS file: /disk/cvs/openbsd/src/sys/arch/arm64/stand/efiboot/exec.c,v
> > retrieving revision 1.5
> > diff -u -p -r1.5 exec.c
> > --- sys/arch/arm64/stand/efiboot/exec.c 8 Feb 2017 09:18:24 -
> > 1.5
> > +++ sys/arch/arm64/stand/efiboot/exec.c 4 Jan 2019 13:40:58 -
> > @@ -94,7 +94,7 @@ run_loadfile(u_long *marks, int howto)
> > char *cp;
> > void *fdt;
> >
> > - snprintf(args, sizeof(args) - 8, "%s:%s", cmd.bootdev, cmd.image);
> > + strlcpy(args, cmd.path, sizeof(args));
> > cp = args + strlen(args);
> >
> > *cp++ = ' ';
>
> cmd.bootdev is the "device" variable and cmd.image is the "image"
> variable of boot(8). They are used as defaults, but if a kernel is
> specified as an argument for "boot" command, they are not used.
> cmd.path is the real path that is used for loading a kernel. The diff
> is to use it as the bootargs as it is.
Thanks for the explanation. ok kettenis@ with the change suggested above.
Re: Convert bridge span & int. list to SLIST()
On 23/12/18(Sun) 14:41, Martin Pieuchot wrote:
> Using SLIST() instead of TAILQ() is a step towards using lock-less
> lists.
>
> As found in my previous attempts the interface list cannot be protected
> by a mutex as long a if_enqueue() might grab the KERNEL_LOCK(). So I'm
> heading towards using SRPL_*().
>
> Ok?
Anyone?
> Index: net/if_bridge.c
> ===
> RCS file: /cvs/src/sys/net/if_bridge.c,v
> retrieving revision 1.315
> diff -u -p -r1.315 if_bridge.c
> --- net/if_bridge.c 12 Dec 2018 14:19:15 - 1.315
> +++ net/if_bridge.c 12 Dec 2018 14:27:21 -
> @@ -108,6 +108,8 @@ void bridgeattach(int);
> int bridge_ioctl(struct ifnet *, u_long, caddr_t);
> void bridge_ifdetach(void *);
> void bridge_spandetach(void *);
> +int bridge_ifremove(struct bridge_iflist *);
> +int bridge_spanremove(struct bridge_iflist *);
> int bridge_input(struct ifnet *, struct mbuf *, void *);
> void bridge_process(struct ifnet *, struct mbuf *);
> void bridgeintr_frame(struct bridge_softc *, struct ifnet *, struct mbuf *);
> @@ -170,8 +172,8 @@ bridge_clone_create(struct if_clone *ifc
> sc->sc_brtmax = BRIDGE_RTABLE_MAX;
> sc->sc_brttimeout = BRIDGE_RTABLE_TIMEOUT;
> timeout_set(&sc->sc_brtimeout, bridge_rtage, sc);
> - TAILQ_INIT(&sc->sc_iflist);
> - TAILQ_INIT(&sc->sc_spanlist);
> + SLIST_INIT(&sc->sc_iflist);
> + SLIST_INIT(&sc->sc_spanlist);
> for (i = 0; i < BRIDGE_RTABLE_SIZE; i++)
> LIST_INIT(&sc->sc_rts[i]);
> arc4random_buf(&sc->sc_hashkey, sizeof(sc->sc_hashkey));
> @@ -216,10 +218,14 @@ bridge_clone_destroy(struct ifnet *ifp)
>
> bridge_stop(sc);
> bridge_rtflush(sc, IFBF_FLUSHALL);
> - while ((bif = TAILQ_FIRST(&sc->sc_iflist)) != NULL)
> + while ((bif = SLIST_FIRST(&sc->sc_iflist)) != NULL) {
> + SLIST_REMOVE_HEAD(&sc->sc_iflist, bif_next);
> bridge_delete(sc, bif);
> - while ((bif = TAILQ_FIRST(&sc->sc_spanlist)) != NULL)
> + }
> + while ((bif = SLIST_FIRST(&sc->sc_spanlist)) != NULL) {
> + SLIST_REMOVE_HEAD(&sc->sc_spanlist, bif_next);
> bridge_spandetach(bif);
> + }
>
> bstp_destroy(sc->sc_stp);
>
> @@ -249,7 +255,6 @@ bridge_delete(struct bridge_softc *sc, s
> hook_disestablish(bif->ifp->if_detachhooks, bif->bif_dhcookie);
>
> if_ih_remove(bif->ifp, bridge_input, NULL);
> - TAILQ_REMOVE(&sc->sc_iflist, bif, next);
> bridge_rtdelete(sc, bif->ifp, 0);
> bridge_flushrule(bif);
> free(bif, M_DEVBUF, sizeof *bif);
> @@ -297,7 +302,7 @@ bridge_ioctl(struct ifnet *ifp, u_long c
> }
>
> /* If it's in the span list, it can't be a member. */
> - TAILQ_FOREACH(bif, &sc->sc_spanlist, next) {
> + SLIST_FOREACH(bif, &sc->sc_spanlist, bif_next) {
> if (bif->ifp == ifs)
> break;
> }
> @@ -338,7 +343,7 @@ bridge_ioctl(struct ifnet *ifp, u_long c
> bif->bif_dhcookie = hook_establish(ifs->if_detachhooks, 0,
> bridge_ifdetach, bif);
> if_ih_insert(bif->ifp, bridge_input, NULL);
> - TAILQ_INSERT_TAIL(&sc->sc_iflist, bif, next);
> + SLIST_INSERT_HEAD(&sc->sc_iflist, bif, bif_next);
> break;
> case SIOCBRDGDEL:
> if ((error = suser(curproc)) != 0)
> @@ -353,7 +358,7 @@ bridge_ioctl(struct ifnet *ifp, u_long c
> error = ESRCH;
> break;
> }
> - error = bridge_delete(sc, bif);
> + error = bridge_ifremove(bif);
> break;
> case SIOCBRDGIFS:
> error = bridge_bifconf(sc, (struct ifbifconf *)data);
> @@ -375,7 +380,7 @@ bridge_ioctl(struct ifnet *ifp, u_long c
> error = EBUSY;
> break;
> }
> - TAILQ_FOREACH(bif, &sc->sc_spanlist, next) {
> + SLIST_FOREACH(bif, &sc->sc_spanlist, bif_next) {
> if (bif->ifp == ifs)
> break;
> }
> @@ -395,7 +400,7 @@ bridge_ioctl(struct ifnet *ifp, u_long c
> bridge_spandetach, bif);
> SIMPLEQ_INIT(&bif->bif_brlin);
> SIMPLEQ_INIT(&bif->bif_brlout);
> - TAILQ_INSERT_TAIL(&sc->sc_spanlist, bif, next);
> + SLIST_INSERT_HEAD(&sc->sc_spanlist, bif, bif_next);
> break;
> case SIOCBRDGDELS:
> if ((error = suser(curproc)) != 0)
> @@ -405,15 +410,15 @@ bridge_ioctl(struct ifnet *ifp, u_long c
> error = ENOENT;
> break;
> }
> - TAILQ_FOREACH(bif, &sc->sc_spanlist, next) {
> + SLIST_FOREACH(bif, &sc->sc_spanlist, bif_next) {
> if (bif->ifp == ifs)
>
ddb examine hex adjustment
Hi,
Printing hex values with right adjustment makes it easier to compare
corresponding digits. So I would like the change the ddb x/x output.
before:
0x803b1038: ff007c531cf0
0x803b1040: 0
0x803b1048: 81a05e29
0x803b1050: 1018
0x803b1058: 8001018
0x803b1060: 4000
0x803b1068: d72a7
0x803b1070: be704
0x803b1078: b3ae3
after:
0x803b1038: ff007c400cf0
0x803b1040:0
0x803b1048: 81a09b51
0x803b1050: 1018
0x803b1058: 8001018
0x803b1060: 4000
0x803b1068:d72a7
0x803b1070:be704
0x803b1078:b3ae3
ok?
bluhm
Index: ddb/db_examine.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/ddb/db_examine.c,v
retrieving revision 1.23
diff -u -p -r1.23 db_examine.c
--- ddb/db_examine.c18 Oct 2016 19:46:00 - 1.23
+++ ddb/db_examine.c9 Jan 2019 12:56:07 -
@@ -130,7 +130,7 @@ db_examine(db_addr_t addr, char *fmt, in
break;
case 'x': /* unsigned hex */
value = db_get_value(addr, size, FALSE);
- db_printf("%-*lx", width, (long)value);
+ db_printf("%*lx", width, (long)value);
break;
case 'm': /* hex dump */
/*
Re: ddb examine hex adjustment
Hello,
On Wed, Jan 09, 2019 at 02:05:23PM +0100, Alexander Bluhm wrote:
> Hi,
>
> Printing hex values with right adjustment makes it easier to compare
> corresponding digits. So I would like the change the ddb x/x output.
>
> before:
> 0x803b1038: ff007c531cf0
> 0x803b1040: 0
> 0x803b1048: 81a05e29
> 0x803b1050: 1018
> 0x803b1058: 8001018
> 0x803b1060: 4000
> 0x803b1068: d72a7
> 0x803b1070: be704
> 0x803b1078: b3ae3
>
> after:
> 0x803b1038: ff007c400cf0
> 0x803b1040:0
> 0x803b1048: 81a09b51
> 0x803b1050: 1018
> 0x803b1058: 8001018
> 0x803b1060: 4000
> 0x803b1068:d72a7
> 0x803b1070:be704
> 0x803b1078:b3ae3
>
> ok?
yes, please. I was about to send same diff.
sashan
>
> bluhm
>
> Index: ddb/db_examine.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/ddb/db_examine.c,v
> retrieving revision 1.23
> diff -u -p -r1.23 db_examine.c
> --- ddb/db_examine.c 18 Oct 2016 19:46:00 - 1.23
> +++ ddb/db_examine.c 9 Jan 2019 12:56:07 -
> @@ -130,7 +130,7 @@ db_examine(db_addr_t addr, char *fmt, in
> break;
> case 'x': /* unsigned hex */
> value = db_get_value(addr, size, FALSE);
> - db_printf("%-*lx", width, (long)value);
> + db_printf("%*lx", width, (long)value);
> break;
> case 'm': /* hex dump */
> /*
>
Re: Convert bridge span & int. list to SLIST()
On 09/01/19(Wed) 10:11, Martin Pieuchot wrote:
> On 23/12/18(Sun) 14:41, Martin Pieuchot wrote:
> > Using SLIST() instead of TAILQ() is a step towards using lock-less
> > lists.
> >
> > As found in my previous attempts the interface list cannot be protected
> > by a mutex as long a if_enqueue() might grab the KERNEL_LOCK(). So I'm
> > heading towards using SRPL_*().
Revised diff that plugs a leak and use SLIST_REMOVE() instead of
rerolling it, as pointed out by visa@.
ok?
Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.315
diff -u -p -r1.315 if_bridge.c
--- net/if_bridge.c 12 Dec 2018 14:19:15 - 1.315
+++ net/if_bridge.c 9 Jan 2019 18:10:45 -
@@ -108,6 +108,8 @@ voidbridgeattach(int);
intbridge_ioctl(struct ifnet *, u_long, caddr_t);
void bridge_ifdetach(void *);
void bridge_spandetach(void *);
+intbridge_ifremove(struct bridge_iflist *);
+intbridge_spanremove(struct bridge_iflist *);
intbridge_input(struct ifnet *, struct mbuf *, void *);
void bridge_process(struct ifnet *, struct mbuf *);
void bridgeintr_frame(struct bridge_softc *, struct ifnet *, struct mbuf *);
@@ -170,8 +172,8 @@ bridge_clone_create(struct if_clone *ifc
sc->sc_brtmax = BRIDGE_RTABLE_MAX;
sc->sc_brttimeout = BRIDGE_RTABLE_TIMEOUT;
timeout_set(&sc->sc_brtimeout, bridge_rtage, sc);
- TAILQ_INIT(&sc->sc_iflist);
- TAILQ_INIT(&sc->sc_spanlist);
+ SLIST_INIT(&sc->sc_iflist);
+ SLIST_INIT(&sc->sc_spanlist);
for (i = 0; i < BRIDGE_RTABLE_SIZE; i++)
LIST_INIT(&sc->sc_rts[i]);
arc4random_buf(&sc->sc_hashkey, sizeof(sc->sc_hashkey));
@@ -216,10 +218,12 @@ bridge_clone_destroy(struct ifnet *ifp)
bridge_stop(sc);
bridge_rtflush(sc, IFBF_FLUSHALL);
- while ((bif = TAILQ_FIRST(&sc->sc_iflist)) != NULL)
+ while ((bif = SLIST_FIRST(&sc->sc_iflist)) != NULL) {
+ SLIST_REMOVE_HEAD(&sc->sc_iflist, bif_next);
bridge_delete(sc, bif);
- while ((bif = TAILQ_FIRST(&sc->sc_spanlist)) != NULL)
- bridge_spandetach(bif);
+ }
+ while ((bif = SLIST_FIRST(&sc->sc_spanlist)) != NULL)
+ bridge_spanremove(bif);
bstp_destroy(sc->sc_stp);
@@ -249,7 +253,6 @@ bridge_delete(struct bridge_softc *sc, s
hook_disestablish(bif->ifp->if_detachhooks, bif->bif_dhcookie);
if_ih_remove(bif->ifp, bridge_input, NULL);
- TAILQ_REMOVE(&sc->sc_iflist, bif, next);
bridge_rtdelete(sc, bif->ifp, 0);
bridge_flushrule(bif);
free(bif, M_DEVBUF, sizeof *bif);
@@ -297,7 +300,7 @@ bridge_ioctl(struct ifnet *ifp, u_long c
}
/* If it's in the span list, it can't be a member. */
- TAILQ_FOREACH(bif, &sc->sc_spanlist, next) {
+ SLIST_FOREACH(bif, &sc->sc_spanlist, bif_next) {
if (bif->ifp == ifs)
break;
}
@@ -338,7 +341,7 @@ bridge_ioctl(struct ifnet *ifp, u_long c
bif->bif_dhcookie = hook_establish(ifs->if_detachhooks, 0,
bridge_ifdetach, bif);
if_ih_insert(bif->ifp, bridge_input, NULL);
- TAILQ_INSERT_TAIL(&sc->sc_iflist, bif, next);
+ SLIST_INSERT_HEAD(&sc->sc_iflist, bif, bif_next);
break;
case SIOCBRDGDEL:
if ((error = suser(curproc)) != 0)
@@ -353,7 +356,7 @@ bridge_ioctl(struct ifnet *ifp, u_long c
error = ESRCH;
break;
}
- error = bridge_delete(sc, bif);
+ error = bridge_ifremove(bif);
break;
case SIOCBRDGIFS:
error = bridge_bifconf(sc, (struct ifbifconf *)data);
@@ -375,7 +378,7 @@ bridge_ioctl(struct ifnet *ifp, u_long c
error = EBUSY;
break;
}
- TAILQ_FOREACH(bif, &sc->sc_spanlist, next) {
+ SLIST_FOREACH(bif, &sc->sc_spanlist, bif_next) {
if (bif->ifp == ifs)
break;
}
@@ -395,7 +398,7 @@ bridge_ioctl(struct ifnet *ifp, u_long c
bridge_spandetach, bif);
SIMPLEQ_INIT(&bif->bif_brlin);
SIMPLEQ_INIT(&bif->bif_brlout);
- TAILQ_INSERT_TAIL(&sc->sc_spanlist, bif, next);
+ SLIST_INSERT_HEAD(&sc->sc_spanlist, bif, bif_next);
break;
case SIOCBRDGDELS:
if ((error = suser(curproc)) != 0)
@@ -405,15 +408,15 @@ bridge_ioctl(struct ifnet *ifp, u_long c
error = ENOENT;
break;
}
- TAILQ_FOREACH(bif, &sc->sc_spanlist, next) {
+ SLIST_FOREACH(bif, &s
off by one in pfkeyv2_sysctl_policydumper()
The last extension type isn't set in pfkeyv2_sysctl_policydumper().
So fix the bug instead of working around it in export_counter().
ok?
Index: net/pfkeyv2.c
===
RCS file: /cvs/src/sys/net/pfkeyv2.c,v
retrieving revision 1.193
diff -u -p -r1.193 pfkeyv2.c
--- net/pfkeyv2.c 18 Dec 2018 13:18:31 - 1.193
+++ net/pfkeyv2.c 9 Jan 2019 18:25:38 -
@@ -2567,7 +2567,7 @@ pfkeyv2_sysctl_policydumper(struct ipsec
w->w_where += sizeof(msg);
w->w_len -= sizeof(msg);
/* set extension type */
- for (i = 1; i < SADB_EXT_MAX; i++)
+ for (i = 1; i <= SADB_EXT_MAX; i++)
if (headers[i])
((struct sadb_ext *)
headers[i])->sadb_ext_type = i;
Index: net/pfkeyv2_convert.c
===
RCS file: /cvs/src/sys/net/pfkeyv2_convert.c,v
retrieving revision 1.64
diff -u -p -r1.64 pfkeyv2_convert.c
--- net/pfkeyv2_convert.c 28 Aug 2018 15:15:02 - 1.64
+++ net/pfkeyv2_convert.c 9 Jan 2019 18:21:23 -
@@ -904,9 +904,8 @@ export_counter(void **p, struct tdb *tdb
{
struct sadb_x_counter *scnt = (struct sadb_x_counter *)*p;
- scnt->sadb_x_counter_len =
- sizeof(struct sadb_x_counter) / sizeof(uint64_t);
- scnt->sadb_x_counter_exttype = SADB_X_EXT_COUNTER;
+ scnt->sadb_x_counter_len = sizeof(struct sadb_x_counter) /
+ sizeof(uint64_t);
scnt->sadb_x_counter_ipackets = tdb->tdb_ipackets;
scnt->sadb_x_counter_opackets = tdb->tdb_opackets;
scnt->sadb_x_counter_ibytes = tdb->tdb_ibytes;
Re: http://cvshome.org no longer related to CVS version control.
On Tue, Jan 08 2019, Alexander Bluhm wrote:
> On Tue, Jan 08, 2019 at 05:13:11PM +0100, Jeremie Courreges-Anglas wrote:
>> >> reading the cvs man page I realized that there are a lot of references to
>> >> the cvshome.org site , but it is not the cvs home page anymore.
>>
>> I remember some people being confused in the past, maybe this could be
>> improved. And the easiest way to do that would be to just delete those
>> links.
>
> Just remove the link from the usage. If people want to find
> docmumentation, they should look into the man page or use a web
> search engine.
Here's a diff that kills all occurrences of loria.fr and cvshome.org
(plus sourrounding fluff) in the *installed* files.
Objections/oks?
Index: contrib/README
===
RCS file: /cvs/src/gnu/usr.bin/cvs/contrib/README,v
retrieving revision 1.1.1.9
diff -u -p -r1.1.1.9 README
--- contrib/README 28 Feb 1999 21:34:13 - 1.1.1.9
+++ contrib/README 9 Jan 2019 20:04:33 -
@@ -20,11 +20,6 @@ If you have some software that works wit
is suggested that you make it available by FTP or HTTP and then announce
it on the info-cvs mailing list.
-There is a web page of software related to CVS at the following URL which
-would presumably be willing to list your software.
-
- http://www.loria.fr/~molli/cvs-index.html
-
An attempt at a table of Contents for this directory:
README This file.
Index: doc/cvs.texinfo
===
RCS file: /cvs/src/gnu/usr.bin/cvs/doc/cvs.texinfo,v
retrieving revision 1.3
diff -u -p -r1.3 cvs.texinfo
--- doc/cvs.texinfo 4 Sep 2016 06:07:47 - 1.3
+++ doc/cvs.texinfo 9 Jan 2019 20:04:34 -
@@ -246,16 +246,6 @@ In April, 1989, Brian Berliner designed
Jeff Polk later helped Brian with the design of the @sc{cvs}
module and vendor branch support.
-@cindex Source, getting CVS source
-You can get @sc{cvs} in a variety of ways, including
-free download from the internet. For more information
-on downloading @sc{cvs} and other @sc{cvs} topics, see:
-
-@example
-http://www.cvshome.org/
-http://www.loria.fr/~molli/cvs-index.html
-@end example
-
@cindex Mailing list
@cindex List, mailing list
@cindex Newsgroups
@@ -13622,24 +13612,6 @@ fix for inclusion in future releases of
the file @sc{hacking} in the @sc{cvs} source
distribution. It contains much more information on the
process of submitting fixes.
-
-@item
-There may be resources on the net which can help. Two
-good places to start are:
-
-@example
-http://www.cvshome.org
-http://www.loria.fr/~molli/cvs-index.html
-@end example
-
-If you are so inspired, increasing the information
-available on the net is likely to be appreciated. For
-example, before the standard @sc{cvs} distribution
-worked on Windows 95, there was a web page with some
-explanation and patches for running @sc{cvs} on Windows
-95, and various people helped out by mentioning this
-page on mailing lists or newsgroups when the subject
-came up.
@item
It is also possible to report bugs to @code{bug-cvs}.
Index: doc/cvsclient.texi
===
RCS file: /cvs/src/gnu/usr.bin/cvs/doc/cvsclient.texi,v
retrieving revision 1.1.1.18
diff -u -p -r1.1.1.18 cvsclient.texi
--- doc/cvsclient.texi 28 Sep 2001 22:45:42 - 1.1.1.18
+++ doc/cvsclient.texi 9 Jan 2019 20:04:34 -
@@ -2004,8 +2004,6 @@ working directory, and the meaning of se
A number of enhancements are possible. Also see the file @sc{todo} in
the @sc{cvs} source distribution, which has further ideas concerning
various aspects of @sc{cvs}, some of which impact the protocol.
-Similarly, the @code{http://www.cvshome.org} site, in particular the
-@cite{Development} pages.
@itemize @bullet
@item
Index: man/cvs.1
===
RCS file: /cvs/src/gnu/usr.bin/cvs/man/cvs.1,v
retrieving revision 1.12
diff -u -p -r1.12 cvs.1
--- man/cvs.1 3 Jun 2013 17:02:36 - 1.12
+++ man/cvs.1 9 Jan 2019 20:04:34 -
@@ -2140,7 +2140,6 @@ For CVS updates, more information on doc
to CVS, development of CVS, and more, see:
.in +1i
.B http://www.cyclic.com
-.B http://www.loria.fr/~molli/cvs-index.html
.in -1i
.sp
.BR ci ( 1 ),
Index: src/main.c
===
RCS file: /cvs/src/gnu/usr.bin/cvs/src/main.c,v
retrieving revision 1.42
diff -u -p -r1.42 main.c
--- src/main.c 17 Nov 2015 12:26:47 - 1.42
+++ src/main.c 9 Jan 2019 20:04:35 -
@@ -176,24 +176,6 @@ static const char *const usg[] =
"(specify -H followed by a command name for command-specific help)\n",
" Specify --help to receive this message\n",
"\n",
-
-/* Some people think that a bug-reporting address should go here. IMHO,
- the web sites are better because anything else is very likely to
Re: http://cvshome.org no longer related to CVS version control.
On Wed, Jan 09, 2019 at 09:07:40PM +0100, Jeremie Courreges-Anglas wrote:
> On Tue, Jan 08 2019, Alexander Bluhm wrote:
> > On Tue, Jan 08, 2019 at 05:13:11PM +0100, Jeremie Courreges-Anglas wrote:
> >> >> reading the cvs man page I realized that there are a lot of references
> >> >> to
> >> >> the cvshome.org site , but it is not the cvs home page anymore.
> >>
> >> I remember some people being confused in the past, maybe this could be
> >> improved. And the easiest way to do that would be to just delete those
> >> links.
> >
> > Just remove the link from the usage. If people want to find
> > docmumentation, they should look into the man page or use a web
> > search engine.
>
> Here's a diff that kills all occurrences of loria.fr and cvshome.org
> (plus sourrounding fluff) in the *installed* files.
>
> Objections/oks?
OK bluhm@
> Index: contrib/README
> ===
> RCS file: /cvs/src/gnu/usr.bin/cvs/contrib/README,v
> retrieving revision 1.1.1.9
> diff -u -p -r1.1.1.9 README
> --- contrib/README28 Feb 1999 21:34:13 - 1.1.1.9
> +++ contrib/README9 Jan 2019 20:04:33 -
> @@ -20,11 +20,6 @@ If you have some software that works wit
> is suggested that you make it available by FTP or HTTP and then announce
> it on the info-cvs mailing list.
>
> -There is a web page of software related to CVS at the following URL which
> -would presumably be willing to list your software.
> -
> - http://www.loria.fr/~molli/cvs-index.html
> -
> An attempt at a table of Contents for this directory:
>
> README This file.
> Index: doc/cvs.texinfo
> ===
> RCS file: /cvs/src/gnu/usr.bin/cvs/doc/cvs.texinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 cvs.texinfo
> --- doc/cvs.texinfo 4 Sep 2016 06:07:47 - 1.3
> +++ doc/cvs.texinfo 9 Jan 2019 20:04:34 -
> @@ -246,16 +246,6 @@ In April, 1989, Brian Berliner designed
> Jeff Polk later helped Brian with the design of the @sc{cvs}
> module and vendor branch support.
>
> -@cindex Source, getting CVS source
> -You can get @sc{cvs} in a variety of ways, including
> -free download from the internet. For more information
> -on downloading @sc{cvs} and other @sc{cvs} topics, see:
> -
> -@example
> -http://www.cvshome.org/
> -http://www.loria.fr/~molli/cvs-index.html
> -@end example
> -
> @cindex Mailing list
> @cindex List, mailing list
> @cindex Newsgroups
> @@ -13622,24 +13612,6 @@ fix for inclusion in future releases of
> the file @sc{hacking} in the @sc{cvs} source
> distribution. It contains much more information on the
> process of submitting fixes.
> -
> -@item
> -There may be resources on the net which can help. Two
> -good places to start are:
> -
> -@example
> -http://www.cvshome.org
> -http://www.loria.fr/~molli/cvs-index.html
> -@end example
> -
> -If you are so inspired, increasing the information
> -available on the net is likely to be appreciated. For
> -example, before the standard @sc{cvs} distribution
> -worked on Windows 95, there was a web page with some
> -explanation and patches for running @sc{cvs} on Windows
> -95, and various people helped out by mentioning this
> -page on mailing lists or newsgroups when the subject
> -came up.
>
> @item
> It is also possible to report bugs to @code{bug-cvs}.
> Index: doc/cvsclient.texi
> ===
> RCS file: /cvs/src/gnu/usr.bin/cvs/doc/cvsclient.texi,v
> retrieving revision 1.1.1.18
> diff -u -p -r1.1.1.18 cvsclient.texi
> --- doc/cvsclient.texi28 Sep 2001 22:45:42 - 1.1.1.18
> +++ doc/cvsclient.texi9 Jan 2019 20:04:34 -
> @@ -2004,8 +2004,6 @@ working directory, and the meaning of se
> A number of enhancements are possible. Also see the file @sc{todo} in
> the @sc{cvs} source distribution, which has further ideas concerning
> various aspects of @sc{cvs}, some of which impact the protocol.
> -Similarly, the @code{http://www.cvshome.org} site, in particular the
> -@cite{Development} pages.
>
> @itemize @bullet
> @item
> Index: man/cvs.1
> ===
> RCS file: /cvs/src/gnu/usr.bin/cvs/man/cvs.1,v
> retrieving revision 1.12
> diff -u -p -r1.12 cvs.1
> --- man/cvs.1 3 Jun 2013 17:02:36 - 1.12
> +++ man/cvs.1 9 Jan 2019 20:04:34 -
> @@ -2140,7 +2140,6 @@ For CVS updates, more information on doc
> to CVS, development of CVS, and more, see:
> .in +1i
> .B http://www.cyclic.com
> -.B http://www.loria.fr/~molli/cvs-index.html
> .in -1i
> .sp
> .BR ci ( 1 ),
> Index: src/main.c
> ===
> RCS file: /cvs/src/gnu/usr.bin/cvs/src/main.c,v
> retrieving revision 1.42
> diff -u -p -r1.42 main.c
> --- src/main.c17 Nov 2015 12:26:47 - 1.42
> +++ src/main.c9 Jan 2019 20:04:35 -
>
Re: Implement Event()/Signal()/Wait() AML operations
Mark Kettenis wrote:
> Index: dev/acpi/dsdt.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
> retrieving revision 1.243
> diff -u -p -r1.243 dsdt.c
> --- dev/acpi/dsdt.c 19 Aug 2018 08:23:47 - 1.243
> +++ dev/acpi/dsdt.c 8 Jan 2019 18:55:14 -
> @@ -2905,29 +2905,33 @@ int
> acpi_event_wait(struct aml_scope *scope, struct aml_value *evt, int timeout)
> {
> /* Wait for event to occur; do work in meantime */
> - evt->v_evt.state = 0;
> - while (!evt->v_evt.state) {
> - if (!acpi_dotask(acpi_softc) && !cold)
> - tsleep(evt, PWAIT, "acpievt", 1);
> - else
> - delay(100);
> + while (evt->v_evt.state == 0 && timeout >= 0) {
> + if (acpi_dotask(acpi_softc))
> + continue;
> + if (!cold) {
> + if (rwsleep(evt, &acpi_softc->sc_lck, PWAIT,
> + "acpievt", 1) == EWOULDBLOCK) {
> + if (timeout < 0x)
> + timeout -= (1000 / hz);
> + }
> + } else {
> + delay(1000);
> + if (timeout < 0x)
> + timeout--;
> + }
Does 0x come from ACPI? Can we give that a name?
I thought sleeping for one tick is kinda weird, but I see what it's doing with
the acpi_dotask loop. This feels precarious, but whatever.
Re: trunk shouldnt care if it's stacked
On Wed, Jan 9, 2019 at 1:11 AM Klemens Nanni wrote: > On Wed, Jan 09, 2019 at 01:12:31PM +1000, David Gwynne wrote: > > -#define TRUNK_MAX_STACKING 4 /* maximum number of stacked > trunks */ > Is this an arbitrary limit or does it conceal other limitiations? > If stacking is handled via possibly recursive calls then there's an effective limit imposed by size of the kernel stack. Imposing a depth limit also prevents looping a stack by adding an upper trunk to a bottom one. Philip Guenther
Re: trunk shouldnt care if it's stacked
Philip Guenther wrote: > On Wed, Jan 9, 2019 at 1:11 AM Klemens Nanni wrote: > > > On Wed, Jan 09, 2019 at 01:12:31PM +1000, David Gwynne wrote: > > > -#define TRUNK_MAX_STACKING 4 /* maximum number of stacked > > trunks */ > > Is this an arbitrary limit or does it conceal other limitiations? > > > > If stacking is handled via possibly recursive calls then there's an > effective limit imposed by size of the kernel stack. > > Imposing a depth limit also prevents looping a stack by adding an upper > trunk to a bottom one. David please stack 100 times. Does it work?
Re: Implement Event()/Signal()/Wait() AML operations
Ted Unangst wrote: > > Does 0x come from ACPI? Can we give that a name? > > I thought sleeping for one tick is kinda weird, but I see what it's doing with > the acpi_dotask loop. This feels precarious, but whatever. So upon further thought, this is pretty bad. If the new task also calls sem wait, we'll end up back here, recursing on the event loop. And of course, the first sem can't wakeup until after the second one does. If you want to say it was like this when you got here, ok, but pretending to pause like this is troublesome. There was a bug in libc rpc code where it tried to do something similar and blew up the stack.
