Re: Adding an ioctl to check for disklabel existence
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 should be retiring > DIOCGDINFO usage as much as possible, rather than figuring out > how to enhance it.. Thanks for all comments. Overall I agree - let's leave it alone for now. I have a slightly-evil-but-not-too-hackish idea what to do in sysinst to avoid special casing it at all. Martin
Re: Proposal, again: Disable autoload of compat_xyz modules
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 cross-compile from NetBSD to get the cross-toolchain, or did = > you need some Linux stuff already compiled? > >> I compiled everything natively on NetBSD, from NetBSD. No Linux stuff > >> precompiled. > > Did you not need Linux compat at this stage? > No. It was needed only to test hello-world example. > Such musl-gcc approach to build non-trivial applications will most > likely fail as we will still be detected as NetBSD and this will affect > the end result. I guess I need to go to musl-libc.org website and their git site. I remember seeing something about cross-compiling, also saw some bad links. > For building applications with dependencies we will need to do it at > least in chroot. Applications would be built and installed into a separate sysroot. Question is whether such a sysroot could run mounted on /emul/linux, as well as in its own partition or USB stick. > However.. getting this setup to build larger packages with plain > musl-gcc is viable. It's a matter of cost vs benefit here. I am still not sure whether I do better with musl as opposed to glibc. > > How does the compiler at NetBSD end know what OS to compile for? Is it= > a matter of the appropriate tuple or triplet? > ELF is similar on NetBSD and Linux, the are few differences that are > handled with musl-gcc GCC script. > However it would involve some work to build non-trivial applications. > >>> But I believe you would need Linux kernel headers in any case. > >> This might be the case that the Linux kernel headers needed that are > >> GPLv2. If so, it will be easier and quicker to get > >> MUSL+LTP+GMAKE+LINUX_HEADERS|(+BASH+) as a package in pkgsrc. > > I found musl, uclibc and glibc in pkgsrc/wip . One is not likely to ge= > t far building packages with pkgsrc, or FreeBSD with ports, without gmake= > and bash. > > Linux headers would not have to be built, but it would be necessary to = > configure and build the Linux kernel. > Building the Linux kernel with musl-gcc can be more tricky as there are > certainly hacks assuming uname=3DLinux. > However... it should be doable. > > Perhaps, musl could be downloaded from their website and compiled. > I was wondering whether there would be a use-case for integration of > MUSL into src/? > >> Implementing everything as a part of src/ is possible, but needs more > >> work and more GPL code around. > >>> Where do you get musl-gcc, or is it built as part of the light cross-= > toolchain? > It is part of the musl git repo. > https://git.musl-libc.org/cgit/musl/ > There is need to build musl-gcc.specs.sh and musl-gcc > https://git.musl-libc.org/cgit/musl/tree/Makefile > I had to run "gmake musl-gcc" "gmake musl-gcc.specs" or similar. I would > need to reproduce it or package to recall the exact commands. > I had to install musl into /usr/local + the ELF leader link into > /lib/ld-musl*. Tom
re: Adding an ioctl to check for disklabel existence
> 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 mark this? it seems to be entirely unused in our code base. 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.. .mrg.
Re: Proposal, again: Disable autoload of compat_xyz modules
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 compat_netbsd < NetBSD-5.0 >> >> Comments? >> >> christos >> >... >> +"compat_linux", >> +"compat_linux32", > >Kinda shocking that nowhere in this thread do we bring up the fact that >compat_linux is not currently being auto-loaded (since a 2017 change by >maxv). > >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. christos
Re: Adding an ioctl to check for disklabel existence
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 detectable? If the
kernel invents a lael, it says "fictitious" in the label field.
All we need to do is make sure that no label read from a disc (into
the kernel, if read directly by userland, then userland knows what it
got and from where, already) contains that value, right? Like if
someone has actually written a label with that string ("fictitious")
to a drive, then when read back we just change it to "unnamed" (or even
just empty) -- it is a bit hard to believe that anyone wants their drive
actuially named "fictitious" (they'd still be able to use "fictional"
if they wanted).
| Now sometimes it is important to know the difference.
If we do that, we will know the difference, and what's more:
| some architectures have native ways to store their partitions [...]
| The kernel converts internally from the native partitions to disklabel when
| trying to read a disklabel,
when that happens, it could set the label to "converted" or if
the native format has a name that we include, put that name in brackets
("[name]") or something so it can be reconised (and then remove the
brackets if this is one of the cases where the kernel coverts back).
| Userland, however, has no way (that I know of) to learn about
| such conversions.
After that it would have, without need for extra ioctls (or for that
matter, any extra system call or work beyond a strcmp or two) - and what's
more it would work just fine with existing tools, as only the kernel, and
then utilities that desire to make use of the extra info (sysinst I presume)
needs to be changed.
We could have the disklabel utility refuse to allow the user to write
back a label containing "fictitious" (or "converted") as a name sometime
later (or now, bnut that isn't really crucial, and people using existing
tools wouldn't see such a change anyway).
| Or just extend and version DIOCGDINFO to provide that flag word in addition
| to the disklabel?
Do we actually need something new, or just this interpretation of the
label field?
kre
Re: Fonts for console/fb for various locales: a proposal
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? Thor
Re: Adding an ioctl to check for disklabel existence
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 change anything here, in particular not add new functionality. There is already too much magic. If we really need to distinguish between read and faked labels we could tag the faked labels. There are unused words, even spare ones that could hold flags or magic numbers. Reading a label from disk would then need to verify and strip such information. The real problem however is then to write a label. Just writing a normal label that would override the faked label after a reboot might be confusing when native OS and NetBSD don't agree in their partitioning scheme. It might be simpler to just let writing a disklabel fail when a faked one is used. Then userland doesn't have to be aware of the difference, just handle the error. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Adding an ioctl to check for disklabel existence
> 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 such > disks, as -r makes disklabel check for a *real* disklabel and fail if > there is none (and besides arcon32, the userland disklabel binary > does not know of any such magic kernel conversion). [ side note: that > acorn32 magic userland code should be removed ] Userland has fdisk for MBR parititoning, disklabel -r for BSD disklabels, and sunlabel for Sun labels. (Are there other such tools? I'm not aware of any.) It seems to me that the rightest ways to go, depending on which way NetBSD wants to jump here, are (1) Eliminate such knowledge from userland entirely. (2) Merge tools such as fdisk and sunlabel into disklabel -r (though MBR partitioning is a bit of an odd duck in practice, because MBR partitions are typically carved up further, which in my experience is not true of either BSD or Sun labels). (3) Split acorn32 userland code out into a separate userland tool a la sunlabel; ideally, write similar tools for any other formats of interest (IIRC mac68k has one, though that memory is fuzzy; there doubtless are others I know nothing about). (4) Something else I haven't thought of. That is, pick a direction and then go there. The current state is a rather ad-hoc mishmash of all three of the above, with all the issues that inconsistency brings. Personally, I don't like (1), because I find such tools too useful; I'm not sure whether I prefer (2) or (3). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Adding an ioctl to check for disklabel existence
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 $mydisk and see it fail if no label is present. If you just ask for the label disklabel $mydisk you will always get something. This happens because the kernel fakes a "fictious" label on all disks if none is found. Now sometimes it is important to know the difference. 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. The kernel converts internally from the native partitions to disklabel when trying to read a disklabel, and sometimes even converts back on writes to the disklabel. This is a bit unfortunate, but back then likely was the easiest way to get things going. Userland, however, has no way (that I know of) to learn about such conversions. The above recipe with "disklabel -r" will fail on such disks, as -r makes disklabel check for a *real* disklabel and fail if there is none (and besides arcon32, the userland disklabel binary does not know of any such magic kernel conversion). [ side note: that acorn32 magic userland code should be removed ] Should we add a DIOCGDINFOREAL (or whatever we name it) disk ioctl that returns the disklabel, but additionaly a flag indication if it is fictious, real or generated from some other representation? Or just extend and version DIOCGDINFO to provide that flag word in addition to the disklabel? Third alternative is to do nothing. The code where I ran into this in sysinst can be fixed differently (and very localy in sysinst code). Opinions? Martin
Re: Proposal, again: Disable autoload of compat_xyz modules
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 > ... > + "compat_linux", > + "compat_linux32", Kinda shocking that nowhere in this thread do we bring up the fact that compat_linux is not currently being auto-loaded (since a 2017 change by maxv). 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.
