Re: Adding mouse sensitivity adjustment to wsmouse
Am 21.05.10 01:45, schrieb Sverre Froyen: [...] It appears that xorg provides acceleration support only (xinput set-ptr- feedback). As you suggested, changing xorg.conf allows configuring the two mouse inputs separately, so adding scaling support to xorg would solve my problem. Finally, it looks like moused(8) provides linear scaling support. I have not yet tested it, however. I think then we should go that way. As I said, I already contacted the author. Once we knowit works that way, we can indeed clean up wsmouse a bit. As soon as I get a reply I will post it here. - Marc
Re: PAT support
On Thu, May 20, 2010 at 07:54:46AM +0200, Christoph Egger wrote: The combined effect of MTRR and PAT memory types: PAT memory type MTRR memory typeeffective memory type UC UC, WC, WP, WT, WB UC UC- UC UC UC- WC WC UC- WP, WT, WB UC WC — WC WP UC UC WP WC UC WP WP WP WP WT UC WP WB WP WT UC UC WT WC, WP UC WT WT, WB WT WB UC UC WB WC WC WB WP WP WB WT WT WB WB WB ISTM that the effective memory type (EMT), not the PAT memory type, should be controlled by pmap(9). MTRR and PAT should be consistent, and no single physical page should be mapped once with one EMT and a second time with an inconsistent EMT. On 20.05.10 01:15, David Young wrote: Are some memory types more suitable for a DMA buffer than others? For MMIO you can use either Uncachable, Uncacheable Minus or Write-Combine. Ok. What about DMA buffers? Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Kernel modules - documentation?
Is there any documentation on the modules interface or API? There does not seem to be anything in the man pages... My specific questions: What actually triggers an autoload of a module? (There seem to be very few places where module_autoload() is called.) What is the semantic difference between module_autoload() and a normal module_load()? Does the code which calls either of these routines need to be concerned with whether the module has been previously loaded? Is it OK to load a module that has already been loaded? Given that there is a kernel thread that runs around and attempts to unload any unreferenced modules that have been loaded for a while, is it ever necessary or desirable to explicitly unload a module? What happens if a global symbol referenced by a module doesn't exist? Does the module get loaded anyway, leaving the reference unresolved? Thanks in advance! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: Kernel modules - documentation?
On May,Friday 21 2010, at 3:04 PM, Paul Goyette wrote: Is there any documentation on the modules interface or API? There does not seem to be anything in the man pages... My specific questions: What actually triggers an autoload of a module? (There seem to be very few places where module_autoload() is called.) Device module_autoloading is done in specfs_open. What is the semantic difference between module_autoload() and a normal module_load()? module_autoload happens automatically when you try to open device node which doesn't have device driver in kernel. Does the code which calls either of these routines need to be concerned with whether the module has been previously loaded? Is it OK to load a module that has already been loaded? I think that this is not possible and these routines return an error when you try to do that. Given that there is a kernel thread that runs around and attempts to unload any unreferenced modules that have been loaded for a while, is it ever necessary or desirable to explicitly unload a module? It doesn't work this way there is a thread(workqueue) which try to unload module in first 300 seconds or mili seconds I can't remember now. But this thread or whatever is it doesn't unload modules older that set limit AFAIK. What happens if a global symbol referenced by a module doesn't exist? Does the module get loaded anyway, leaving the reference unresolved? If you have a module which uses foo routine and it is not defined in kernel or loaded modules your module will simply not load. Thanks in advance! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | - Regards Adam.
Re: Kernel modules - documentation?
On Sat, 22 May 2010, Adam Hamsik wrote: My specific questions: What actually triggers an autoload of a module? (There seem to be very few places where module_autoload() is called.) Device module_autoloading is done in specfs_open. OK. So I guess there's no generic Gee, the kernel just tried to reference something that's not here, so maybe we can find a module to resolve that reference. What is the semantic difference between module_autoload() and a normal module_load()? module_autoload happens automatically when you try to open device node which doesn't have device driver in kernel. My question was more along the lines of what is the _difference_ between module_load() vs module_autoload()? Or even simpler, Why do both routines exist? :) Does the code which calls either of these routines need to be concerned with whether the module has been previously loaded? Is it OK to load a module that has already been loaded? I think that this is not possible and these routines return an error when you try to do that. That's OK, I'd expect the error. I can ignore that. I just need to be sure that the previously-loaded module doesn't get screwed up from the attempt to load it the second time. Given that there is a kernel thread that runs around and attempts to unload any unreferenced modules that have been loaded for a while, is it ever necessary or desirable to explicitly unload a module? It doesn't work this way there is a thread(workqueue) which try to unload module in first 300 seconds or mili seconds I can't remember now. But this thread or whatever is it doesn't unload modules older that set limit AFAIK. Hmmm, I must have misunderstood this code - time to go look again. What happens if a global symbol referenced by a module doesn't exist? Does the module get loaded anyway, leaving the reference unresolved? If you have a module which uses foo routine and it is not defined in kernel or loaded modules your module will simply not load. This is actually what I was hoping would happen. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: xxxVERBOSE module?
On Sep 4, 9:00am, Paul Goyette wrote: } } From the comments in the GENERIC config files, the primary reason for } omitting the various xxxVERBOSE options is to avoid including large text } tables in the resulting kernel. And I vaguely recall some spirited } discussion back when the change was made to exclude these options by } default. } } Now that we have MODULAR kernels (at least on some architectures), I've } been wondering if it might make sense to create a mod_verbose that could There's been quite a bit of discussion about doing just this. } be loaded during start-up time and then unloaded after the machine is up It would have to be loaded by the boot loader then. As far as I know, only the x86 boot loader is capable of loading modules. } and running. (For plug-and-play situations, such as USB, the module } could be reloaded and unloaded whenever a new device is added.) } } Is this something that would be useful? Yes, I think it would be very useful. I was thinking of looking at this myself. Thanks for taking on this task. It's one thing I can cross off my TODO list. :-) }-- End of excerpt from Paul Goyette
Re: xxxVERBOSE module?
On Fri, 21 May 2010, John Nemeth wrote: } be loaded during start-up time and then unloaded after the machine is up It would have to be loaded by the boot loader then. As far as I know, only the x86 boot loader is capable of loading modules. I'm almost finished with the PCIVERBOSE stuff... My current approach is to load the module right before the first pcibus is enumerated, and unload when finished. So we can use the in-kernel loader/linker for whichever platforms it supports. For other platforms it will still be possible to set 'options PCIVERBOSE' to generate a built-in module. The fun part is making sure that the shared code still plays nicely with src/lib/libpci :) Yes, I think it would be very useful. I was thinking of looking at this myself. Thanks for taking on this task. It's one thing I can cross off my TODO list. :-) No worries! When I finish up with PCI, I'll start in on USB. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: xxxVERBOSE module?
On Fri, 21 May 2010, John Nemeth wrote: } My current approach is to load the module right before the first pcibus } is enumerated, and unload when finished. So we can use the in-kernel File systems aren't initialised during autoconf when the system is being cold booted, thus it isn't possible for the kernel to load a module at that point in time. Also consider that on most platforms with PCI, prior to the first pcibus being enumerated, the kernel doesn't know anything about any disk drives that may be attached to the system. Ah, yeah! Ooppss! :) I guess I can probably remove those changes. So we'll have to rely on either the module being built-in or established by the boot loader. } The fun part is making sure that the shared code still plays nicely with } src/lib/libpci :) I don't know anything about libpci, but have fun with that. The only thing I find that uses libpci is /usr/sbin/pcictl and that seems to be working fine. } No worries! When I finish up with PCI, I'll start in on USB. I imagine that will be mostly copy/paste. Mostly. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: xxxVERBOSE module?
On Sep 6, 9:11am, Paul Goyette wrote: } On Fri, 21 May 2010, John Nemeth wrote: } } } be loaded during start-up time and then unloaded after the machine is up } } It would have to be loaded by the boot loader then. As far as I } know, only the x86 boot loader is capable of loading modules. } } I'm almost finished with the PCIVERBOSE stuff... } } My current approach is to load the module right before the first pcibus } is enumerated, and unload when finished. So we can use the in-kernel File systems aren't initialised during autoconf when the system is being cold booted, thus it isn't possible for the kernel to load a module at that point in time. Also consider that on most platforms with PCI, prior to the first pcibus being enumerated, the kernel doesn't know anything about any disk drives that may be attached to the system. } loader/linker for whichever platforms it supports. For other platforms } it will still be possible to set 'options PCIVERBOSE' to generate a } built-in module. Sure, this is the way MODULEs are supposed to work. } The fun part is making sure that the shared code still plays nicely with } src/lib/libpci :) I don't know anything about libpci, but have fun with that. } Yes, I think it would be very useful. I was thinking of looking } at this myself. Thanks for taking on this task. It's one thing I can } cross off my TODO list. :-) } } No worries! When I finish up with PCI, I'll start in on USB. I imagine that will be mostly copy/paste. }-- End of excerpt from Paul Goyette
