Hi,
I'm looking for information (keywords for a search?) regarding the *user interface* that allows selected drivers in a particular kernel to be effectively excised during the boot. So, the boot proceeds AS IF the driver was not present (i.e., the code in the driver doesn't execute at all -- not even the probe()!)
[I don't want to perform these actions. Rather, just want to examine how this is handled FROM A USER'S PERSPECTIVE]Thx,
--don
On a sunny day (Wed, 15 Oct 2014 11:09:28 -0700) it happened Don Y wrote in :
edit /etc/modprobe.d/blacklist.conf example: blacklist pcspkr
Read:
Google search: linux inhibit driver loading at boot
On a sunny day (Wed, 15 Oct 2014 18:31:02 GMT) it happened Jan Panteltje wrote in :
PS if the driver is compiled into the kernel, not as module, then I dunno if you can prevent it from executing if it finds the hardware.
No. That only apparently works for things built *as* modules (at least the web pages that I have visited state this condition) AND only works AFTER you have a bootable system.
I want to be able to disable a particular driver AT BOOT having never had the system "up".
afaik you can't unless the driver itself provides a way to do it on the boot command line, else you'll need to build a new kernel without the driver
-Lasse
OK. In NetBSD, you can disable any driver with a statement of the form: userconf disable at the boot prompt. After the system boots, you can add this to the boot.conf(5) file so that it happens automagically thereafter.
"Modules" are handled differently.
But, this is klunky and requires intimate familiarity with the system. I.e., what's the name of the VIA IDE driver? Or, the Atheros wireless?
While I can interactively *list* all of the (~500) drivers in the kernel prior to booting, that list is essentially meaningless to anyone that is not "in the know".
The module blacklist also works as a kernel boot option (second answer):
I don't think you can disable drivers compiled into the kernel though, unless the driver supports some specific boot option to do that. See this for some examples:
There is also the kernel boot option initcall_blacklist that allows you to disable specific initcalls and therefore (maybe) specific drivers, but probably you need to know a lot of kernel internals to use it.
-- Fletto i muscoli e sono nel vuoto.
Can you build a kernel where all the drivers are implemented as modules and, thus, get around this restriction in that way?
So, there's no way for "mere mortals" to get a system up and running without a techy to hold their hands.
NetBSD tries to address some of the "common" problems that might plague a particular system -- e.g., boot with SMP disabled, boot with ACPI disabled, etc. -- but, it still seems like you need someone to talk you through a failed boot if you aren't technically inclined.
I'll have to think about what "makes sense" from a user's perspective ("ignorance") before coding something up. Look at it with a set of "if you have a problem, try these things in this order" instructions in mind.
Thanks!
Sounds like you need to rebuild the kernel first. (On another system, if you really don't want it to load, ever. What are you running it on, a Trident missile?)
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
The GENERIC/INSTALL kernels for NetBSD are "kitchen sink" sorts of efforts. Damn near everything imaginable stuffed in so it runs on "anything" (well, anything for that particular processor variety).
Bringing up a system for the first time relies on that kernel being bootable (well, there are other kernels that you can choose from but the point is to make this as easy as possible for Joe Average User to "get right").
The ability to selectively enable/disable different in-kernel drivers BEFORE boot (via an interactive menu system) allows a tech-savvy user to get a kernel to boot even if a driver has issues with the particular hardware.
In my case, I knew the board had a SiS chipset that was probably the reason I couldn't boot. So, I disabled the device associated with that chipset (bridge) and was able to boot the system.
Adding that "disable pchb" command to the boot.conf(5) file ensures that it will be disabled on all future boots -- IF present in the kernel that I elect to boot!
Once the machine boots, I am free to build a new kernel eliding that driver -- as well as any of the others that aren't pertinent to THAT particular board (by examining the devices in dmesg(8) that were successfully probed during the boot and commenting out -- of the kernel config file -- any that are not detected.
Then: mv /netbsd /netbsd.GENERIC # save the old generic kernel in case I need it mv mykernel /netbsd # install my new kernel reboot
I would like this NOT to be reliant on technical expertise (forget the kernel rebuild... I'm interested primarily in the initial BOOT!) so casual/inexperienced users can successfully bring up a system on a new board without having to GUESS as to what devices may be causing them problems.
E.g., make it possible to do a "boot barebones" if the GENERIC kernel "has issues" on a particular system. Then, examine the dmesg output to see what other devices your hardware may *need* and add them back in, incrementally, to determine where the problem lies (it may lie in a driver that is not even pertinent to your hardware -- so, why enable it at all??)
Most distribution kernels come configured in a such way that all drivers except the essential ones for booting are in modules. The modules are in an initial ramdisk image (initrd) which is loaded into the memory together with the kernel. The kernel picks the necessary modules (including the disk and filesystem drivers) from the initrd at startup.
If you want to change the initially loaded modules, you may need to change the ramdisk image (usually at /initrd).
-- Tauno Voipio
Then it would boil down to the discretion of the individual who decides which are "essential". In my case, I would assume the PCI host bridge would *probably* have been considered "essential" -- even though it isn't.
Regardless, if the "user interface" for disabling/enabling is a command line (or make command line entries in a config file), it is still too "techy" for Joe Novice User (bringing up a system on a virgin machine). That is the current case for NetBSD (though it makes no distinction between essential and nonessential drivers -- anything in the kernel can be enabled/disabled at boot time).
I think I've come up with an approach that should work (friendly and intuitive) and be easily extensible. The hard part is always managing the limited resources available that early in the IPL. I'll try to start coding it up later today.
No, strike that. I have to help assemble a greenhouse for a neighbor. :<
(sigh)
Hmmm... a cursory examination of a sample linux kernel configuration suggests Linux uses the term "driver" in a more general sense. To be clear, I am talking about "hardware device drivers". E.g., nfsd is not a "driver". (there is no "nfs hardware" -- there are NIC drivers and storage media drivers that NFS relies upon, but no specific "NFS hardware"!)
Hardware device drivers are those things that probes the specific hardware on a particular host. They have memory/IO addresses associated with them (explicitly or implicitly).
[Where does the "NFS" hardware reside? Where does the "hibernation" hardware reside? Many/most Linux modules appear to implement subsystems or "features" that NetBSD deals with as "kernel OPTIONS" (keyword)]The video chipset, host bridge, parallel port, network interface chips (cards), PHY's, scsi host bus adapters, radios, usb controllers, temperature monitors, SATA/PATA controllers, etc. are "drivers" in the context I am using. There may be dozens of NIC's supported, ditto with video controllers, etc. I want to be able to selectively enable/disable ANY of them! Disabling ALL of them should result in an unbootable kernel (because the kernel won't be able to talk to ANY of the hardware!)
Adding support for RT extensions, NFS, different file systems, etc. is at a much higher layer (and has little to do with a particular "board"/host). I.e., if NFS works on any machine, it works on ALL machines (subject to having suitable hardware drivers UNDER it).
Most of the NetBSD hardware device drivers are processor neutral (though obviously the code to implement them has to be compiled to the native instruction set). *All* of the drivers are "enable/disable-able" (unless they don't appear in the kernel instance at all!)
[This is part of what contributes to it being so intimidating for non-techy's... long lists of "supported hardware devices" referenced solely by cryptic 4 or 5 letter "driver names" and memory/IO/irq/drq qualifiiers.]
The only interface available is boot parameters, so look there.
eg: I suspect that if I say "8250.nr_uarts=0" then it won't go looking to any 8250 compatible serial ports. (I can't say for sure I've not tried setting it to 0)
-- umop apisdn
On 18 Oct 2014 03:34:55 GMT, Jasen Betts Gave us:
It also has to have been a feature which was compiled into the kernel AS a "loadable module".
AFAICT, the Linux kernel doesn't reflect the structure of the hardware in the kernel's configuration ("specification").
E.g., in NetBSD, I can disable a particular IDE controller chip *if* it is attached to a PCI bus but not if "discovered" on the ISA bus or a PCMCIA bus or dangling off a USB controller, etc.
(trivial example just to give an idea of the *structure* encoded in the "device universe").
Or, disable all instances of that controller regardless of where encountered.
[By analogy, you can disable an entire *bus* -- and any devices that might otherwise have been detected on that bus]This is more like the way SPARC's are probed (under Solaris)
In any case, everything that I have found is geared towards tech-savvy users and would require a fair bit of hand-holding for a novice user to be able to effectively use WITHOUT SUPERVISION.
no, it can be pert of the kernel binary (not a loadable module) and still be configured (and potentially disabled) at boot time.
-- umop apisdn
On 18 Oct 2014 05:47:36 GMT, Jasen Betts Gave us:
I sit... with an updated knowledge.
On a sunny day (Fri, 17 Oct 2014 22:18:29 -0700) it happened Don Y wrote in :
I do not quite follow you here, you can [re]compile a kernel and specify any driver you want or do not want. Cross compiling or compiling a kernel is not that hard, I have a 10 or 20 line guide I wrote myself.
As you claim to know what driver you do not want to execute, you must be a very experienced hardware man... :-) The 20 lines of instruction is much less that RTF man pages for a hundred things.
And Linux is not for dummies. OTOH if you install Ubuntu, or Debian, or Slackware, many others, things will run out of the box on normal platforms. Did you design your own hardware or something?
On Sat, 18 Oct 2014 08:26:41 GMT, Jan Panteltje Gave us:
He knows that.
One is, the other is not as much.
Probably obsolete, since everyone cross-compiles on virtual machines now.
How many times have folks here told you that you are such an ass?
The smiley thing means nothing, ass.
Stop mumbling, ya drunken f*ck.
You wouldn't know, since you fall below even that curve plot.
Folks need you to spout this near truth?
You make some of the most stupid remarks I have ever seen.
For the OP...
WHEN you do perform a re-compile, there is a graphical configuration you can use, which will allow you to see ALL the "switches" and modules Linux has packed away in itself, before you BEGIN the compile itself.
The script it uses as a baseline is the current configuration of the current kernel. IOW YOUR current config.
So all you would have to do is find your pesky driver/module/property in that configuration session, and shut it off, or leave it out completely.
You could compile multiple kernels with hard locks in those areas, and boot the kernel needed for the particular task, though that is less orthodox than the loadable module paradigm.
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.