Re: svn commit: r345680 - head/sys/conf

2019-09-03 Thread Kyle Evans
On Fri, Mar 29, 2019 at 12:34 AM Rodney W. Grimes
 wrote:
>
> > -Original Message-
> > From:  on behalf of Kyle Evans 
> > 
> > Date: 2019-03-28, Thursday at 21:00
> > To: , , 
> > 
> > Subject: svn commit: r345680 - head/sys/conf
> >
> > > Author: kevans
> > > Date: Fri Mar 29 04:00:46 2019
> > > New Revision: 345680
> > > URL: https://svnweb.freebsd.org/changeset/base/345680
> > >
> > > Log:
> > >   NOTES: Use non-default value for BOOT_TAG
> >
> > Why?
> >
> > (I was on IRC when jhb debugged this, but I didn't quite get it; and of 
> > course lots of us *weren't* on IRC at the time.)
>
> Yes, please, why is this beeing changed, do I need to revise my .sh that
> was hunting for the old string to use what now?  Or do I need to now
> override this in my KERNCONF files?
>
> I think changing this in stable/12 is a POLA issue.
>
> > Thanks,
> >
> > Ravi (rpokala@)
> >
> > >   Reported by:  jhb
> > >   MFC after:1 week (except non-empty value in stable/11)
>
> Why is 11 being treated special, or is it that it does not implement
> BOOT_TAG at all?
>
> Does this deserve a RELNOTES Y, or UPDATING entry?
>

The short answer to all of this is "No, no, no" -- see Bruce's
response about the purpose of NOTES, and the NOTES header itself. It's
the kitchen sink, and you can't/won't/don't include the kitchen sink
when you need a pipelet.

11 is special because BOOT_TAG was implemented after stable/11
branched. I MFC'd it because I used it on stable/11, but the MFC had
to result in a no-op to the msgbuf to not violate POLA.


___
svn-src-all@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"


Re: svn commit: r345680 - head/sys/conf

2019-09-03 Thread Bruce Evans

On Thu, 28 Mar 2019, Ravi Pokala wrote:


-Original Message-
From:  on behalf of Kyle Evans 

Date: 2019-03-28, Thursday at 21:00
To: , , 

Subject: svn commit: r345680 - head/sys/conf


Author: kevans
Date: Fri Mar 29 04:00:46 2019
New Revision: 345680
URL: https://svnweb.freebsd.org/changeset/base/345680

Log:
  NOTES: Use non-default value for BOOT_TAG


Why?

(I was on IRC when jhb debugged this, but I didn't quite get it; and of course 
lots of us *weren't* on IRC at the time.)


Because NOTES is primarily for generating LINT, and LINT's reason for
existence is to test as many cases as possible.  Testing the default cases
again is not very useful, so by convention NOTES never configures defaults,
except of course where it is broken.  This commit is to fix 1 broken place.

Not repeating the default is also good for NOTES' secondary purpose of
documentation.  Defaults are easy to find by grepping the source code for
them if there is no documentation.  Changing defaults to valid and useful
values requires understanding more of the source if there is no documentation.


Modified: head/sys/conf/NOTES
==
--- head/sys/conf/NOTES Fri Mar 29 03:25:20 2019(r345679)
+++ head/sys/conf/NOTES Fri Mar 29 04:00:46 2019(r345680)
@@ -150,7 +150,7 @@ options BOOTHOWTO=RB_MULTIPLE
 #
 # Default boot tag; may use 'kern.boot_tag' loader tunable to override.  The
 # current boot's tag is also exposed via the 'kern.boot_tag' sysctl.
-optionsBOOT_TAG=\"---<>---\"
+optionsBOOT_TAG=\"\"


Useful variations are not always easy to invent.  I usually just add 1 for
numeric values.  This example is useful.  It kills the boot tag.  It gives
an empty tag, and the kernel does extra work to avoid printing a newline
after an empty tag.


 # Maximum boot tag size the kernel's static buffer should accomodate.  Maximum
 # size for both BOOT_TAG and the assocated tunable.
 optionsBOOT_TAG_SZ=32


This bug remains unfixed.  32 is the default.  This option shouldn't exist.
Instead, just use size strlen(BOOT_TAG) + 1 for the static string and keep
the dynamic string in the environment.  The string is only used once, and
msgbufinit() already has to check both the static string and the environment
to find the right string (it does this by fetching the dynamic string to
overwrite the static string, but it is easier to not use a tunable or
support a sysctl and just keep the dynamic string in the environment).

Bruce


___
svn-src-all@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"


Re: svn commit: r345680 - head/sys/conf

2019-09-03 Thread Rodney W. Grimes
> -Original Message-
> From:  on behalf of Kyle Evans 
> 
> Date: 2019-03-28, Thursday at 21:00
> To: , , 
> 
> Subject: svn commit: r345680 - head/sys/conf
> 
> > Author: kevans
> > Date: Fri Mar 29 04:00:46 2019
> > New Revision: 345680
> > URL: https://svnweb.freebsd.org/changeset/base/345680
> > 
> > Log:
> >   NOTES: Use non-default value for BOOT_TAG
> 
> Why?
> 
> (I was on IRC when jhb debugged this, but I didn't quite get it; and of 
> course lots of us *weren't* on IRC at the time.)

Yes, please, why is this beeing changed, do I need to revise my .sh that
was hunting for the old string to use what now?  Or do I need to now
override this in my KERNCONF files?

I think changing this in stable/12 is a POLA issue.

> Thanks,
> 
> Ravi (rpokala@)
> 
> >   Reported by:  jhb
> >   MFC after:1 week (except non-empty value in stable/11)

Why is 11 being treated special, or is it that it does not implement
BOOT_TAG at all?

Does this deserve a RELNOTES Y, or UPDATING entry?

> > Modified:
> >   head/sys/conf/NOTES
> > 
> > Modified: head/sys/conf/NOTES
> > ==
> > --- head/sys/conf/NOTES Fri Mar 29 03:25:20 2019(r345679)
> > +++ head/sys/conf/NOTES Fri Mar 29 04:00:46 2019(r345680)
> > @@ -150,7 +150,7 @@ options BOOTHOWTO=RB_MULTIPLE
> >  #
> >  # Default boot tag; may use 'kern.boot_tag' loader tunable to override.  
> > The
> >  # current boot's tag is also exposed via the 'kern.boot_tag' sysctl.
> > -optionsBOOT_TAG=\"---<>---\"
> > +optionsBOOT_TAG=\"\"
> >  # Maximum boot tag size the kernel's static buffer should accomodate.  
> > Maximum
> >  # size for both BOOT_TAG and the assocated tunable.
> >  optionsBOOT_TAG_SZ=32
> 
> 
> 
> 
> 

-- 
Rod Grimes rgri...@freebsd.org


___
svn-src-all@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"


Re: svn commit: r345680 - head/sys/conf

2019-09-03 Thread Bruce Evans

On Fri, 29 Mar 2019, Alexey Dokuchaev wrote:


On Fri, Mar 29, 2019 at 05:40:05PM +1100, Bruce Evans wrote:

...
-optionsBOOT_TAG=\"---<>---\"
+optionsBOOT_TAG=\"\"


Useful variations are not always easy to invent.  I usually just add 1 for
numeric values.  This example is useful.  It kills the boot tag.  It gives
an empty tag, and the kernel does extra work to avoid printing a newline
after an empty tag.


That's a nice idea, thanks Bruce.  I always had to revert commits that had
added this stupid boot tag; if empty tag does not imply a newline, then it
makes things much easier.

./danfe

P.S.  Boot tag of a healthy human is "Copyright (c) 1992-2018 The FreeBSD
Project".


Actually, there are ordering problems.  After fixing lost messages, I get
for the simplest case of a non-verbose cold boot:

XX Mar 29 19:14:08 gamplex syslogd: kernel boot file is /kernel

This boot file message is the first one.  I often grep for it, so as to
ignore messages for previous boots.

XX Mar 29 19:14:08 gamplex kernel: ---<>---

This is almost first.

XX Mar 29 19:14:08 gamplex kernel: Test of early printf to msgbuf
XX Mar 29 19:14:08 gamplex kernel: Test of early printf to console

Tests for my fixes.  msgbufinit() is called early and uses a statically
allocated buffer until the dynamic message buffer is mapped.  Early messages
are thus not lost for the message buffer.  They may be lost for the
console.

XX Mar 29 19:14:08 gamplex kernel: GDB: debug ports: sio
XX Mar 29 19:14:08 gamplex kernel: GDB: current port: sio
XX Mar 29 19:14:08 gamplex kernel: KDB: debugger backends: ddb gdb
XX Mar 29 19:14:08 gamplex kernel: KDB: current backend: ddb

Standard early messages if DDB is configured.

XX Mar 29 19:14:08 gamplex kernel: WARNING: loader(8) metadata is missing!

I don't use loader on i386, and am reminded that I don't like it by this
warning.

XX Mar 29 19:14:08 gamplex kernel: Copyright (c) 1992-2019 The FreeBSD Project.

Finally the copyright message.  The source code still obfuscates the order
of this using SYSINIT(), and on x86 and powerpc still has a bogus "Good
{morning,afternoon,evening, night}" comment that isn't even attached to its
code (the printf() of the message).  The comment is in cpu_startup()
which runs at SI_SUB_CPU, SI_ORDER_FIRST.  This is much later than printing
the copyright, which runs at SI_SUB_COPYRIGHT.  In between, there are SUBs
for VM, KMEM, HYPERISOR, WITNESS, MTX_POOL_DYNAMIC, LOCK, EVENTHANDLER,
VNET_PRELINK and KLD.  Before COPYRIGHT, there are only DUMMY, DONE and
TUNABLES under sysinit, but lots more in early initialization including
early console use for the above messages and ddb.  The comment on
SI_SUB_COPYRIGHT wrongly says that it is for the first use of the console.

Booting with -v gives many more early messages that are usually lost.  E.g.,
ones about SMAP on x86.

Warm boots sometimes give a dynamic message buffer that is actually useful.
To be useful, it must be retained at boot.  Otherwise, it is easier to
put the message buffer in the bss.

The dynamic message buffer only works for me on amd64 and i386 with pae_mode=1
(and probably also more than 4GB RAM).  Otherwise, it is below 4GB and the
BIOS scribbles on it (fairly sparsely, but it doesn't have enough error
correcting to recover).  Recovering it fixes loss of the last few messages
for the previous boot, but risks doubling of non-lost messages.  The BOOT
tags are useful for seeing where the new messages start.

Everything usually works as well as possible:

XX Mar 25 02:59:49 iotaplex syslogd: exiting on signal 15

The use of an amd64 kernel a few days ago was terminated by turning the
system off.  Messages printed after killing syslogd were lost.

XX Mar 29 21:33:49 iotaplex syslogd: kernel boot file is /boot/kernel/kernel
XX Mar 29 21:33:49 iotaplex kernel: ---<>---
XX Mar 29 21:33:49 iotaplex kernel: Test of early printf to msgbuf
XX Mar 29 21:33:49 iotaplex kernel: GDB: debug ports: sio
XX Mar 29 21:33:49 iotaplex kernel: GDB: current port: sio
XX Mar 29 21:33:49 iotaplex kernel: KDB: debugger backends: ddb gdb
XX Mar 29 21:33:49 iotaplex kernel: KDB: current backend: ddb
XX Mar 29 21:33:49 iotaplex kernel: Copyright (c) 1992-2019 The FreeBSD Project.

Cold boot of the same kernel today (actually, i386 was running before this,
but the boot was cold enough for the message buffer).

XX ...
XX Mar 29 21:34:32 iotaplex syslogd: exiting on signal 15

As usual, messages printed after killing syslogd are not logged properly...

XX Mar 29 21:35:55 iotaplex syslogd: kernel boot file is /boot/kernel/kernel

Warm boot of the same amd64 kernel.

XX Mar 29 21:35:55 iotaplex kernel: Waiting (max 60 seconds) for system process 
`vnlru' to stop... done
XX Mar 29 21:35:55 iotaplex kernel: Waiting (max 60 seconds) for system process `syncer' to stop... 
XX Mar 29 21:35:55 iotaplex kernel: Syncing disks, vnodes remaining... 0 0 0 done

XX Mar 29 21:35:55 iotaplex kernel: Waiting (max 60 seconds) for system thread 

Re: svn commit: r345680 - head/sys/conf

2019-09-03 Thread Kyle Evans
On Fri, Mar 29, 2019 at 1:40 AM Bruce Evans  wrote:
>
> On Thu, 28 Mar 2019, Ravi Pokala wrote:
>
> > -Original Message-
> > From:  on behalf of Kyle Evans 
> > 
> > Date: 2019-03-28, Thursday at 21:00
> > To: , , 
> > 
> > Subject: svn commit: r345680 - head/sys/conf
> >> [... snip ...]
> >>  # Maximum boot tag size the kernel's static buffer should accomodate.  
> >> Maximum
> >>  # size for both BOOT_TAG and the assocated tunable.
> >>  options BOOT_TAG_SZ=32
>
> This bug remains unfixed.  32 is the default.  This option shouldn't exist.
> Instead, just use size strlen(BOOT_TAG) + 1 for the static string and keep
> the dynamic string in the environment.  The string is only used once, and
> msgbufinit() already has to check both the static string and the environment
> to find the right string (it does this by fetching the dynamic string to
> overwrite the static string, but it is easier to not use a tunable or
> support a sysctl and just keep the dynamic string in the environment).
>

I will consider doing just that. Where I was going with this turned
out to be logistically annoying because of kenv's val length
limitation. I had some one-off test setups where I wanted to dump some
cherry-picked information about the build into the BOOT_TAG via the
tunable for reference when looking back and comparing msgbufs between
boots. However, we can't reasonably support values the length I need
in the environment (with a caveat, see [0]), so I would need to break
them up -- likely by hand, which means I'm more inclined to just hunt
down the current BOOT_TAG and modify these msgbufs post-mortem to
include the information I want to see. This process is still less
convenient than it would've been to be able to set it in loader.conf,
because for many of these I already have to edit loader.conf for other
reasons.

Enlarging the BOOT_TAG_SZ in the 'breaking up' scenario is convenient
because I'd rather not stitch the boot tag back together from the
environment when observed via sysctl -- I want to do this once, and
observe it exactly as it is after it's printed, so pushing it into the
boot tag buffer that already holds the statically configured boot tag
is convenient there. There are other reasons it'd be convenient to
push them into the same buffer, but they're rather moot now since I'm
likely the only one that wanted to use larger boot tags like that and
I'm just not going to go that far to support my use case.

[0] Merging into the dynamic environment is kind of broken here, and I
didn't really fix it when I touched that. We only verify that the
whole assignment line isn't more than MNAMELEN + MVALLEN + 2, rather
than the individual components, so I could take advantage of this and
have way-too-long values... that's not much more helpful, though.


___
svn-src-all@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"


Re: svn commit: r345680 - head/sys/conf

2019-09-03 Thread Mark Linimon
On Fri, Mar 29, 2019 at 09:49:03AM +, Alexey Dokuchaev wrote:
> P.S.  Boot tag of a healthy human is "Copyright (c) 1992-2018 The FreeBSD
> Project".

ITYM 2019.

mcl


___
svn-src-all@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"


Re: svn commit: r345680 - head/sys/conf

2019-09-03 Thread Ravi Pokala
-Original Message-
From:  on behalf of Kyle Evans 

Date: 2019-03-28, Thursday at 21:00
To: , , 

Subject: svn commit: r345680 - head/sys/conf

> Author: kevans
> Date: Fri Mar 29 04:00:46 2019
> New Revision: 345680
> URL: https://svnweb.freebsd.org/changeset/base/345680
> 
> Log:
>   NOTES: Use non-default value for BOOT_TAG

Why?

(I was on IRC when jhb debugged this, but I didn't quite get it; and of course 
lots of us *weren't* on IRC at the time.)

Thanks,

Ravi (rpokala@)

>   Reported by:jhb
>   MFC after:  1 week (except non-empty value in stable/11)
> 
> Modified:
>   head/sys/conf/NOTES
> 
> Modified: head/sys/conf/NOTES
> ==
> --- head/sys/conf/NOTES   Fri Mar 29 03:25:20 2019(r345679)
> +++ head/sys/conf/NOTES   Fri Mar 29 04:00:46 2019(r345680)
> @@ -150,7 +150,7 @@ options   BOOTHOWTO=RB_MULTIPLE
>  #
>  # Default boot tag; may use 'kern.boot_tag' loader tunable to override.  The
>  # current boot's tag is also exposed via the 'kern.boot_tag' sysctl.
> -options  BOOT_TAG=\"---<>---\"
> +options  BOOT_TAG=\"\"
>  # Maximum boot tag size the kernel's static buffer should accomodate.  
> Maximum
>  # size for both BOOT_TAG and the assocated tunable.
>  options  BOOT_TAG_SZ=32





___
svn-src-all@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"


Re: svn commit: r345680 - head/sys/conf

2019-09-03 Thread Alexey Dokuchaev
On Fri, Mar 29, 2019 at 05:40:05PM +1100, Bruce Evans wrote:
> >> ...
> >> -options   BOOT_TAG=\"---<>---\"
> >> +options   BOOT_TAG=\"\"
> 
> Useful variations are not always easy to invent.  I usually just add 1 for
> numeric values.  This example is useful.  It kills the boot tag.  It gives
> an empty tag, and the kernel does extra work to avoid printing a newline
> after an empty tag.

That's a nice idea, thanks Bruce.  I always had to revert commits that had
added this stupid boot tag; if empty tag does not imply a newline, then it
makes things much easier.

./danfe

P.S.  Boot tag of a healthy human is "Copyright (c) 1992-2018 The FreeBSD
Project".


___
svn-src-all@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"


Re: svn commit: r345680 - head/sys/conf

2019-03-29 Thread Kyle Evans
On Fri, Mar 29, 2019 at 12:34 AM Rodney W. Grimes
 wrote:
>
> > -Original Message-
> > From:  on behalf of Kyle Evans 
> > 
> > Date: 2019-03-28, Thursday at 21:00
> > To: , , 
> > 
> > Subject: svn commit: r345680 - head/sys/conf
> >
> > > Author: kevans
> > > Date: Fri Mar 29 04:00:46 2019
> > > New Revision: 345680
> > > URL: https://svnweb.freebsd.org/changeset/base/345680
> > >
> > > Log:
> > >   NOTES: Use non-default value for BOOT_TAG
> >
> > Why?
> >
> > (I was on IRC when jhb debugged this, but I didn't quite get it; and of 
> > course lots of us *weren't* on IRC at the time.)
>
> Yes, please, why is this beeing changed, do I need to revise my .sh that
> was hunting for the old string to use what now?  Or do I need to now
> override this in my KERNCONF files?
>
> I think changing this in stable/12 is a POLA issue.
>
> > Thanks,
> >
> > Ravi (rpokala@)
> >
> > >   Reported by:  jhb
> > >   MFC after:1 week (except non-empty value in stable/11)
>
> Why is 11 being treated special, or is it that it does not implement
> BOOT_TAG at all?
>
> Does this deserve a RELNOTES Y, or UPDATING entry?
>

The short answer to all of this is "No, no, no" -- see Bruce's
response about the purpose of NOTES, and the NOTES header itself. It's
the kitchen sink, and you can't/won't/don't include the kitchen sink
when you need a pipelet.

11 is special because BOOT_TAG was implemented after stable/11
branched. I MFC'd it because I used it on stable/11, but the MFC had
to result in a no-op to the msgbuf to not violate POLA.
___
svn-src-all@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"


Re: svn commit: r345680 - head/sys/conf

2019-03-29 Thread Mark Linimon
On Fri, Mar 29, 2019 at 09:49:03AM +, Alexey Dokuchaev wrote:
> P.S.  Boot tag of a healthy human is "Copyright (c) 1992-2018 The FreeBSD
> Project".

ITYM 2019.

mcl
___
svn-src-all@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"


Re: svn commit: r345680 - head/sys/conf

2019-03-29 Thread Kyle Evans
On Fri, Mar 29, 2019 at 1:40 AM Bruce Evans  wrote:
>
> On Thu, 28 Mar 2019, Ravi Pokala wrote:
>
> > -Original Message-
> > From:  on behalf of Kyle Evans 
> > 
> > Date: 2019-03-28, Thursday at 21:00
> > To: , , 
> > 
> > Subject: svn commit: r345680 - head/sys/conf
> >> [... snip ...]
> >>  # Maximum boot tag size the kernel's static buffer should accomodate.  
> >> Maximum
> >>  # size for both BOOT_TAG and the assocated tunable.
> >>  options BOOT_TAG_SZ=32
>
> This bug remains unfixed.  32 is the default.  This option shouldn't exist.
> Instead, just use size strlen(BOOT_TAG) + 1 for the static string and keep
> the dynamic string in the environment.  The string is only used once, and
> msgbufinit() already has to check both the static string and the environment
> to find the right string (it does this by fetching the dynamic string to
> overwrite the static string, but it is easier to not use a tunable or
> support a sysctl and just keep the dynamic string in the environment).
>

I will consider doing just that. Where I was going with this turned
out to be logistically annoying because of kenv's val length
limitation. I had some one-off test setups where I wanted to dump some
cherry-picked information about the build into the BOOT_TAG via the
tunable for reference when looking back and comparing msgbufs between
boots. However, we can't reasonably support values the length I need
in the environment (with a caveat, see [0]), so I would need to break
them up -- likely by hand, which means I'm more inclined to just hunt
down the current BOOT_TAG and modify these msgbufs post-mortem to
include the information I want to see. This process is still less
convenient than it would've been to be able to set it in loader.conf,
because for many of these I already have to edit loader.conf for other
reasons.

Enlarging the BOOT_TAG_SZ in the 'breaking up' scenario is convenient
because I'd rather not stitch the boot tag back together from the
environment when observed via sysctl -- I want to do this once, and
observe it exactly as it is after it's printed, so pushing it into the
boot tag buffer that already holds the statically configured boot tag
is convenient there. There are other reasons it'd be convenient to
push them into the same buffer, but they're rather moot now since I'm
likely the only one that wanted to use larger boot tags like that and
I'm just not going to go that far to support my use case.

[0] Merging into the dynamic environment is kind of broken here, and I
didn't really fix it when I touched that. We only verify that the
whole assignment line isn't more than MNAMELEN + MVALLEN + 2, rather
than the individual components, so I could take advantage of this and
have way-too-long values... that's not much more helpful, though.
___
svn-src-all@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"


Re: svn commit: r345680 - head/sys/conf

2019-03-29 Thread Bruce Evans

On Fri, 29 Mar 2019, Alexey Dokuchaev wrote:


On Fri, Mar 29, 2019 at 05:40:05PM +1100, Bruce Evans wrote:

...
-optionsBOOT_TAG=\"---<>---\"
+optionsBOOT_TAG=\"\"


Useful variations are not always easy to invent.  I usually just add 1 for
numeric values.  This example is useful.  It kills the boot tag.  It gives
an empty tag, and the kernel does extra work to avoid printing a newline
after an empty tag.


That's a nice idea, thanks Bruce.  I always had to revert commits that had
added this stupid boot tag; if empty tag does not imply a newline, then it
makes things much easier.

./danfe

P.S.  Boot tag of a healthy human is "Copyright (c) 1992-2018 The FreeBSD
Project".


Actually, there are ordering problems.  After fixing lost messages, I get
for the simplest case of a non-verbose cold boot:

XX Mar 29 19:14:08 gamplex syslogd: kernel boot file is /kernel

This boot file message is the first one.  I often grep for it, so as to
ignore messages for previous boots.

XX Mar 29 19:14:08 gamplex kernel: ---<>---

This is almost first.

XX Mar 29 19:14:08 gamplex kernel: Test of early printf to msgbuf
XX Mar 29 19:14:08 gamplex kernel: Test of early printf to console

Tests for my fixes.  msgbufinit() is called early and uses a statically
allocated buffer until the dynamic message buffer is mapped.  Early messages
are thus not lost for the message buffer.  They may be lost for the
console.

XX Mar 29 19:14:08 gamplex kernel: GDB: debug ports: sio
XX Mar 29 19:14:08 gamplex kernel: GDB: current port: sio
XX Mar 29 19:14:08 gamplex kernel: KDB: debugger backends: ddb gdb
XX Mar 29 19:14:08 gamplex kernel: KDB: current backend: ddb

Standard early messages if DDB is configured.

XX Mar 29 19:14:08 gamplex kernel: WARNING: loader(8) metadata is missing!

I don't use loader on i386, and am reminded that I don't like it by this
warning.

XX Mar 29 19:14:08 gamplex kernel: Copyright (c) 1992-2019 The FreeBSD Project.

Finally the copyright message.  The source code still obfuscates the order
of this using SYSINIT(), and on x86 and powerpc still has a bogus "Good
{morning,afternoon,evening, night}" comment that isn't even attached to its
code (the printf() of the message).  The comment is in cpu_startup()
which runs at SI_SUB_CPU, SI_ORDER_FIRST.  This is much later than printing
the copyright, which runs at SI_SUB_COPYRIGHT.  In between, there are SUBs
for VM, KMEM, HYPERISOR, WITNESS, MTX_POOL_DYNAMIC, LOCK, EVENTHANDLER,
VNET_PRELINK and KLD.  Before COPYRIGHT, there are only DUMMY, DONE and
TUNABLES under sysinit, but lots more in early initialization including
early console use for the above messages and ddb.  The comment on
SI_SUB_COPYRIGHT wrongly says that it is for the first use of the console.

Booting with -v gives many more early messages that are usually lost.  E.g.,
ones about SMAP on x86.

Warm boots sometimes give a dynamic message buffer that is actually useful.
To be useful, it must be retained at boot.  Otherwise, it is easier to
put the message buffer in the bss.

The dynamic message buffer only works for me on amd64 and i386 with pae_mode=1
(and probably also more than 4GB RAM).  Otherwise, it is below 4GB and the
BIOS scribbles on it (fairly sparsely, but it doesn't have enough error
correcting to recover).  Recovering it fixes loss of the last few messages
for the previous boot, but risks doubling of non-lost messages.  The BOOT
tags are useful for seeing where the new messages start.

Everything usually works as well as possible:

XX Mar 25 02:59:49 iotaplex syslogd: exiting on signal 15

The use of an amd64 kernel a few days ago was terminated by turning the
system off.  Messages printed after killing syslogd were lost.

XX Mar 29 21:33:49 iotaplex syslogd: kernel boot file is /boot/kernel/kernel
XX Mar 29 21:33:49 iotaplex kernel: ---<>---
XX Mar 29 21:33:49 iotaplex kernel: Test of early printf to msgbuf
XX Mar 29 21:33:49 iotaplex kernel: GDB: debug ports: sio
XX Mar 29 21:33:49 iotaplex kernel: GDB: current port: sio
XX Mar 29 21:33:49 iotaplex kernel: KDB: debugger backends: ddb gdb
XX Mar 29 21:33:49 iotaplex kernel: KDB: current backend: ddb
XX Mar 29 21:33:49 iotaplex kernel: Copyright (c) 1992-2019 The FreeBSD Project.

Cold boot of the same kernel today (actually, i386 was running before this,
but the boot was cold enough for the message buffer).

XX ...
XX Mar 29 21:34:32 iotaplex syslogd: exiting on signal 15

As usual, messages printed after killing syslogd are not logged properly...

XX Mar 29 21:35:55 iotaplex syslogd: kernel boot file is /boot/kernel/kernel

Warm boot of the same amd64 kernel.

XX Mar 29 21:35:55 iotaplex kernel: Waiting (max 60 seconds) for system process 
`vnlru' to stop... done
XX Mar 29 21:35:55 iotaplex kernel: Waiting (max 60 seconds) for system process `syncer' to stop... 
XX Mar 29 21:35:55 iotaplex kernel: Syncing disks, vnodes remaining... 0 0 0 done

XX Mar 29 21:35:55 iotaplex kernel: Waiting (max 60 seconds) for system thread 

Re: svn commit: r345680 - head/sys/conf

2019-03-29 Thread Alexey Dokuchaev
On Fri, Mar 29, 2019 at 05:40:05PM +1100, Bruce Evans wrote:
> >> ...
> >> -options   BOOT_TAG=\"---<>---\"
> >> +options   BOOT_TAG=\"\"
> 
> Useful variations are not always easy to invent.  I usually just add 1 for
> numeric values.  This example is useful.  It kills the boot tag.  It gives
> an empty tag, and the kernel does extra work to avoid printing a newline
> after an empty tag.

That's a nice idea, thanks Bruce.  I always had to revert commits that had
added this stupid boot tag; if empty tag does not imply a newline, then it
makes things much easier.

./danfe

P.S.  Boot tag of a healthy human is "Copyright (c) 1992-2018 The FreeBSD
Project".
___
svn-src-all@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"


Re: svn commit: r345680 - head/sys/conf

2019-03-29 Thread Bruce Evans

On Thu, 28 Mar 2019, Ravi Pokala wrote:


-Original Message-
From:  on behalf of Kyle Evans 

Date: 2019-03-28, Thursday at 21:00
To: , , 

Subject: svn commit: r345680 - head/sys/conf


Author: kevans
Date: Fri Mar 29 04:00:46 2019
New Revision: 345680
URL: https://svnweb.freebsd.org/changeset/base/345680

Log:
  NOTES: Use non-default value for BOOT_TAG


Why?

(I was on IRC when jhb debugged this, but I didn't quite get it; and of course 
lots of us *weren't* on IRC at the time.)


Because NOTES is primarily for generating LINT, and LINT's reason for
existence is to test as many cases as possible.  Testing the default cases
again is not very useful, so by convention NOTES never configures defaults,
except of course where it is broken.  This commit is to fix 1 broken place.

Not repeating the default is also good for NOTES' secondary purpose of
documentation.  Defaults are easy to find by grepping the source code for
them if there is no documentation.  Changing defaults to valid and useful
values requires understanding more of the source if there is no documentation.


Modified: head/sys/conf/NOTES
==
--- head/sys/conf/NOTES Fri Mar 29 03:25:20 2019(r345679)
+++ head/sys/conf/NOTES Fri Mar 29 04:00:46 2019(r345680)
@@ -150,7 +150,7 @@ options BOOTHOWTO=RB_MULTIPLE
 #
 # Default boot tag; may use 'kern.boot_tag' loader tunable to override.  The
 # current boot's tag is also exposed via the 'kern.boot_tag' sysctl.
-optionsBOOT_TAG=\"---<>---\"
+optionsBOOT_TAG=\"\"


Useful variations are not always easy to invent.  I usually just add 1 for
numeric values.  This example is useful.  It kills the boot tag.  It gives
an empty tag, and the kernel does extra work to avoid printing a newline
after an empty tag.


 # Maximum boot tag size the kernel's static buffer should accomodate.  Maximum
 # size for both BOOT_TAG and the assocated tunable.
 optionsBOOT_TAG_SZ=32


This bug remains unfixed.  32 is the default.  This option shouldn't exist.
Instead, just use size strlen(BOOT_TAG) + 1 for the static string and keep
the dynamic string in the environment.  The string is only used once, and
msgbufinit() already has to check both the static string and the environment
to find the right string (it does this by fetching the dynamic string to
overwrite the static string, but it is easier to not use a tunable or
support a sysctl and just keep the dynamic string in the environment).

Bruce
___
svn-src-all@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"


Re: svn commit: r345680 - head/sys/conf

2019-03-28 Thread Rodney W. Grimes
> -Original Message-
> From:  on behalf of Kyle Evans 
> 
> Date: 2019-03-28, Thursday at 21:00
> To: , , 
> 
> Subject: svn commit: r345680 - head/sys/conf
> 
> > Author: kevans
> > Date: Fri Mar 29 04:00:46 2019
> > New Revision: 345680
> > URL: https://svnweb.freebsd.org/changeset/base/345680
> > 
> > Log:
> >   NOTES: Use non-default value for BOOT_TAG
> 
> Why?
> 
> (I was on IRC when jhb debugged this, but I didn't quite get it; and of 
> course lots of us *weren't* on IRC at the time.)

Yes, please, why is this beeing changed, do I need to revise my .sh that
was hunting for the old string to use what now?  Or do I need to now
override this in my KERNCONF files?

I think changing this in stable/12 is a POLA issue.

> Thanks,
> 
> Ravi (rpokala@)
> 
> >   Reported by:  jhb
> >   MFC after:1 week (except non-empty value in stable/11)

Why is 11 being treated special, or is it that it does not implement
BOOT_TAG at all?

Does this deserve a RELNOTES Y, or UPDATING entry?

> > Modified:
> >   head/sys/conf/NOTES
> > 
> > Modified: head/sys/conf/NOTES
> > ==
> > --- head/sys/conf/NOTES Fri Mar 29 03:25:20 2019(r345679)
> > +++ head/sys/conf/NOTES Fri Mar 29 04:00:46 2019(r345680)
> > @@ -150,7 +150,7 @@ options BOOTHOWTO=RB_MULTIPLE
> >  #
> >  # Default boot tag; may use 'kern.boot_tag' loader tunable to override.  
> > The
> >  # current boot's tag is also exposed via the 'kern.boot_tag' sysctl.
> > -optionsBOOT_TAG=\"---<>---\"
> > +optionsBOOT_TAG=\"\"
> >  # Maximum boot tag size the kernel's static buffer should accomodate.  
> > Maximum
> >  # size for both BOOT_TAG and the assocated tunable.
> >  optionsBOOT_TAG_SZ=32
> 
> 
> 
> 
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@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"


Re: svn commit: r345680 - head/sys/conf

2019-03-28 Thread Ravi Pokala
-Original Message-
From:  on behalf of Kyle Evans 

Date: 2019-03-28, Thursday at 21:00
To: , , 

Subject: svn commit: r345680 - head/sys/conf

> Author: kevans
> Date: Fri Mar 29 04:00:46 2019
> New Revision: 345680
> URL: https://svnweb.freebsd.org/changeset/base/345680
> 
> Log:
>   NOTES: Use non-default value for BOOT_TAG

Why?

(I was on IRC when jhb debugged this, but I didn't quite get it; and of course 
lots of us *weren't* on IRC at the time.)

Thanks,

Ravi (rpokala@)

>   Reported by:jhb
>   MFC after:  1 week (except non-empty value in stable/11)
> 
> Modified:
>   head/sys/conf/NOTES
> 
> Modified: head/sys/conf/NOTES
> ==
> --- head/sys/conf/NOTES   Fri Mar 29 03:25:20 2019(r345679)
> +++ head/sys/conf/NOTES   Fri Mar 29 04:00:46 2019(r345680)
> @@ -150,7 +150,7 @@ options   BOOTHOWTO=RB_MULTIPLE
>  #
>  # Default boot tag; may use 'kern.boot_tag' loader tunable to override.  The
>  # current boot's tag is also exposed via the 'kern.boot_tag' sysctl.
> -options  BOOT_TAG=\"---<>---\"
> +options  BOOT_TAG=\"\"
>  # Maximum boot tag size the kernel's static buffer should accomodate.  
> Maximum
>  # size for both BOOT_TAG and the assocated tunable.
>  options  BOOT_TAG_SZ=32



___
svn-src-all@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"