Re: Proposal, again: Disable autoload of compat_xyz modules
In article <201909301931.x8ujvvve028...@server.cornerstoneservice.ca>, John Nemeth wrote: >On Sep 30, 1:06pm, Michael van Elst wrote: >} On Mon, Sep 30, 2019 at 12:37:38AM -0700, John Nemeth wrote: >} >} > BTW, modules.conf isn't read by the kernel, it's read by >} > /etc/rc.d/modules. Putting anything in there that would have a >} > lasting effect (i.e. parameters for autoloaded modules) would >} > require quite a bit of work. >} >} You could just store the parameters in the kernel so that a future >} autoload will use these instead of or merged with the plist. > > You could do this using the backend code for the proposed >sysctl. The question then is how do you know when the .plist is >changed? Would you attach some kind of a kevent to it? If so, then >you need to track the source of the entry in the "blacklist". If >it came from the .plist, then upon receiving notification that it >has changed, then you want to delete the entry. However, if it >came from userland via sysctl or is part of the default list, then >you don't want to delete the entry just because the .plist changed. >This is starting to get complicated with corner cases. I am not sure what gets priority here. The command line arguments in modules.conf or the plist entries (when both exist)? Also while it is attractive to store the plist next to the module we currently install 0 plists. What is the expectation here? That one will use modload to generate plists or that we are going to put the arguments in modules.conf? I think that the plists were meant to be static (as the arguments in modules.conf) and they would take effect only during load time. The variables in the plists are also supposed to be module-specific not global. christos
Re: Proposal, again: Disable autoload of compat_xyz modules
On Sep 30, 1:06pm, Michael van Elst wrote: } On Mon, Sep 30, 2019 at 12:37:38AM -0700, John Nemeth wrote: } } > BTW, modules.conf isn't read by the kernel, it's read by } > /etc/rc.d/modules. Putting anything in there that would have a } > lasting effect (i.e. parameters for autoloaded modules) would } > require quite a bit of work. } } You could just store the parameters in the kernel so that a future } autoload will use these instead of or merged with the plist. You could do this using the backend code for the proposed sysctl. The question then is how do you know when the .plist is changed? Would you attach some kind of a kevent to it? If so, then you need to track the source of the entry in the "blacklist". If it came from the .plist, then upon receiving notification that it has changed, then you want to delete the entry. However, if it came from userland via sysctl or is part of the default list, then you don't want to delete the entry just because the .plist changed. This is starting to get complicated with corner cases. }-- End of excerpt from Michael van Elst
cprng x y z: failed statistical RNG test
After switching to a DIAGNOSTIC+DEBUG+LOCKDEBUG (8.1) kernel, I get lots of messages I haven't seen before: Kernel RNG "3348 0 0" long run test FAILURE: Run of 26 0s found cprng 3348 0 0: failed statistical RNG test Kernel RNG "6079 29 0" long run test FAILURE: Run of 26 1s found cprng 6079 29 0: failed statistical RNG test Kernel RNG "18472 1 0" long run test FAILURE: Run of 26 0s found cprng 18472 1 0: failed statistical RNG test Kernel RNG "6467 1 0" long run test FAILURE: Run of 26 0s found cprng 6467 1 0: failed statistical RNG test Kernel RNG "24433 5 3" runs test FAILURE: too many runs of 5 1s (211 >= 209) cprng 24433 5 3: failed statistical RNG test Kernel RNG "3914 0 0" poker test failure: parameter X = 2.960 cprng 3914 0 0: failed statistical RNG test Kernel RNG "3947 0 0" poker test failure: parameter X = 49.51040 cprng 3947 0 0: failed statistical RNG test Kernel RNG "20014 0 1" runs test FAILURE: too many runs of 1 1s (2688 >= 2685) cprng 20014 0 1: failed statistical RNG test Kernel RNG "22038 48 1" long run test FAILURE: Run of 27 1s found cprng 22038 48 1: failed statistical RNG test Kernel RNG "27178 1 1" runs test FAILURE: too few runs of 1 0s (2308 <= 2315) cprng 27178 1 1: failed statistical RNG test Kernel RNG "29061 9 4" runs test FAILURE: too few runs of 3 1s (526 <= 527) cprng 29061 9 4: failed statistical RNG test Kernel RNG "28659 2 6" poker test failure: parameter X = 1.79840 cprng 28659 2 6: failed statistical RNG test Kernel RNG "22021 11 8" long run test FAILURE: Run of 28 0s found cprng 22021 11 8: failed statistical RNG test Kernel RNG "16081 0 0" long run test FAILURE: Run of 26 0s found cprng 16081 0 0: failed statistical RNG test Kernel RNG "25242 0 1" poker test failure: parameter X = 48.53120 cprng 25242 0 1: failed statistical RNG test Kernel RNG "11772 0 1" long run test FAILURE: Run of 26 0s found cprng 11772 0 1: failed statistical RNG test Kernel RNG "9936 1 0" runs test FAILURE: too many runs of 1 0s (2708 >= 2685) cprng 9936 1 0: failed statistical RNG test Kernel RNG "13842 1 7" long run test FAILURE: Run of 26 0s found cprng 13842 1 7: failed statistical RNG test Kernel RNG "7761 1 0" runs test FAILURE: too few runs of 2 1s (1110 <= 1114) cprng 7761 1 0: failed statistical RNG test Kernel RNG "16658 15 0" monobit test FAILURE: 10298 ones cprng 16658 15 0: failed statistical RNG test Kernel RNG "6892 5 1" long run test FAILURE: Run of 27 0s found cprng 6892 5 1: failed statistical RNG test This was all within an hour. Is it something to worry about?
Re: Fonts for console/fb for various locales: a proposal
On Mon, Sep 30, 2019 at 11:01:51AM +0200, tlaro...@polynum.com wrote: > On Mon, Sep 30, 2019 at 10:32:40AM +0200, Martin Husemann wrote: > > I guess noone would object a metafont2wsfont converter tool. > > Look at the true type tool Michael mentioned in xsrc/local and do something > > similar for metafont. > > I have already planed to re-start with the Hershey fonts, for reasons > explained in my initial mail and for others and this will be combined > with TeX (kerTeX). So there will probably be something in this > line, at the end, even if it is only for my own use. Sorry for late comment but I would like to suggest mlterm-fb as - probably - easiest solution for Your case (if I understood problem correctly, of course). mlterm running in framebuffer console is capable to use wide range of standard X fonts[1] without hassle. If You want to convert fonts to wsfont You may take a look at some additional resources. In addition to already mentioned there is also my small tool[2], created for my own work for bitmap terminus fonts (see [3] for gallery) - it isn't useful for converting vectors, but may provide a hints about your own methods of mapping from UTF codes or Adobe names to particular code pages (wide range of definitions is provided by original terminus package, for my case I made only one, for cp437). 1 - https://www.mail-archive.com/netbsd-users@netbsd.org/msg10136.html 2 - https://github.com/aniou/bdf2wsfont 3 - http://smutek.pl/netbsd/wsfont/terminus/ 4 - http://terminus-font.sourceforge.net/ -- Piotr 'aniou' Meyer
Re: Fonts for console/fb for various locales: a proposal
On Mon, Sep 30, 2019 at 02:23:02PM +0200, Piotr Meyer wrote: > On Mon, Sep 30, 2019 at 11:01:51AM +0200, tlaro...@polynum.com wrote: > > On Mon, Sep 30, 2019 at 10:32:40AM +0200, Martin Husemann wrote: > > > I guess noone would object a metafont2wsfont converter tool. > > > Look at the true type tool Michael mentioned in xsrc/local and do > > > something > > > similar for metafont. > > > > I have already planed to re-start with the Hershey fonts, for reasons > > explained in my initial mail and for others and this will be combined > > with TeX (kerTeX). So there will probably be something in this > > line, at the end, even if it is only for my own use. > > Sorry for late comment but I would like to suggest mlterm-fb as > - probably - easiest solution for Your case (if I understood problem > correctly, of course). mlterm running in framebuffer console is > capable to use wide range of standard X fonts[1] without hassle. > > If You want to convert fonts to wsfont You may take a look at some > additional resources. In addition to already mentioned there is also > my small tool[2], created for my own work for bitmap terminus fonts > (see [3] for gallery) - it isn't useful for converting vectors, but > may provide a hints about your own methods of mapping from UTF codes > or Adobe names to particular code pages (wide range of definitions is > provided by original terminus package, for my case I made only one, > for cp437). > > 1 - https://www.mail-archive.com/netbsd-users@netbsd.org/msg10136.html > 2 - https://github.com/aniou/bdf2wsfont > 3 - http://smutek.pl/netbsd/wsfont/terminus/ > 4 - http://terminus-font.sourceforge.net/ > Thank you for the links. When I will tackle the task I will also provide short explanations about what different pieces achieve and comparisons between solutions (for example, I guess, since this has been totally lost in the huge hay stack of TeXLive, that very few people know about virtual fonts, even less know how it works; few people can make a link between METAFONT, freetype or Cairo; few people know how DVI compares to PDF, or that one can compare METAFONT/TeX/DVI with PS, doing in three what is done in one with the full fledge PS programming language---leading after to a drop of a part of PS to keep only PDF in a wide range of cases; etc.). -- Thierry Laronde http://www.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: Proposal, again: Disable autoload of compat_xyz modules
On Mon, Sep 30, 2019 at 12:37:38AM -0700, John Nemeth wrote: > Uh, that's not true. If you store .plist in the same > directory with the module, it will be loaded and passed to the > module to provide parameters. Good to know. > BTW, modules.conf isn't read by the kernel, it's read by > /etc/rc.d/modules. Putting anything in there that would have a > lasting effect (i.e. parameters for autoloaded modules) would > require quite a bit of work. You could just store the parameters in the kernel so that a future autoload will use these instead of or merged with the plist. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Adding an ioctl to check for disklabel existence
Date:Mon, 30 Sep 2019 06:43:10 - (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | It also says 'fictitious' when you then write that label and read it | back (and that magic word is also used by the wedge naming code to | be treated like an empty label). Yes, the idea (the one change that would be needed) was to delete (blank/zero out) the label in the label read from disc routine(s) if it is seen to contain "fictitious" - then the wedge code wouldn't need to deal with it. | It might be easier to use a different, more obscure field in the | disklabel instead of d_packname (the "label" field) for such magic | values. It makes little difference, whatever is used when the kernel invents one, disklabel (or at least old versions of it) will simply write it to disc when making (unrelated) changes. The kernel is already using this field - inserting its magic value, we don't really want that in a from disc label, so fixing the label read routine(s) to delete it is probably worth doing whether or not Martin decides to use this, or another method, to deal with non disklabel labels that have been translated. kre
Re: Fonts for console/fb for various locales: a proposal
On Mon, Sep 30, 2019 at 10:32:40AM +0200, Martin Husemann wrote: > I guess noone would object a metafont2wsfont converter tool. > Look at the true type tool Michael mentioned in xsrc/local and do something > similar for metafont. I have already planed to re-start with the Hershey fonts, for reasons explained in my initial mail and for others and this will be combined with TeX (kerTeX). So there will probably be something in this line, at the end, even if it is only for my own use. The next visible step will be on the users mailing list, to hopefully find japanese speaking users able to "sort" the oriental glyphes when I will produce the whole rendering of the Hershey fonts. -- Thierry Laronde http://www.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: Fonts for console/fb for various locales: a proposal
I guess noone would object a metafont2wsfont converter tool. Look at the true type tool Michael mentioned in xsrc/local and do something similar for metafont. Martin
Re: Proposal, again: Disable autoload of compat_xyz modules
On Sep 30, 7:10am, Michael van Elst wrote: } chris...@astron.com (Christos Zoulas) writes: } >In article <20190929090053.g...@homeworld.netbsd.org>, } > wrote: } >>On Sat, Sep 28, 2019 at 01:29:39AM -, Christos Zoulas wrote: } >>> + "compat_linux", } >>> + "compat_linux32", } >> } >>As for the actual change, I'd like to see it integrated through } >>modules.conf, not via settings of default sysctl values. I think it's } >>bad user experience. } } >modules.conf contains module names and their arguments. It is a configuration } >file for each module. There are already sysctls in the kern.module. tree all } >related to autoloading. } } Everything currently in modules.conf is loaded permanently. One argument } for adding autoload support would be that it allows to configure module } parameters in a common place, as autoloaded modules cannot get parameters } yet. It could also be used to configure policies (e.g. blacklists). Uh, that's not true. If you store .plist in the same directory with the module, it will be loaded and passed to the module to provide parameters. You can use "modload -p" to create the file (see module(7)). Also, if you put a special flag in the .plist the module won't be autoloaded, see this from module(9): The directory from which the module is loaded will be searched for a file with the same name as the module file, but with the suffix ``.plist''. If this file is found, the prop_dictionary it contains will be loaded and passed to the module's modcmd() routine. If this prop_dictionary contains a ``noautoload'' property which is set to ``true'' then the system will refuse to load the module. BTW, modules.conf isn't read by the kernel, it's read by /etc/rc.d/modules. Putting anything in there that would have a lasting effect (i.e. parameters for autoloaded modules) would require quite a bit of work. Although it could be made to specify modules not to autoload by having it use christos' kern.module.noautoload sysctl. }-- End of excerpt from Michael van Elst
COMPAT_NETBSD32 broken on aarch64 due to UVM bug
Hi, COMPAT_NETBSD32 has been broken for aarch64, since jemalloc became to mmap 8KB-aligned anonymous memory for earm. Running 32-bit binaries easily causes KASSERT failure like this: panic: kernel diagnostic assertion "!topdown || hint <= orig_hint" failed: file "../../../../uvm/uvm_map.c", line 2164 hint: fbefc000, orig_hint: f2c2f000 This seems to be an MI bug, not MD; uvm_findspace() is broken in the cases where a required alignment (8KB) is larger than the native page size (4KB). For more details, please see kern/54395: http://gnats.netbsd.org/54395 With the patch attached in the PR, that KASSERT does no longer fire on aarch64 with 32-bit binaries, as far as I can see. Also, the patched kernels just work for me on amd64, earm, and m68k. This also affects netbsd-9 branch. I'd like to fix this before 9.0 is released. Could anyone please review my patch, or provide a better fix? Thanks, rin
Re: Adding an ioctl to check for disklabel existence
m...@eterna.com.au (matthew green) writes: >however, disklabel fails at >2TiB for 512 byte sector, so i'm >now thinking that fixing this doesn't really solve the problem >for the future properly -- disklabel doesn't return a true >label here anyway... so it seems that we should be retiring >DIOCGDINFO usage as much as possible, rather than figuring out >how to enhance it.. The problem is not with default labels (i.e. no disklabel yet written) but with generated ones (converted from some native label). All such labels are (so far) as limited as disklabels and couldn't be used for larger disks. So I don't think that this is a problem. Tagging such labels with a magic value or flag bit has also a very limited scope. If we have native labels that support larger disks we can easily write a wedge autodiscover method for these. Of course we could do this also without the need for larger disks and phase out the fake label generation somewhen. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Proposal, again: Disable autoload of compat_xyz modules
chris...@astron.com (Christos Zoulas) writes: >In article <20190929090053.g...@homeworld.netbsd.org>, > wrote: >>On Sat, Sep 28, 2019 at 01:29:39AM -, Christos Zoulas wrote: >>> + "compat_linux", >>> + "compat_linux32", >> >>As for the actual change, I'd like to see it integrated through >>modules.conf, not via settings of default sysctl values. I think it's >>bad user experience. >modules.conf contains module names and their arguments. It is a configuration >file for each module. There are already sysctls in the kern.module. tree all >related to autoloading. Everything currently in modules.conf is loaded permanently. One argument for adding autoload support would be that it allows to configure module parameters in a common place, as autoloaded modules cannot get parameters yet. It could also be used to configure policies (e.g. blacklists). But that's a far way. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Fonts for console/fb for various locales: a proposal
Hello, On Sun, 29 Sep 2019 18:02:14 -0400 Thor Lancelot Simon wrote: > On Sat, Sep 28, 2019 at 02:39:19PM +0200, tlaro...@polynum.com wrote: > > > > 4. Rasterizing (c). This is the whole purpose of METAFONT. METAFONT is a > > rasterizer. > > Rasterization of vector fonts by privileged code has been a major source > of security holes in other operating systems. Does the very limited > benefit really justify the risk? We already have support for alpha fonts, which are rasterized vector fonts. On most supported hardware you can take a truetype font, feed it to a utility found in xsrc/local/programs/ttf2wsfont to generate a rendering in whatever size you specify, and load that into a wsdisplay. There's also something to directly load BDF fonts. Caveat: it's the user's responsibility to make sure the font is suitable for console use, as in, monospace or at least not excessively proportional. have fun Michael PS: please discard if irrelevant, I somehow missed the original mail.
Re: Adding an ioctl to check for disklabel existence
k...@munnari.oz.au (Robert Elz) writes: >Yes, we will - but can't we make that something detectable? If the >kernel invents a lael, it says "fictitious" in the label field. It also says 'fictitious' when you then write that label and read it back (and that magic word is also used by the wedge naming code to be treated like an empty label). It might be easier to use a different, more obscure field in the disklabel instead of d_packname (the "label" field) for such magic values. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
