Re: xxxVERBOSE module?
On Sat, May 22, 2010 at 08:29:22PM -0700, Paul Goyette wrote:
attempt to load from the filesystem. I expected it to fail, but the
failure mode is rather ungraceful
Maybe this would help?
Index: vfs_lookup.c
===
RCS file: /cvsroot/src/sys/kern/vfs_lookup.c,v
retrieving revision 1.121
diff -u -r1.121 vfs_lookup.c
--- vfs_lookup.c8 Jan 2010 11:35:10 - 1.121
+++ vfs_lookup.c23 May 2010 09:43:18 -
@@ -340,6 +340,11 @@
* Get root directory for the translation.
*/
cwdi = self-l_proc-p_cwdi;
+ if (__predict_false(cwdi == NULL)) {
+ PNBUF_PUT(cnp-cn_pnbuf);
+ ndp-ni_vp = NULL;
+ return ENONENT;
+ }
rw_enter(cwdi-cwdi_lock, RW_READER);
state-namei_startdir = cwdi-cwdi_rdir;
if (state-namei_startdir == NULL)
Or actually move that test up a few lines and use the existing if (error) exit.
Martin
Re: xxxVERBOSE module?
On Sat, 22 May 2010, John Nemeth wrote:
} (referring to loading the pciverbose module...)
} I guess I can probably remove those changes. So we'll have to rely on
Although, you can't test them, possibly keep them. We do want to
support hotswap PCI at some point.
It turns out that I need to keep them after all! Without an explicit
load, the modules don't get initalized until much later in system
startup, and this module beomces rather useless. :)
There is still one problem, though. As you (John) pointed out earlier,
we don't have any accessible filesystems from which to load modules.
But unfortunately, the kern_module subsystem doesn't seem to realize
this. So, if the pci code requests the module to be loaded, and the
module is neither built-in nor provided by the boot loader, it _will_
attempt to load from the filesystem. I expected it to fail, but the
failure mode is rather ungraceful - the kernel panics with backtrace
_atomic_inc_32
namei + x109
vn_open + x84
kobj_load_vfs + x82
module_load_vfs + x2cf
module_do_load + 3e9
module_load + x68
It would seem to me that somewhere in this mess we should simply return
ENOENT (or some other appropriate errno).
Also, dyoung@ is in the process of
merging cardbus into PCI. I don't know if your changes would cause
mod_verbose to be autoloaded for cardbus, which uses PCIVERBOSE, but
cardbus insertion should be handled at some point. And, of course,
there is PCIe and expresscard on the horizon. expresscard is basically
hotswap PCIe along with USB (i.e. an expresscard slot brings out
signals for both and the card determines which one it is going to
use).
Both of these will be reasonable. I've already updated all the cardbus
references to the pci_find{vendor,product} routines, so it would be a
simple matter of making the pciverbose module gets (re)loaded.
What about X? What does it use for scanning the PCI bus?
I suspect it uses libpci - I'll be doing a full-tree search for libpci
shortly.
-
| 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
Re: xxxVERBOSE module?
Am 20.05.10 05:52, schrieb Paul Goyette: 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 be loaded during start-up time and then unloaded after the machine is up 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? To my understanding most of the VERBOSE options are compile-time switches which are used to conditionally compile debug code using #ifdefs. I am not sure how such a module should work then, changing #ifdef'ed code into code that is always compiled, but only used under certain circumstances?
Re: xxxVERBOSE module?
On Thu, May 20, 2010 at 08:13:15AM +0200, Marc Balmer wrote: To my understanding most of the VERBOSE options are compile-time switches which are used to conditionally compile debug code using #ifdefs. I am not sure how such a module should work then, changing #ifdef'ed code into code that is always compiled, but only used under certain circumstances? No, this was about PCIVERBOSE, USBVERBOSE and SCSIVERBOSE, which adds in the kernel table of strings for vendor/device names, extended error codes, etc ... -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: xxxVERBOSE module?
On Thu, 20 May 2010, Manuel Bouyer wrote: On Thu, May 20, 2010 at 08:13:15AM +0200, Marc Balmer wrote: To my understanding most of the VERBOSE options are compile-time switches which are used to conditionally compile debug code using #ifdefs. I am not sure how such a module should work then, changing #ifdef'ed code into code that is always compiled, but only used under certain circumstances? No, this was about PCIVERBOSE, USBVERBOSE and SCSIVERBOSE, which adds in the kernel table of strings for vendor/device names, extended error codes, etc ... Correct - that was my intention. - | 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?
Am 20.05.10 11:12, schrieb Manuel Bouyer: On Thu, May 20, 2010 at 08:13:15AM +0200, Marc Balmer wrote: To my understanding most of the VERBOSE options are compile-time switches which are used to conditionally compile debug code using #ifdefs. I am not sure how such a module should work then, changing #ifdef'ed code into code that is always compiled, but only used under certain circumstances? No, this was about PCIVERBOSE, USBVERBOSE and SCSIVERBOSE, which adds in the kernel table of strings for vendor/device names, extended error codes, etc ... Ah, I see. Well, the this addition makes sense, for sure ;)
Re: xxxVERBOSE module?
On Thu, 20 May 2010, David Young wrote: On Wed, May 19, 2010 at 08:52:52PM -0700, 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 be loaded during start-up time and then unloaded after the machine is up 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, it would be. ... Kewl - I plan on starting with PCIVERBOSE, followed closely with USB. ... Just an idea: we may get a lot of mileage out of a generic method for adding or augmenting, and removing kernel property lists from a kernel, either at run- or compile-time. Consider that much of the VERBOSE info is in tabular form, thus expressible by property list. So are PCI/USB/... vendor/product tables that we use to match drivers with devices---I wish we could change those tables without recompiling. I anticipate using property lists to express device locators. So it seems to me that linking property lists into the kernel could be very useful. Great idea, but I think I'll save that for a future time when I have a bit more free time! - | 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 | -
xxxVERBOSE module?
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 be loaded during start-up time and then unloaded after the machine is up 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? - | 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 | -
