Re: Proposal, again: Disable autoload of compat_xyz modules

2019-09-29 Thread maya
On Sat, Sep 28, 2019 at 01:29:39AM -, Christos Zoulas wrote: > Here's what I've implemented: > > kern.module.noautoload="compat_linux* compat_[0-4]?" > > This disables autoload for all compat_linux modules as well > as compat_netbsd < NetBSD-5.0 > > Comments? > > christos > ... > +

Re: Fonts for console/fb for various locales: a proposal

2019-09-29 Thread Thor Lancelot Simon
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

Re: Adding an ioctl to check for disklabel existence

2019-09-29 Thread Mouse
> So far all good. But there is a catch: some architectures have native > ways to store their partitions and no real userland support for those > schemes. [...] > Userland, however, has no way (that I know of) to learn about such > conversions. The above recipe with "disklabel -r" will fail on

Re: Adding an ioctl to check for disklabel existence

2019-09-29 Thread Michael van Elst
mar...@duskware.de (Martin Husemann) writes: >So far all good. But there is a catch: some architectures have native >ways to store their partitions and no real userland support for those schemes. Some drivers may also have their own idea about what disklabels are, in particular cd(4). I wouldn't

Adding an ioctl to check for disklabel existence

2019-09-29 Thread Martin Husemann
Hey folks, I am wondering, despite the fact that we are trying to phase out as many uses of disklabels as fast as we can, if we should add an ioctl to the disk devices that tells us if a label has been found. Currently the only method to check a "blank" disk is to run disklabel -r

re: Adding an ioctl to check for disklabel existence

2019-09-29 Thread matthew green
> Yes, we will - but can't we make that something detectable? If the > kernel invents a lael, it says "fictitious" in the label field. i had a similar idea, and i like your "converted" idea too. i was looking at struct disklabel itself, and while i realised we could probably abuse d_subtype to

Re: Proposal, again: Disable autoload of compat_xyz modules

2019-09-29 Thread Christos Zoulas
In article <20190929090053.g...@homeworld.netbsd.org>, wrote: >On Sat, Sep 28, 2019 at 01:29:39AM -, Christos Zoulas wrote: >> Here's what I've implemented: >> >> kern.module.noautoload="compat_linux* compat_[0-4]?" >> >> This disables autoload for all compat_linux modules as well >> as

Re: Proposal, again: Disable autoload of compat_xyz modules

2019-09-29 Thread Thomas Mueller
from Kamil Rytarowski: > My primary motivation is running LTP kernel regression tests for > compat_linux and integrate them into ATF (src/tests). > With musl it is posible to get cross-toolchain for the same CPU > configuration as host without building customized gcc/clang. > >>> Did you

Re: Adding an ioctl to check for disklabel existence

2019-09-29 Thread Martin Husemann
On Mon, Sep 30, 2019 at 11:15:02AM +1000, matthew green wrote: > 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

Re: Adding an ioctl to check for disklabel existence

2019-09-29 Thread Robert Elz
Date:Sun, 29 Sep 2019 13:32:51 +0200 From:Martin Husemann Message-ID: <20190929113251.ga12...@mail.duskware.de> | If you just ask for the label | | disklabel $mydisk | | you will always get something. Yes, we will - but can't we make that something