On Wed, 15 Oct 2014 11:09:28 -0700, Don Y Gave us:
There is a *user interface* configuration one can run where exactly what you state is seen and controlled, but that is used just prior to and as a part of a new kernel compile
Make multiple kernels and boot via a menu the one you need.
One could even build sub-menus for each kernel selection.
I do not believe there is a comprehensive "boot element selection gui" screen thing yet.
It would be a great addition to say the "utility/rescue" boot selections which are out there. Grub2 should be able to handle.
OR "BURG", which I like better than grub.
Ubuntu's "F6" selection on their install/live discs has a few 'handy' items. But I know of nothing comprehensive, as it were. (as it should be).
(with a Jedi voice inflection/tone, and a horizontal hand wave)
"These are not the kernels you are looking for..."
On a sunny day (Sat, 18 Oct 2014 02:03:06 -0700) it happened DecadentLinuxUserNumeroUno wrote in :
It would be better if you were executed and your ashes burned an extra time in a volcano. Now go way and stay away, or come here and I will help you with that, but you wont you coward. Or you cannot, your an invalid mentally retarded cripple on a no-fly list, and you are Alwayswrong.
Probably not, he is gona write that few lines of code, but got delayed by having to build a glasshouse or something. Will wait, see what happens.
Since you have not published a line of code ever, neither written one, nor could you, I think it is safe to conclude that your opinion is as always:wrong.
A NetBSD driver tends to be architecture neutral. I.e., the code to talk to an 16550 doesn't care if that 16550 is in a PC, m68K apple, SPARctation, SGI Indy, etc. A 16550 is a 16550 regardless of where it exists.
Of course, *how* a 16550 is connected to an m68k *CPU* (chip) in an Apple is different than how it is attached to an UltraSPARC CPU or an x86/x64, etc.
And, even within a particular "architecture" (e.g., "PC"), a particular "device" may be "wired" to the CPU via an ISA bus, PCI bus, PCMCIA bus, etc.
So, when you configure a NetBSD kernel, you indicate *how* the various devices are "wired" into the system. You can trace the flow of data/control through the hierarchy of "devices" detected by the kernel.
Some excerpts from a kernel's configuration file to illustrate:
at {}
'#' can be a small integer to indicate a particular instance of a particular . Or, can be a wildcard to allow "next available instance" to be assigned. Same sorts of rules apply to s
acpi0 at mainbus0 isa0 at mainbus?
mainbus0 is *effectively* the top level in the hierarchy (hand-waving, here). Think of it as "pins of the CPU *chip*. The first line indicates POTENTIAL to support the 0th instance of the "acpi" device ATTACHED to the 0th instance of the mainbus device. The second line indicates the potential to support the 0th instance of the "isa" device on any mainbus instance.
pci* at mainbus? bus ?
Any number of "pci" devices (this is misleading. a "pci" device is a *bus*!) can attach to any mainbus instance.
pchb* at pci? dev ? function ? pcib* at pci? dev ? function ? ppb* at pci? dev ? function ?
Any number of "pchb" (PCI-Host bridges) devices can attach to any "pci" instance. Ditto for "pcib" (PCI-ISA bridges) and "ppb" (PCI-PCI bridges).
pci* at pchb? bus ?
Any number of "pci" devices can attach to any "pchb" instance. (!)
pci* at ppb? bus ?
Any number of "pci" devices can attach to any "ppb" instance.
isa0 at pcib?
The zero'th instance of an "isa" device (remember, this is a BUS not a particular "chip" *on* the ISA bus)
I.e., we now have lots of different ways to "attach" pci buses to a CPU (mainbus) -- directly or indirectly. And, ways to attach bridges that support other "buses".
You should be able to see how this idea extends to support, for example, a standard "com port" that can be attached to the CPU (ultimately) in a variety of different ways:
cbb* at pci? dev ? function ? cardslot* at cbb?
cardbus* at cardslot? pcmcia* at cardslot?
com* at pcmcia? function ? pcmcom* at pcmcia? function ?
com* at pcmcom? slave ? com* at cardbus? function ? # Modems and serial cards com* at acpi? # Serial communications
com0 at isa? port 0x3f8 irq 4 # Standard PC serial ports com1 at isa? port 0x2f8 irq 3
xirc* at pcmcia? function ? # Xircom CreditCard Ethernet com* at xirc?
mhzc* at pcmcia? function ? # Megahertz Ethernet/Modem com* at mhzc?
So, you don't just indicate that you want the "com" driver present in the kernel but *where* you are willing to allow it to attach to the system (and, ultimately, the CPU). E.g., if you remove the "com* at xirc?" line from the configuration file, you can have standard serial ports ON THE ISA BUS (which is implemented by the "isa" device) supported by the "com" driver (because of those two "com0" and "com1" lines) and NOT attach the serial port ("com") that is present in the Xircom PCMCIA card!
[I.e., you might only want to support the ethernet NIC in that PCMCIA card. Note that the "device" for that NIC is not mentioned, here, but would attach to the "xirc?" device(s)]
NetBSD has the ability to individually enable/disable (and even adjust any "options" that were specified in a "device specification" in the kernel configuration file. But, it only is of use to tech-savvy users. Would you have guessed the meaning/purpose/role of the "mhzc" device without the commentary appearing above?
If you can't get the system to *boot*, then you can't read the man pages. Or, modify any configuration files. Etc.
I.e., the existing tool is really only useful to people who are intimately familiar with individual device names as well as the whole "autoconfig" system.
I want to be able to say:
- If you can't boot the CD, restart the system and select boot option 2 (which disables virtually every device except the display, keyboard, etc.)
- Once this works, type "dmesg" at a command prompt and note the device names that are listed as "not configured". (or, ideally, have a script extract those names automatically and stuff them in a "boot config file")
- Reboot the system with boot option 3 (which is the same as option 2 but also examines the "boot config file" to add those devices back into the live kernel)
- WHEN THIS DOESN'T WORK, return to option 2 and delete the *first* line in that "boot config file" (i.e., assume that line is the "problem" and don't allow it to be added back into the system).
- Again, reboot from option 3 and keep doing this until you can successfully boot the system AS YOU COULD IN OPTION 2. The "boot config file" now contains the devices that you can successfully add back into the stripped down kernel (option 2) so the line that is missing indicates the "problem"
[Of course, this isn't the *real* approach that would be taken. But, is meant to illustrate how you could allow a novice user to get a system up and running (option 2) but *beyond* "bare bones" configuration (that option 2 affords).]
It works "during" boot, depending upon your definition of "boot".
If the driver is built directly into the kernel, you either need to find some option implemented by that driver which will effectively disable it or build a new kernel without it.
But most mainstream distributions avoid building drivers into the kernel. Their kernels are designed to run on a wide variety of systems, and try to avoid wasting memory on drivers which will be unused on a non-trivial proportion of those systems.
At one time, kernels had to include the drivers for hardware needed during boot, e.g. ATA or SCSI disc controllers; if the driver for the disc controller is in a module stored on the filesystem, you'd have a chicken-and-egg problem.
This problem has since been eliminated by the use of "initrd" (initial RAM disc). This is a compressed image containing a read-only filesystem which is extracted into RAM. The filesystem contains any modules which may be required to progress the boot process to the point where the real filesystem can be mounted, the script(s) to control this process, and any programs and libraries which are needed.
After the kernel has finished initialising itself, it mounts the initrd filesystem and executes the init script, which loads the modules required by the specific hardware being used. After which, the initrd filesystem is unmounted, the real root filesystem (on disk) is mounted, and the real init daemon is started to handle the remainder of the boot sequence.
So if you want to control the loading of "early" drivers, you need to either look into the details of the initrd image being used, or replace it with your own image via the configuration file for your boot loader (LILO, GRUB, etc).
Drivers which aren't required before the real root filesystem is mounted will be stored on disc and controlled by the on-disc init scripts.
NetBSD already effectively has this -- just disable all but essential drivers (VGA, keyboard). But, this is contrary to the way the kernel tends to be invoked (i.e., "kitchen sink").
Neither the current NetBSD approach -- nor the Linux approaches that I've seen described -- are at all "user friendly". Each "requires" some sort of support (forum, etc.) to handle those cases where the user *can't* get to a system prompt (graphical or otherwise). EVEN IF THE USER'S PROBLEM IS COMMONPLACE ENOUGH THAT A "READY SOLUTION" CAN BE OFFERED UP (by that technical forum or user group).
I.e., OFFER those solutions to the user AT BOOT TIME!
On a sunny day (Sat, 18 Oct 2014 17:35:53 -0700) it happened Don Y wrote in :
OK, that is the hardware interface, I know all that, I have written BIOSes. Maybe the point is that a 'novice user?' as you call it will not normally try to get a Linux kernel working on his self designed hardware without any other computah of any kind available, or a clue what that hardware is. So I repeat the question what hardware are you running on? Others asked the same. Or are you making your own Linux distro? Or selling some software that you expect not to run in places and need this to help users to get it to run? One situation I can imagine is have some Linux runing in some FPGA with hardware interfaces that you made yourself... I have not tried to do that, so that seems a mystery to me now... But that is not your average user, maybe it will be a big company like A or X and an ARM core... and standard interfaces anyways... Things are not really that complicated, what is complicated and frustrating to a person like me is the endless GUI interfaces to 'help the clueless', take for example for networking, while I just type ifconfig and route..... and be done in 30 seconds.....
PERSONALLY I got fed up with all that shit years ago, and I have a file that runs at bootlevel X (cant remember X) and configures the whole machine (that includes unloading and loading modules, starting servers, what not) it is /usr/local/sbin/panteldingen..... 'panteldingen' has been copied from PC to PC with minor differences and does everything needed. Its one place, one file, one format, and it works. Dont even remember WhereTF it is called from.... that varies. Maybe you want to do something similar... that would be cool. :-) So far my PCs boot with standard Linuxes.. If not stick in a rescue disk (I have many), grml
formatting link
used to be cool for that, not sure it it has not morphed into the same molasses... I have one server running the first version...
The point is a NetBSD kernel is configured by indicating *how* each device (buses being devices as well!) are "wired" together. So, a particular driver can be configured to attach at various different places.
As such, you may want to disable its attachment "here" -- but *not* "there". So, in the example I presented, you could have serial ports ("com" driver) attached to the "isa" device (which is a bus) while disabling the serial ports on PCMCIA cards (or attached to the "acpi" device).
In this way, you can isolate problem instances of a particular device without unilaterally disabling all instances of a device.
[similarly, you can disable "COM2:" without disabling the "COM1:" instance]
"Self-designed hardware" is not the point. In my case, I couldn't get a kernel to successfully boot on a COTS Atom "computer" due to a problem in one of the bridges. If I allowed the bridge "device" to be present in the kernel, the boot would hang at the point where the bridge (device) tried to attach itself.
By disabling the bridge -- effectively removing the driver from the kernel that was ALREADY PRESENT on the CD -- the machine boots properly.
A novice user trying to boot that GENERIC kernel on this make/model computer would encounter the same crash. He would be left with "scrambled video" and very frustrated trying to provide answers to the sorts of questions that "support" folks would likely ask: "Which device was it probing at the time it crashed?" "I don't know. The screen is scrambled!" At this point, "support" would have to either have seen this problem before or made some educated guesses as to what sorts of things can "go wrong in a big way". Using that information, they could INSTRUCT the user to disable particular POTENTIAL drivers that may be the source of his problem and "try again".
Much simpler if you could publish a priori instructions that effectively say, "If something goes wonky, here is how you get to a 'fail safe kernel configuration'. Once there, make note of the contents of this diagnostic log file -- reporting it to 'Support'. Or, take the following additional steps to isolate the actual problem and get a more capable kernel running (with everything other than the problem device configured back into the kernel)"
The existing NetBSD implementation already addresses this sort of thing. If you are rolling your own hardware, you would tend to have already built a
*custom* kernel BEFORE releasing the hardware and kernel. You can add/remove devices that you *know* should/shouldn't be present in YOUR kernel. You aren't stuck using a GENERIC (that is literally the name of the kernel) kernel.
My "system" configures everything from an RDBMS. Which is also used to provide data to services while the system is running. E.g., the local name service maintains tables *in* that RDBMS (instead of in "private process memory"). The list of services controlled by inetd is yet another table in the RDBMS. The DHCP server's configuration is still another table. etc.
The various configuration files that litter the file system are gone. Parsing them is no longer something that a "service implementor" has to write from scratch (i.e., create a suitable grammar for the files and then write code to parse them to extract the configuration data contained within).
It also allows services to have a more wholistic view of the system and their clients -- because they can be redefined to peek at "other details" available for their clients instead of just restricting their knowledge to the services/data that they provide them.
So, I can replicate any portion of the system's configuration algorithmically -- with a bunch of SELECTs issued on that RDBMS.
Oh boy. The framework is differed from BSD. The terms do not always translate at all, let alone cleanly.
suggests
nfsd is a daemon program, not a driver.
hardware
them
hardware
"features"
temperature
controllers,
Disabling
There is quite a bit of variation in what is hardware and what is firmware and what is program in this list. At least some of this you are already aware of.
"board"/host).
having
(unless
Actually most of this is well hidden from even the techy types, the regular user just sees a computer OS that installs easy and uses and that works. I an a long term and serious Linux user and it "just boots, installs and runs" from my usual perspective.
OK there is a lot of misconceptions here. Just read some Linux support (hardware) groups and web sites for a few days. Then you can see the general user issues better.
NFS (as served by nfsd) requires kernel support. In NetBSD, a kernel that provides that support is built with: "options NFSSERVER"
In Linux, this is implemented by the knfsd.ko "module" -- which, presumably, can be "enabled and disabled" using the same mechanisms that have been described elsewhere in this thread for "Linux modules".
All of these are physical devices. I can *point* to the location of any of them on a given motherboard/PCI card/etc. All need specific software (drivers) to implement their functionality. The (hardware device) driver is the glue that allows the kernel to "talk to" these individual bits of "special" hardware (i.e., they aren't "memory" or "CPU").
As long as you are using a machine that someone has ALREADY SUPPORTED! :> Sort of "already-been-used" hardware.
But, I've got what I need to know to implement the features that I want. There are a few other things I'll want to tackle but I'll deal with them when the time comes.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.