Re: Finding the slot in the ioconf table a module attaches to?
hello. Following up on my own post, I found the mechanism by which the
cdevsw structure
gets tied to the ioconf table in NetBSD-5. It's done with:
MOD_DEV("zaptel", "zaptel", NULL, -1, &zaptel_cdevsw, ZT_MAJOR)
This macro has been removed from the new module framework. Can someone point
me in the correct
direction as to where to look for the replacement function for this macro with
the new module
framework?
I'm not finding it and it seems like it should be simple.
-thanks
-Brian
Re: Finding the slot in the ioconf table a module attaches to?
On Wed, 1 Feb 2023, Brian Buhrow wrote:
hello. Following up on my own post, I found the mechanism by which the
cdevsw structure
gets tied to the ioconf table in NetBSD-5. It's done with:
MOD_DEV("zaptel", "zaptel", NULL, -1, &zaptel_cdevsw, ZT_MAJOR)
This macro has been removed from the new module framework. Can someone point
me in the correct
direction as to where to look for the replacement function for this macro with
the new module
framework?
These should help you:
/usr/src/sys/modules/examples/readhappy/readhappy.c
/usr/src/sys/conf/majors*
-RVP
Re: Finding the slot in the ioconf table a module attaches to?
On Wed, Feb 01, 2023 at 08:28:35 +, RVP wrote: > /usr/src/sys/modules/examples/readhappy/readhappy.c > /usr/src/sys/conf/majors* Hmm, lots of real modules seems to use config_init_component() that is not documented at all in the section 9. Can someone please write a man page for that? I'll help with mdoc if troff incantations make you anxious :) -uwe
Re: Finding the slot in the ioconf table a module attaches to?
RVP writes:
> On Wed, 1 Feb 2023, Brian Buhrow wrote:
>
>> hello. Following up on my own post, I found the mechanism by which the
>> cdevsw structure
>> gets tied to the ioconf table in NetBSD-5. It's done with:
>>
>>
>> MOD_DEV("zaptel", "zaptel", NULL, -1, &zaptel_cdevsw, ZT_MAJOR)
>>
>> This macro has been removed from the new module framework. Can someone
>> point me in the correct
>> direction as to where to look for the replacement function for this macro
>> with the new module
>> framework?
>>
>
> These should help you:
>
> /usr/src/sys/modules/examples/readhappy/readhappy.c
> /usr/src/sys/conf/majors*
>
> -RVP
To add a bit... generally I have just added an entry to one of the
"major" files in sys/conf. However, I have noticed that in order for
the module to be able to use it, after the major file edit, I had to
rebuild the kernel as well. I have never been 100% sure that was proper
behavior, but it seems to be the case. That is, just editing the major
file and building or rebuilding the module has not been enough.
--
Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: Finding the slot in the ioconf table a module attaches to?
On Wed, Feb 01, 2023 at 08:27:57 -0500, Brad Spencer wrote: > To add a bit... generally I have just added an entry to one of the > "major" files in sys/conf. However, I have noticed that in order for > the module to be able to use it, after the major file edit, I had to > rebuild the kernel as well. I have never been 100% sure that was proper > behavior, but it seems to be the case. That is, just editing the major > file and building or rebuilding the module has not been enough. .Xr devsw_attach 9 Major numbers (mapping "foo" -> 42, so that a program that opens a node with major 42 gets to the device "foo") are a property of the kernel config, so yes, you need to rebuild the kernel when you introduce a new fixed major number. When the module is loaded, the driver tells the kernel, "I'm `foo'". It can also tell the kernel either "I'm ok with whatever major number you give me", or it can tell "I want a specific major number N". It's an error to request a specific major N that is already taken (either fixed in a major config file, or dynamically allocated to another driver). -uwe
Re: Finding the slot in the ioconf table a module attaches to?
hello Brad. I thought the idea behind modules was that you didn't need to rebuild a kernel to add devices to the ioconf table? And, in fact, under the old module framework, that is, NetBSD-5 and earlier, you could add devices and major numbers to the table without having to rebuild the kernel. If, in fact, I need to rebuild the kernel to add device drivers to the kernel, then I submit our module framework is fatally broken. So, I'll hope that isn't the case and proceed. If I figure out how to do it, I'll post here so others won't have to climb that learning curve using the same path. -thanks -Brian
Re: Finding the slot in the ioconf table a module attaches to?
Usually your user program would attempt to open xyz0 which would find the major/minor in th devsw tables. You're relying on a hard coded major. That's the difference. If you take the first approach and your module uses the config_init_component() method to install the driver, it will do what you want. On the other hand, hard-coding the major requires rebuilding the kernel to get the major-->name mapping. Is there a reaason your user program needs to open-by-major? On Wed, 1 Feb 2023, Brian Buhrow wrote: hello Brad. I thought the idea behind modules was that you didn't need to rebuild a kernel to add devices to the ioconf table? And, in fact, under the old module framework, that is, NetBSD-5 and earlier, you could add devices and major numbers to the table without having to rebuild the kernel. If, in fact, I need to rebuild the kernel to add device drivers to the kernel, then I submit our module framework is fatally broken. So, I'll hope that isn't the case and proceed. If I figure out how to do it, I'll post here so others won't have to climb that learning curve using the same path. -thanks -Brian !DSPAM:63da9667288221001310414! ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Finding the slot in the ioconf table a module attaches to?
> Usually your user program would attempt to open xyz0 which would find > the major/minor in th devsw tables. You're relying on a hard coded > major. That's the difference. Okay, I'm probably exposing my ignorance of something here, but, what's the difference? You still have to get the major number, whether chosen at module load time or chosen at kernel build time, into the /dev/xyz0 special file in the filesystem. That requires exfiltrating it from the kernel *somehow* /~\ 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: Finding the slot in the ioconf table a module attaches to?
hello. Mouse's question is the same as mine. It's fine to have a dynamically assigned major number for the module, but since we don't have a dynamic /dev, that number needs to be static enough so that devices can be created in the /dev tree. The idea that one can request a prefered major number from the kernel in the module itself partially mitigates this issue in the sense that one can be pretty confident that one will get the same number when ever the system boots on a given system, but it does mean that a kernel update or new device driver statically linked into the kernel, or if the ordering of the module load changes, the major device number assigned to a given module and the number on the node in the /dev tree can get out of sync. It looks like the devpubd(8) program partially solves this problem, at least for the installation of a new module. It can be configured, in conjunction with modifications to the /dev/MAKEDEV script, to create new device nodes. However, as currently implemented, devpubd doesn't pass the major number to the MAKEDEV script. So, the MAKEDEV script would need to have some intelligence about how to get the major number from the kernel, probably by reading a sysctl variable. Also, it doesn't look like the devpubd program currently deletes any devices from the /dev tree. 'This is a problem since if the major number changes, the MAKEDEV script, as currently implemented and as devpubd currently calls it, won't modify an existing device in the /dev tree. Having said that, it looks like the easiest way to make this problem better is to extend the functionality of the devpubd program to allow it to dynamically add and delete devices from the /dev tree and to provide a standardized mechanism for extracting the major number from the kernel and passing it to the MAKEDEV script. -thanks -Brian
Re: Finding the slot in the ioconf table a module attaches to?
Brian Buhrow writes: > hello Brad. I thought the idea behind modules was that you didn't need > to rebuild a > kernel to add devices to the ioconf table? And, in fact, under the old > module framework, that > is, NetBSD-5 and earlier, you could add devices and major numbers to the > table without having > to rebuild the kernel. If, in fact, I need to rebuild the kernel to add > device drivers to the > kernel, then I submit our module framework is fatally broken. So, I'll hope > that isn't the > case and proceed. If I figure out how to do it, I'll post here so others > won't have to climb > that learning curve using the same path. > -thanks > -Brian My general experience seems to be that a recompile of the kernel is needed, at least when used in the manor I used it (adding a new module that used a static major number in one of the major files). I was bundling a module that would be added to src anyway, so the recompile wasn't a notable problem. The devsw_attach(9) man page implies that the major and minor number can be selected with that call, but I have never used it that way. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
Re: Finding the slot in the ioconf table a module attaches to?
On Wed, Feb 1, 2023 at 10:42 Brad Spencer wrote: > Brian Buhrow writes: > > > hello Brad. I thought the idea behind modules was that you didn't > need to rebuild a > > kernel to add devices to the ioconf table? And, in fact, under the old > module framework, that > > is, NetBSD-5 and earlier, you could add devices and major numbers to the > table without having > > to rebuild the kernel. If, in fact, I need to rebuild the kernel to add > device drivers to the > > kernel, then I submit our module framework is fatally broken. So, I'll > hope that isn't the > > case and proceed. If I figure out how to do it, I'll post here so > others won't have to climb > > that learning curve using the same path. > > -thanks > > -Brian OT: dh@ and I had a discussion (on-list here and in #netbsd-code iirc) surrounding these sorts of issues some time (~2 years?) ago and I believe he got excited/disappointed enough that he suggested he might write-up some thoughts on modules and NetBSD, incl (if this helps dh@ find the paper, or otherwise chime in) why block vs character distinction is unnecessary, and a mistake. Dave? -bch > > > My general experience seems to be that a recompile of the kernel is > needed, at least when used in the manor I used it (adding a new module > that used a static major number in one of the major files). I was > bundling a module that would be added to src anyway, so the recompile > wasn't a notable problem. The devsw_attach(9) man page implies that the > major and minor number can be selected with that call, but I have never > used it that way. > > > -- > Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org >
Re: Finding the slot in the ioconf table a module attaches to?
hello. Okay. That is helpful. Passing -1 in as the cmajor number to the devsw_attach() function does, in fact, assign a reasonable major number which seems to work. I use the cdevsw_lookup_major() function to retrieve the assigned number and print it for the user. So, thankfully, things aren't as broken as I momentarily feared. -thanks -Brian
Re: Finding the slot in the ioconf table a module attaches to?
On Wed, Feb 01, 2023 at 11:14:42 -0800, Brian Buhrow wrote:
> hello. Okay. That is helpful. Passing -1 in as the cmajor
> number to the devsw_attach() function does, in fact, assign a
> reasonable major number which seems to work. I use the
> cdevsw_lookup_major() function to retrieve the assigned number and
> print it for the user.
devsw_attach updates &cmajor with the assigned number if you passed
NODEVMAJOR (-1) in it, so you don't even need to look it up
separately. We also have in-kernel convenience "MAKEDEV".
E.g., paraphrasing a bit, vbox guest additions module does:
bmajor = cmajor = NODEVMAJOR;
error = devsw_attach("vboxguest", NULL, &bmajor,
&vboxguest_cdevsw, &cmajor);
if (error)
...
error = do_sys_mknod(curlwp, "/dev/vboxguest",
S_IFCHR | 0666, makedev(cmajor, 0),
&retval, UIO_SYSSPACE);
if (error == EEXIST) {
error = 0;
/*
* Since NetBSD doesn't yet have a major reserved for
* vboxguest, the (first free) major we get will
* change when new devices are added, so an existing
* /dev/vboxguest may now point to some other device,
* creating confusion (tripped me up a few times).
*/
aprint_normal("vboxguest: major %d:"
" check existing /dev/vboxguest\n", cmajor);
}
(The comment is no longer true, as we do have a reserved major for vbox now).
-uwe
devsw_detach is failing -- is this a manifestation of PR kern/56962?
Hello. I've found that after I perform a modunload on the module I'm working on, I cannot then modload the module because devsw_attach fails to attach the same module again. And, yes, the module calls devsw_detach before it unloads. I'm runing NetBSD-9.99.77, which predates the pr kern/56962 fixes. Is this behavior expected prior to the fix for this bug or am I running into something else? -thanks -Brian
