Re: ldomctl, ldomd: Honour DEBUG in Makefile
Seems accidentally left over from development. As a rule we don't
ship with -g.
Klemens Nanni wrote:
> As of now, `export DEBUG=... ; make' will ignore my flags.
>
> I guess kettenis wanted symbols by default, so leave a default DEBUG
> value that allows overwriting instead of omitting DEBUG as usual.
>
> OK?
>
>
> Index: ldomctl/Makefile
> ===
> RCS file: /cvs/src/usr.sbin/ldomctl/Makefile,v
> retrieving revision 1.9
> diff -u -p -r1.9 Makefile
> --- ldomctl/Makefile 28 Jul 2019 15:30:45 - 1.9
> +++ ldomctl/Makefile 19 Nov 2019 22:16:19 -
> @@ -8,7 +8,7 @@ PROG= ldomctl
> SRCS=ldomctl.c ds.c mdesc.c util.c mdstore.c pri.c config.c parse.y
> CFLAGS+=-Wall
> CFLAGS+=-I${.CURDIR}/../ldomd -I${.CURDIR}
> -DEBUG= -g
> +DEBUG?= -g
>
> .else
>
> Index: ldomd/Makefile
> ===
> RCS file: /cvs/src/usr.sbin/ldomd/Makefile,v
> retrieving revision 1.5
> diff -u -p -r1.5 Makefile
> --- ldomd/Makefile28 Jul 2019 15:30:45 - 1.5
> +++ ldomd/Makefile19 Nov 2019 22:16:23 -
> @@ -8,7 +8,7 @@ PROG= ldomd
> SRCS=ldomd.c ds.c mdesc.c util.c var-config.c
> CFLAGS+=-Wall
> CFLAGS+=-I${.CURDIR}/../ldomctl
> -DEBUG= -g
> +DEBUG?= -g
>
> .else
>
>
Re: sdhc(4): no 0V one some Intel
On Tue, Nov 19, 2019 at 10:44:54AM +0100, Patrick Wildt wrote: > > Hi, Hi Patrick, > on some GPD Pocket mlarkin@ has the eMMC doesn't come up. One issue > is that we shouldn't go to 0V on some/most(?) Intel controllers. This > only adds it for his machine, but I know that the Appollo Lake versions > might also work if added to this check. But unless verified I'll not > add it. This makes mlarkin@'s machine work, even though it's utterly > slow. That would be the next thing to fix... probably low clocks or > doesn't use 8-bit. James Hastings has a similar diff for Intel Apollo Lake and Gemini Lake: https://www.mail-archive.com/tech@openbsd.org/msg51024.html It did work on my Apollo Lake box. > ok? > > Patrick > > diff --git a/sys/dev/pci/sdhc_pci.c b/sys/dev/pci/sdhc_pci.c > index d1b6688f573..dd6bc79c29c 100644 > --- a/sys/dev/pci/sdhc_pci.c > +++ b/sys/dev/pci/sdhc_pci.c > @@ -127,6 +127,11 @@ sdhc_pci_attach(struct device *parent, struct device > *self, void *aux) > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ENE_SDCARD) > sc->sc.sc_flags |= SDHC_F_NOPWR0; > > + /* Some Intel controllers break if set to 0V bus power. */ > + if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_INTEL && > + PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_INTEL_100SERIES_LP_EMMC) > + sc->sc.sc_flags |= SDHC_F_NOPWR0; > + > /* Some RICOH controllers need to be bumped into the right mode. */ > if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_RICOH && > (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_RICOH_R5U822 || >
ldomctl, ldomd: Honour DEBUG in Makefile
As of now, `export DEBUG=... ; make' will ignore my flags.
I guess kettenis wanted symbols by default, so leave a default DEBUG
value that allows overwriting instead of omitting DEBUG as usual.
OK?
Index: ldomctl/Makefile
===
RCS file: /cvs/src/usr.sbin/ldomctl/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- ldomctl/Makefile28 Jul 2019 15:30:45 - 1.9
+++ ldomctl/Makefile19 Nov 2019 22:16:19 -
@@ -8,7 +8,7 @@ PROG= ldomctl
SRCS= ldomctl.c ds.c mdesc.c util.c mdstore.c pri.c config.c parse.y
CFLAGS+=-Wall
CFLAGS+=-I${.CURDIR}/../ldomd -I${.CURDIR}
-DEBUG= -g
+DEBUG?=-g
.else
Index: ldomd/Makefile
===
RCS file: /cvs/src/usr.sbin/ldomd/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- ldomd/Makefile 28 Jul 2019 15:30:45 - 1.5
+++ ldomd/Makefile 19 Nov 2019 22:16:23 -
@@ -8,7 +8,7 @@ PROG= ldomd
SRCS= ldomd.c ds.c mdesc.c util.c var-config.c
CFLAGS+=-Wall
CFLAGS+=-I${.CURDIR}/../ldomctl
-DEBUG= -g
+DEBUG?=-g
.else
Re: unwind: log missing config file
On 2019/11/19 20:48, Klemens Nanni wrote: > On Tue, Nov 19, 2019 at 12:15:34AM +0100, Klemens Nanni wrote: > > On Mon, Nov 18, 2019 at 10:19:47PM +0100, Klemens Nanni wrote: > > > With that, my initial case is no longer misleading; alternatively, I > > > can implement the dash semantic, but that's another diff. > > Hm, that makes the default setup (no /etc/unwind.conf, empty > > unwind_flags) always print a warning, which is ugly. > I looked for other daemons and vmd(8) behaves just like that: > > # vmd -dnf/nonexistent ; echo $? > failed to open /nonexistent: No such file or directory > configuration OK > 0 > > # mv /etc/vm.conf /etc/vm.conf.orig > # vmd -d > startup > failed to open /etc/vm.conf: No such file or directory > > (Silently) ignoring missing config seems fine when no explicit one is > configured, whereas `-f /nonexistent' should always fail. > > Are there other daemons which such graceful default behaviour? > FWIW, bgpd properly fails hard on missing config, so does pfctl; I've > checked those as they share most of the config file parser. Most of these daemons do require a config file though, so in those cases a hard failure is expected.
Re: unwind: log missing config file
On Tue, Nov 19, 2019 at 12:15:34AM +0100, Klemens Nanni wrote: > On Mon, Nov 18, 2019 at 10:19:47PM +0100, Klemens Nanni wrote: > > With that, my initial case is no longer misleading; alternatively, I > > can implement the dash semantic, but that's another diff. > Hm, that makes the default setup (no /etc/unwind.conf, empty > unwind_flags) always print a warning, which is ugly. I looked for other daemons and vmd(8) behaves just like that: # vmd -dnf/nonexistent ; echo $? failed to open /nonexistent: No such file or directory configuration OK 0 # mv /etc/vm.conf /etc/vm.conf.orig # vmd -d startup failed to open /etc/vm.conf: No such file or directory (Silently) ignoring missing config seems fine when no explicit one is configured, whereas `-f /nonexistent' should always fail. Are there other daemons which such graceful default behaviour? FWIW, bgpd properly fails hard on missing config, so does pfctl; I've checked those as they share most of the config file parser.
Re: sysupgrade: Allow to use another directory for the sets
Craig Skinner wrote: > On Thu, 7 Nov 2019 14:42:32 + Stuart Henderson wrote: > > On 2019/11/07 11:15, Craig Skinner wrote: > > > On Wed, 6 Nov 2019 13:41:07 +0100 Renaud Allard wrote: > > > > Given the amount of people which encrypt /home directory on their > > > > servers, it might be useful to be able to define another directory for > > > > the sets in sysupgrade as /home_sysupgrade will not be available in > > > > that > > > > case. > > > > > > How about /var/cache/sysupgrade/ as the default? > > > > > > i.e: sysupgrade caches files which are variable over time. > > > > > > > > > > The merits of different filesystems were already discussed when choosing the > > current default - disklabel auto layout usually leaves a fair amount of > > space > > in /home, reduces risk of running out of space in a fairly import system fs, > > and avoids consuming space on an fs where files are unpacked during the > > upgrade install. > > > > If the installer created a 750Mb /var/cache/ partition, and sysupgrade's cache > directory is hard coded as /var/cache/sysupgrade/, would that simply solve > the various problems people are having & scripting difficulties? > > Other tools which cache files in /home/ or /var/db/ could also use /var/cache/ crazy. not going to happen.
Re: sysupgrade: Allow to use another directory for the sets
On Tue, Nov 19, 2019 at 09:00:33AM +, Stuart Henderson wrote: > On 2019/11/18 14:45, Raimo Niskanen wrote: > > On Mon, Nov 18, 2019 at 01:23:27PM +0100, Renaud Allard wrote: > > > > > > > > > On 11/18/19 10:08 AM, Raimo Niskanen wrote: > > > > > > > A configuration parameter could be accomplished through an optional > > > > symlink > > > > /etc/_sysupgrade that the sysadmin can create to point at the > > > > installation's > > > > sysupgrade directory. The sysupgrade script would test -s > > > > /etc/_sysupgrade > > > > and if there is a symlink readlink -f /etc/_sysupgrade to get SETSDIR. > > > > > > > > > > As it was said earlier, this doesn't solve the removal issue. With your > > > patch, please try "ln -s /home/_sysupgrade / ; sysupgrade". > > > > > > > This is actually not yet in my patch. I just want to, as a first step > > towards either of our solutions, patch to have the /home/_sysupgrade literal > > in only one place in the sysupgrade script, which would facilitate patching > > the sysupgrade script before calling it, as a poor man's solution. > > Plus, the script gets cleaner. > > > > The symlink suggestion is a future patch. > > > > But I think your suggestion to instead specify the parent directory of the > > _syspatch directory should be sufficient to remedy the removal issue both > > for your command line suggestion, as for this future patch symlink > > suggestion. > > > > It is a pity nobody else has responded to that prefix suggestion of yours! > > It does avoid the removal issue but it seems an awkward user interface to > pass the parent directory. Perhaps better to enforce that the path matches Yes. > */_sysupgrade, though this also doesn't feel quite right. Perhaps add > /_sysupgrade if it wasn't already present... Or, since readlink -f normalizes the path one could simply check that the result is not / which should fix the important case. > > > I think the feature itself is more important than if it is implemented > > with a command line argument or a symlink. > > > > Other than that. What do you or anyone else think about my argument that > > the location of the system upgrade download directory is an installation > > configuration that will not change between upgrades and hence it would be > > nice to not have to remember the command line argument for every future > > sysupgrade. > > Generally agree, but I'm not keen on a proliferation of tiny pseudo-config > files, and this feels maybe part of something bigger. A similar argument > could be made for the choice of release/stable vs snaps (-s / -r here, > -Dsnap in pkg_add) which could be in some kind of "system config" alongside > source URLs (base, packages, firmware), a list of sets, maybe some pkg_add > related things (whether to install debug packages?), ... Agreed. /etc/installurl is now a tiny one item config file but was once a different file containing more items. Perhaps something to go back to? -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: sysupgrade: Allow to use another directory for the sets
On 11/19/19 11:11 AM, Craig Skinner wrote: If the installer created a 750Mb /var/cache/ partition, and sysupgrade's cache directory is hard coded as /var/cache/sysupgrade/, would that simply solve the various problems people are having & scripting difficulties? Other tools which cache files in /home/ or /var/db/ could also use /var/cache/ If other tools store data in /var/cache, how are you sure 750Mb will be enough for everyone? /home is probably the safest _default_, but there are clearly reasons for an override in some cases.
Re: sysupgrade: Allow to use another directory for the sets
On 2019/11/19 10:11, Craig Skinner wrote: > On Thu, 7 Nov 2019 14:42:32 + Stuart Henderson wrote: > > On 2019/11/07 11:15, Craig Skinner wrote: > > > On Wed, 6 Nov 2019 13:41:07 +0100 Renaud Allard wrote: > > > > Given the amount of people which encrypt /home directory on their > > > > servers, it might be useful to be able to define another directory for > > > > the sets in sysupgrade as /home_sysupgrade will not be available in > > > > that > > > > case. > > > > > > How about /var/cache/sysupgrade/ as the default? > > > > > > i.e: sysupgrade caches files which are variable over time. > > > > > > > > > > The merits of different filesystems were already discussed when choosing the > > current default - disklabel auto layout usually leaves a fair amount of > > space > > in /home, reduces risk of running out of space in a fairly import system fs, > > and avoids consuming space on an fs where files are unpacked during the > > upgrade install. > > > > If the installer created a 750Mb /var/cache/ partition, and sysupgrade's cache > directory is hard coded as /var/cache/sysupgrade/, would that simply solve > the various problems people are having & scripting difficulties? > > Other tools which cache files in /home/ or /var/db/ could also use /var/cache/ > > > Cheers, > -- > Craig Skinner | http://linkd.in/yGqkv7 > We are short on partitions, there is a hard limit (14+swap), disklabel auto defaults already use 9, and there need to be some free for typical user use (ports, dest for "make release", people often want a separate /var/www and/or /var/log).
Re: sysupgrade: Allow to use another directory for the sets
On 11/19/19 10:00 AM, Stuart Henderson wrote: It does avoid the removal issue but it seems an awkward user interface to pass the parent directory. Perhaps better to enforce that the path matches */_sysupgrade, though this also doesn't feel quite right. Perhaps add /_sysupgrade if it wasn't already present... That's what I proposed in my latest patch, including the forcing of non removal if -d is used. Did you check my latest patch? smime.p7s Description: S/MIME Cryptographic Signature
Re: sysupgrade: Allow to use another directory for the sets
On Thu, 7 Nov 2019 14:42:32 + Stuart Henderson wrote: > On 2019/11/07 11:15, Craig Skinner wrote: > > On Wed, 6 Nov 2019 13:41:07 +0100 Renaud Allard wrote: > > > Given the amount of people which encrypt /home directory on their > > > servers, it might be useful to be able to define another directory for > > > the sets in sysupgrade as /home_sysupgrade will not be available in that > > > case. > > > > How about /var/cache/sysupgrade/ as the default? > > > > i.e: sysupgrade caches files which are variable over time. > > > > > > The merits of different filesystems were already discussed when choosing the > current default - disklabel auto layout usually leaves a fair amount of space > in /home, reduces risk of running out of space in a fairly import system fs, > and avoids consuming space on an fs where files are unpacked during the > upgrade install. > If the installer created a 750Mb /var/cache/ partition, and sysupgrade's cache directory is hard coded as /var/cache/sysupgrade/, would that simply solve the various problems people are having & scripting difficulties? Other tools which cache files in /home/ or /var/db/ could also use /var/cache/ Cheers, -- Craig Skinner | http://linkd.in/yGqkv7
Re: sdhc(4): no 0V one some Intel
On Tue, Nov 19, 2019 at 10:44:54AM +0100, Patrick Wildt wrote: > Hi, > > on some GPD Pocket mlarkin@ has the eMMC doesn't come up. One issue > is that we shouldn't go to 0V on some/most(?) Intel controllers. This > only adds it for his machine, but I know that the Appollo Lake versions > might also work if added to this check. But unless verified I'll not > add it. This makes mlarkin@'s machine work, even though it's utterly > slow. That would be the next thing to fix... probably low clocks or > doesn't use 8-bit. > > ok? > Sure. And you get the handoff to fix the rest :) -ml > Patrick > > diff --git a/sys/dev/pci/sdhc_pci.c b/sys/dev/pci/sdhc_pci.c > index d1b6688f573..dd6bc79c29c 100644 > --- a/sys/dev/pci/sdhc_pci.c > +++ b/sys/dev/pci/sdhc_pci.c > @@ -127,6 +127,11 @@ sdhc_pci_attach(struct device *parent, struct device > *self, void *aux) > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ENE_SDCARD) > sc->sc.sc_flags |= SDHC_F_NOPWR0; > > + /* Some Intel controllers break if set to 0V bus power. */ > + if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_INTEL && > + PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_INTEL_100SERIES_LP_EMMC) > + sc->sc.sc_flags |= SDHC_F_NOPWR0; > + > /* Some RICOH controllers need to be bumped into the right mode. */ > if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_RICOH && > (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_RICOH_R5U822 || >
sdhc(4): no 0V one some Intel
Hi, on some GPD Pocket mlarkin@ has the eMMC doesn't come up. One issue is that we shouldn't go to 0V on some/most(?) Intel controllers. This only adds it for his machine, but I know that the Appollo Lake versions might also work if added to this check. But unless verified I'll not add it. This makes mlarkin@'s machine work, even though it's utterly slow. That would be the next thing to fix... probably low clocks or doesn't use 8-bit. ok? Patrick diff --git a/sys/dev/pci/sdhc_pci.c b/sys/dev/pci/sdhc_pci.c index d1b6688f573..dd6bc79c29c 100644 --- a/sys/dev/pci/sdhc_pci.c +++ b/sys/dev/pci/sdhc_pci.c @@ -127,6 +127,11 @@ sdhc_pci_attach(struct device *parent, struct device *self, void *aux) PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ENE_SDCARD) sc->sc.sc_flags |= SDHC_F_NOPWR0; + /* Some Intel controllers break if set to 0V bus power. */ + if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_INTEL && + PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_INTEL_100SERIES_LP_EMMC) + sc->sc.sc_flags |= SDHC_F_NOPWR0; + /* Some RICOH controllers need to be bumped into the right mode. */ if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_RICOH && (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_RICOH_R5U822 ||
Re: unwind: log missing config file
On Tue, Nov 19, 2019 at 03:53:16AM +0100, Florian Obser wrote: > On Tue, Nov 19, 2019 at 12:15:34AM +0100, Klemens Nanni wrote: > > On Mon, Nov 18, 2019 at 10:19:47PM +0100, Klemens Nanni wrote: > > > With that, my initial case is no longer misleading; alternatively, I > > > can implement the dash semantic, but that's another diff. > > Hm, that makes the default setup (no /etc/unwind.conf, empty > > unwind_flags) always print a warning, which is ugly. > > It's not just ugly, it's missleading. We want unwind to be the best it > can be *without* a config file. We don't to suggest a config file. We > want to steer people away from pushing buttons, not towards. > > Btw. I'm not sure the parser can work with stdin, I think it needs to > seek, which you can't do on stdin? But I might be mistaken on multiple > levels. yacc uses a one-token lookahead parser, it needs to look at the one extra token max to decide what to do next. It keeps track of the last token seen itself. As for the lexers we use, they use one character lookahead, with an occasional ungetc. stdio is guaranteed to handle that without issues for any stream source. As for parsers or lexers needing seek, the thought alone! ;-) -Otto
Re: sysupgrade: Allow to use another directory for the sets
On 2019/11/18 14:45, Raimo Niskanen wrote: > On Mon, Nov 18, 2019 at 01:23:27PM +0100, Renaud Allard wrote: > > > > > > On 11/18/19 10:08 AM, Raimo Niskanen wrote: > > > > > A configuration parameter could be accomplished through an optional > > > symlink > > > /etc/_sysupgrade that the sysadmin can create to point at the > > > installation's > > > sysupgrade directory. The sysupgrade script would test -s > > > /etc/_sysupgrade > > > and if there is a symlink readlink -f /etc/_sysupgrade to get SETSDIR. > > > > > > > As it was said earlier, this doesn't solve the removal issue. With your > > patch, please try "ln -s /home/_sysupgrade / ; sysupgrade". > > > > This is actually not yet in my patch. I just want to, as a first step > towards either of our solutions, patch to have the /home/_sysupgrade literal > in only one place in the sysupgrade script, which would facilitate patching > the sysupgrade script before calling it, as a poor man's solution. > Plus, the script gets cleaner. > > The symlink suggestion is a future patch. > > But I think your suggestion to instead specify the parent directory of the > _syspatch directory should be sufficient to remedy the removal issue both > for your command line suggestion, as for this future patch symlink > suggestion. > > It is a pity nobody else has responded to that prefix suggestion of yours! It does avoid the removal issue but it seems an awkward user interface to pass the parent directory. Perhaps better to enforce that the path matches */_sysupgrade, though this also doesn't feel quite right. Perhaps add /_sysupgrade if it wasn't already present... > I think the feature itself is more important than if it is implemented > with a command line argument or a symlink. > > Other than that. What do you or anyone else think about my argument that > the location of the system upgrade download directory is an installation > configuration that will not change between upgrades and hence it would be > nice to not have to remember the command line argument for every future > sysupgrade. Generally agree, but I'm not keen on a proliferation of tiny pseudo-config files, and this feels maybe part of something bigger. A similar argument could be made for the choice of release/stable vs snaps (-s / -r here, -Dsnap in pkg_add) which could be in some kind of "system config" alongside source URLs (base, packages, firmware), a list of sets, maybe some pkg_add related things (whether to install debug packages?), ...
