Re: Unexpected kernel device dependency for 'vga* at pci?'
Thanks for the explanation. It would seem to me that the vga console code should be separated from the rest of the vga driver. Then it would be rather easy to include the console code whenever vga or radeon or the Intel equivalent is configured. I've also noticed that even though no genfb is included in my config file, the generated file genfb.h sets NGENFB = 1, while the vga.h file contains NVGA = 0. Some how, this feels like a hack, in order to avoid making a similar split (console vs non-console) in the genfb code. Any way, thanks for all of the extra eyes looking at this, and all the explanations. At least now I know why I need the vga driver, even if I'd prefer to omit it. On Sun, 10 Jul 2016, Michael van Elst wrote: k...@munnari.oz.au (Robert Elz) writes: | While doing this, I've discovered that a radeondrmkmsfb0-based kernel | requires that I retain the | vga* at pci? dev ? func ? | line in the configuration, even though no such device is ever attached. The VGA driver is used very early as a console, this happens before autoconf and before the driver is really attached. For this you only need the VGA driver included in the kernel. The kernel would panic without the vga driver on conventional hardware, but there is a bug in the code. If the VGA driver is included, the radeon code will detach and reattach it as a console. When the VGA driver is not included, nothing like that happens, and the VGA hardware probably isn't mapped anywhere. In my (intel, not radeon) driver I detach the VGA console #if NVGA > 0 iaa.iaa_console = vga_cndetach() ? true : false; #else iaa.iaa_console = false; #endif and then map the hardware and attach a wsdisplay as if no VGA driver had existed. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree." !DSPAM:578273e731621319712218! +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: Unexpected kernel device dependency for 'vga* at pci?'
k...@munnari.oz.au (Robert Elz) writes: >And as I (kind of said) I never actually tried a config with the "vga* at pci?" >config included but the wsdisplay* at vga? console ?" omitted, it was both >or neither for me (just the way it worked out.) Initially VGA gets attached as console. This has nothing to do with the config file. It's in the MD consinit() code. This also attaches an initial wsdisplay screen. Later VGA may attach at PCI. This provides the regular attachment and takes over the initial console screen. Later VGA may attach at ISA. This fails if there is already a PCI attachment because the hardware is already mapped and cannot be mapped again. If there is a radeon driver, it will take priority over the PCI attachment. No VGA attaches here but VGA is still the console. Then it gets a bit kludgy -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Unexpected kernel device dependency for 'vga* at pci?'
k...@munnari.oz.au (Robert Elz) writes: > | While doing this, I've discovered that a radeondrmkmsfb0-based kernel > | requires that I retain the > |vga* at pci? dev ? func ? > | line in the configuration, even though no such device is ever attached. The VGA driver is used very early as a console, this happens before autoconf and before the driver is really attached. For this you only need the VGA driver included in the kernel. The kernel would panic without the vga driver on conventional hardware, but there is a bug in the code. If the VGA driver is included, the radeon code will detach and reattach it as a console. When the VGA driver is not included, nothing like that happens, and the VGA hardware probably isn't mapped anywhere. In my (intel, not radeon) driver I detach the VGA console #if NVGA > 0 iaa.iaa_console = vga_cndetach() ? true : false; #else iaa.iaa_console = false; #endif and then map the hardware and attach a wsdisplay as if no VGA driver had existed. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Potentially undesirable behavior with apropos(1)
On Sun, Jul 10, 2016 at 4:05 PM, thilo jeremiaswrote: > The man page is clear: > > -k Search man pages for keyword(s), in the same manner as > apropos(1). If you want old apropos, there is -l option or set environment variable APROPOS and use man -k. :) > And doing > -bash-4.3$ man -k re | wc > 1515 22761 148437 > -bash-4.3$ > > is meaning less. It's not meaning less. The first result is re(4), which is probably what you are looking for. Just 're' as a query is hard to guess for apropos, it might mean the hardware driver, or regular expression, or re-initialize, re-sample, re-map etc., and that's why you see so many results. I encourage you to compare `apropos -l re` and `apropos re` and decide which output is more useful :) Here is what I see: $ apropos -n 10 -M re re (4)RealTek 8139C+/8169/8169S/8168/8110S/8111 PCI Ethernet adapter driver FcInitReinitialize (3)re-initialize library mremap (2)re-map a virtual memory address refuse (3)Re-implementation of a file system in userspace system magick (1)convert between image formats as well as resize an image, blur, crop, despeckle, dither, draw on, flip, join, re-sample, and much more. convert (1) convert between image formats as well as resize an image, blur, crop, despeckle, dither, draw on, flip, join, re-sample, and much more. magick-script (1) scripting language that converts between image formats as well as resize an image, blur, crop, despeckle, dither, draw on, flip, join, re-sample, and much more. mogrify (1) resize an image, blur, crop, despeckle, dither, draw on, flip, join, re-sample, and much more. Mogrify overwrites the original image file, whereas, convert(1) writes to a different image file. chpass (1)add or change user database information awi (4) AMD PCnetMobile IEEE 802.11 PCMCIA wireless network driver $ apropos -n 20 -M -l re #old apropos output winfo(n) - Return window-related information ttk::treeview(n) - hierarchical multicolumn data display widget ttk::sizegrip(n) - Bottom-right corner resize widget ttk::scale(n) - Create and manipulate a scale widget ttk::progressbar(n) - Provide progress feedback ttk::menubutton(n) - Widget that pops down a menu when pressed ttk::button(n) - Widget that issues a command when pressed toplevel(n) - Create and manipulate 'toplevel' main and popup window widgets tk_optionMenu(n) - Create an option menubutton and its menu tk_messageBox(n) - pops up a message window and waits for user response. tk_focusNext(n) - Utility procedures for managing the input focus. tk_dialog(n) - Create modal dialog and wait for response tk_chooseDirectory(n) - pops up a dialog box for the user to select a directory. text(n) - Create and manipulate 'text' hypertext editing widgets spinbox(n) - Create and manipulate 'spinbox' value spinner widgets send(n) - Execute a command in a different application scrollbar(n) - Create and manipulate 'scrollbar' scrolling control and indicator widgets scale(n) - Create and manipulate 'scale' value-controlled slider widgets safe::loadTk(n) - Load Tk into a safe interpreter. radiobutton(n) - Create and manipulate 'radiobutton' pick-one widgets With the new apropos(1), most of the times you would find the result you were searching for in the top, there will be some unrelated results also in the mix, but you can just ignore them. :) > > I just wonder how can I search for the cryptic keywords I used to be able to > find. Could you give few examples of such keywords where you don't see the expected result in the top, and it might help me to improve apropos :) > > I agree stemming and full text search is a nice feature, but just a feature. > > Giving the user the option would be democratic. > :-) > > I just got used to use man -k in the last 25 years, and it would be a > unexpected change. It is understandable, you can use `apropos -l` if you preferred the classic version :) - Abhinav