Re: Reserve device major numbers for pkgsrc
On 19.02.2019 08:17, Michael van Elst wrote: > n...@gmx.com (Kamil Rytarowski) writes: > >> =46rom end-user point of view major and minor numbers don't matter most o= >> f >> the time (are there exceptions?) and it might be picked by the kernel >> dynamically. > > When the kernel choses major numbers dynamically, it must also provide > a dynamically generated mapping to userland. > > Minor numbers usually translate 1:1 into device units, they cannot be > chosen dynamically. > > End-users are usually concerned with major/minor numbers in that they > don't change (e.g. for find -xdev) and sometimes don't change over > reboots or even re-installations (think about backup). > > The most simple method to assign major numbers is to assign them > during installation. Can be as simple as a file in /etc as a registry, > MAKEDEV to create /dev entries and a system call (probably sysctl) > that augments the device switches. Combining the system call with > the module loader is possible, but won't work for autoloaded modules > (not a problem for HAXM). > I feel corrected that non -U builds need it for other purposes, mostly file grants. As discussed internally an issue with devfs is that (according to my observation) that expectations raise too much and people start to demand functionality comparable to automounter. Something similar appeared in Linux with all the devfs, udev, sysfs etc.. Also touching major numbers can trigger temptation to change namespace of devices from numbers to strings (I don't really see win myself in exchange for compat breakage)... so better to leave it as it is. For cases such as HAXM the least bad solution is to add haxmfs and union mount over /dev (providing /dev/hax_vm*/* nodes).. however until it will become a blocker to ship only 8 VMs x 16 VCPUs I will keep using traditional mknod(2) approach. If there are no more concerns I will apply this patch: http://netbsd.org/~kamil/patch-00086-pkgsrc-majors.2.txt Probably with bumped major numbers as we are soon acquiring another major for KCOV. signature.asc Description: OpenPGP digital signature
Re: Reserve device major numbers for pkgsrc
n...@gmx.com (Kamil Rytarowski) writes: >=46rom end-user point of view major and minor numbers don't matter most o= >f >the time (are there exceptions?) and it might be picked by the kernel >dynamically. When the kernel choses major numbers dynamically, it must also provide a dynamically generated mapping to userland. Minor numbers usually translate 1:1 into device units, they cannot be chosen dynamically. End-users are usually concerned with major/minor numbers in that they don't change (e.g. for find -xdev) and sometimes don't change over reboots or even re-installations (think about backup). The most simple method to assign major numbers is to assign them during installation. Can be as simple as a file in /etc as a registry, MAKEDEV to create /dev entries and a system call (probably sysctl) that augments the device switches. Combining the system call with the module loader is possible, but won't work for autoloaded modules (not a problem for HAXM). -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Reserve device major numbers for pkgsrc
On 17.02.2019 21:28, Christoph Badura wrote: > On Sat, Feb 16, 2019 at 09:02:05PM -0800, John Nemeth wrote: >> On Feb 16, 11:25pm, Kamil Rytarowski wrote: >> } Where and how to reserve these major numbers? >> >> The ideal thing is to not reserve numbers at all and have them >> allocated dynamically. This requires the module reporting the >> number that was allocated to userland somehow. However, the only >> thing that is coming to mind off the top of my head is printf(9) >> which would normally land in /var/log/messages. > > We have sysctl as an easy an convenient way. > From end-user point of view major and minor numbers don't matter most of the time (are there exceptions?) and it might be picked by the kernel dynamically. I don't see how printing them in dmesg(8) or exposing to sysctl(2) help. > Maybe we should think of a standard way to do that there. E.g. like a > separate hierarchy for modules and a standard way of naming them. > I'm not sure what does this part mean, but HAXM (and certainly other users of device nodes) needs them located in exact places (/dev/HAXM etc). > --chris > devfs is the way to go, but I cannot add this now or short term. Once we will get devfs functional we can remove restriction of building the full release as root on NetBSD as this supports generating /dev entries (mknod(8)). We could drop -U option entirely and need for privileged builds. (I'm aware that this can be worked around and OS will try to generate the devices on the first boot). From the HAXM point of view I will enable support for 64 VMs and until then I will keep the restriction to 8 VMs in order to reduce the population of HAX entries in /dev. signature.asc Description: OpenPGP digital signature
Re: Reserve device major numbers for pkgsrc
On Sat, Feb 16, 2019 at 09:02:05PM -0800, John Nemeth wrote: > Of course, the real ideal thing would be to get a devfs and > get rid of the concept of major numbers. Here I go again, starting > contriversies. :-> A more viable approach: use strings instead of major numbers. Even in ufs1 with 32-bit block pointers there's 60 bytes available for this, which is more than ample. There's still a namespace management issue, but it's no worse than (and can be made the same as) the namespace management issue we currently have with driver names. -- David A. Holland dholl...@netbsd.org
Re: Reserve device major numbers for pkgsrc
On Sat, Feb 16, 2019 at 09:02:05PM -0800, John Nemeth wrote: > On Feb 16, 11:25pm, Kamil Rytarowski wrote: > } Where and how to reserve these major numbers? > > The ideal thing is to not reserve numbers at all and have them > allocated dynamically. This requires the module reporting the > number that was allocated to userland somehow. However, the only > thing that is coming to mind off the top of my head is printf(9) > which would normally land in /var/log/messages. We have sysctl as an easy an convenient way. Maybe we should think of a standard way to do that there. E.g. like a separate hierarchy for modules and a standard way of naming them. --chris
Re: Reserve device major numbers for pkgsrc
> Of course, the real ideal thing would be to get a devfs and get rid > of the concept of major numbers. For many purposes. But, if it's not possible to hand-build a /dev with only a few entries, that will cripple usefulness a number of possible locked-down uses, from chroot() to unusual setups like two I know of for an embedded product where /sbin/init is not a normal init(8) and /dev has only eight entries in one case or thirty in the other. /~\ 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
Re: Reserve device major numbers for pkgsrc
On Feb 16, 11:25pm, Kamil Rytarowski wrote: } } We started to build and ship kernel modules through pkgsrc. This is a really good thing and is part of the reason why modules exist. } I would like to reserve 3 major numbers for the HAXM case from the base } pool of devices and prevent potential future conflicts and compatibility } breakage due to picking up another major number in a 3rd party software. } } Where and how to reserve these major numbers? The ideal thing is to not reserve numbers at all and have them allocated dynamically. This requires the module reporting the number that was allocated to userland somehow. However, the only thing that is coming to mind off the top of my head is printf(9) which would normally land in /var/log/messages. This is obviously not very convenient. Does anybody else have thoughts on this? Maybe we need to extend modctl(MODCTL_LOAD, ...) to be able to return information from the loaded module? Of course, the real ideal thing would be to get a devfs and get rid of the concept of major numbers. Here I go again, starting contriversies. :-> }-- End of excerpt from Kamil Rytarowski
Re: Reserve device major numbers for pkgsrc
On Sat, Feb 16, 2019 at 11:25:36PM +0100, Kamil Rytarowski wrote: > We started to build and ship kernel modules through pkgsrc. We did a long time ago, sort of... > I would like to reserve 3 major numbers for the HAXM case from the base > pool of devices and prevent potential future conflicts and compatibility > breakage due to picking up another major number in a 3rd party software. > > Where and how to reserve these major numbers? > > I expect that we will start growing software that uses our kernel module > framework. (I have got few candidates to get ported in future) > Some history from AFS/OpenAFS/Arla: Our base system reserves a syscall number (210) for the AFS syscall, which is used either by the OpenAFS kernel module, or the Arla nnpfs kernel module. (Neither of these modules are currently functional with modern NetBSD.) Arla nnpfs additionally used a character device major, which it IIRC allocated dynamically at module load time, which was then somehow conveyed to userland to mknod the necessary device special before starting arlad. I'd suggest similar for this: allocate a MI range of character and block majors for quasi-external use, and then make registrations for your needs. Jonathan Kollasch P.S. Maybe reserve the first character major in the block for nnpfs as a sort of monument to Arla (which is pretty much abandoned these days).
Re: Reserve device major numbers for pkgsrc
New version. http://netbsd.org/~kamil/patch-00086-pkgsrc-majors.2.txt I have no preference on preallocation and selection of numbers. On 17.02.2019 00:12, Jaromír Doleček wrote: > Perhaps do not pre-reserve anything and simply reserve consecutive > numbers as the need arises? > > Le sam. 16 févr. 2019 à 23:55, Kamil Rytarowski a écrit : >> >> On 16.02.2019 23:40, Jaromír Doleček wrote: >>> Le sam. 16 févr. 2019 à 23:24, Kamil Rytarowski a écrit : We started to build and ship kernel modules through pkgsrc. I would like to reserve 3 major numbers for the HAXM case from the base pool of devices and prevent potential future conflicts and compatibility breakage due to picking up another major number in a 3rd party software. Where and how to reserve these major numbers? I expect that we will start growing software that uses our kernel module framework. (I have got few candidates to get ported in future) >>> >>> See sys/conf/majors >>> >>> Jaromir >>> >> >> Proposed patch: >> >> http://netbsd.org/~kamil/patch-00086-pkgsrc-majors.txt >> >> I have no opinion on numbers to pick, please suggest the right ranges >> and I will follow it. >> signature.asc Description: OpenPGP digital signature
Re: Reserve device major numbers for pkgsrc
Perhaps do not pre-reserve anything and simply reserve consecutive numbers as the need arises? Le sam. 16 févr. 2019 à 23:55, Kamil Rytarowski a écrit : > > On 16.02.2019 23:40, Jaromír Doleček wrote: > > Le sam. 16 févr. 2019 à 23:24, Kamil Rytarowski a écrit : > >> > >> We started to build and ship kernel modules through pkgsrc. > >> > >> I would like to reserve 3 major numbers for the HAXM case from the base > >> pool of devices and prevent potential future conflicts and compatibility > >> breakage due to picking up another major number in a 3rd party software. > >> > >> Where and how to reserve these major numbers? > >> > >> I expect that we will start growing software that uses our kernel module > >> framework. (I have got few candidates to get ported in future) > > > > See sys/conf/majors > > > > Jaromir > > > > Proposed patch: > > http://netbsd.org/~kamil/patch-00086-pkgsrc-majors.txt > > I have no opinion on numbers to pick, please suggest the right ranges > and I will follow it. >
Re: Reserve device major numbers for pkgsrc
On 16.02.2019 23:40, Jaromír Doleček wrote: > Le sam. 16 févr. 2019 à 23:24, Kamil Rytarowski a écrit : >> >> We started to build and ship kernel modules through pkgsrc. >> >> I would like to reserve 3 major numbers for the HAXM case from the base >> pool of devices and prevent potential future conflicts and compatibility >> breakage due to picking up another major number in a 3rd party software. >> >> Where and how to reserve these major numbers? >> >> I expect that we will start growing software that uses our kernel module >> framework. (I have got few candidates to get ported in future) > > See sys/conf/majors > > Jaromir > Proposed patch: http://netbsd.org/~kamil/patch-00086-pkgsrc-majors.txt I have no opinion on numbers to pick, please suggest the right ranges and I will follow it. signature.asc Description: OpenPGP digital signature
Re: Reserve device major numbers for pkgsrc
Le sam. 16 févr. 2019 à 23:24, Kamil Rytarowski a écrit : > > We started to build and ship kernel modules through pkgsrc. > > I would like to reserve 3 major numbers for the HAXM case from the base > pool of devices and prevent potential future conflicts and compatibility > breakage due to picking up another major number in a 3rd party software. > > Where and how to reserve these major numbers? > > I expect that we will start growing software that uses our kernel module > framework. (I have got few candidates to get ported in future) See sys/conf/majors Jaromir
