OT: disabling a driver at boot time in Linux kernel - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: OT: disabling a driver at boot time in Linux kernel
Gave us:

Quoted text here. Click to load it

  He knows that.

Quoted text here. Click to load it

  One is, the other is not as much.

Quoted text here. Click to load it

  Probably obsolete, since everyone cross-compiles on virtual machines
now.

Quoted text here. Click to load it

  How many times have folks here told you that you are such an ass?

  The smiley thing means nothing, ass.

Quoted text here. Click to load it

  Stop mumbling, ya drunken fuck.

Quoted text here. Click to load it

  You wouldn't know, since you fall below even that curve plot.

Quoted text here. Click to load it

  Folks need you to spout this near truth?

Quoted text here. Click to load it

  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.

Re: OT: disabling a driver at boot time in Linux kernel
On a sunny day (Sat, 18 Oct 2014 02:03:06 -0700) it happened

Quoted text here. Click to load it

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.

:-)

Re: OT: disabling a driver at boot time in Linux kernel
On 10/18/2014 1:26 AM, Jan Panteltje wrote:

Quoted text here. Click to load it

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:

    <device><#>    at <attachpoint>

'#' can be a small integer to indicate a particular instance of
a particular <device>.  Or, can be a wildcard to allow "next available
instance" to be assigned.   Same sorts of rules apply to <attachpoint>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)]

Quoted text here. Click to load it

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).]

Quoted text here. Click to load it

Re: OT: disabling a driver at boot time in Linux kernel
On a sunny day (Sat, 18 Oct 2014 17:35:53 -0700) it happened Don Y

Quoted text here. Click to load it

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 (www.grml.org) 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...










Re: OT: disabling a driver at boot time in Linux kernel
On 10/19/2014 2:58 AM, Jan Panteltje wrote:
Quoted text here. Click to load it


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]

Quoted text here. Click to load it

"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)"

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it


Re: OT: disabling a driver at boot time in Linux kernel

Quoted text here. Click to load it
in
tried
kernel
computer
before
in a
disable
 say,
Quoted text here. Click to load it
diagnostic
additional
running
the

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.

?-)
  

Re: OT: disabling a driver at boot time in Linux kernel

Quoted text here. Click to load it
  If
Quoted text here. Click to load it
a
add/remove
Quoted text here. Click to load it
You
kernel.

Poxy hell.  You are conflating two extraordinarily different use cases.

?-)
  

Re: OT: disabling a driver at boot time in Linux kernel
Gave us:

Quoted text here. Click to load it



  Bwuahahahahahahaa!

Re: OT: disabling a driver at boot time in Linux kernel
Gave us:

Quoted text here. Click to load it


  You mean like your complete lack of a clue about the word COMPUTER?

  Grow up, child.  You are currently self retahded.

Re: OT: disabling a driver at boot time in Linux kernel
On Wed, 15 Oct 2014 11:37:40 -0700, Don Y wrote:

Quoted text here. Click to load it

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.


Re: OT: disabling a driver at boot time in Linux kernel
us:

Quoted text here. Click to load it

  Best and most correct description yet.

  I suppose grub menu entries could be made to make calls on different
initrd files.

  Are they not specifically tied to the kernel under which they were
made?

  So, we are back to multiple kernels and initrd files and boot menu
entries.

  Seems grub could do so much more with some sophisticated submenu
'switch action' selectors made available.

  I dunno.

Re: OT: disabling a driver at boot time in Linux kernel
On 10/18/2014 6:44 PM, Nobody wrote:
Quoted text here. Click to load it

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").

Quoted text here. Click to load it

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!

"In case of difficulty, break glass"

Re: OT: disabling a driver at boot time in Linux kernel

Quoted text here. Click to load it

  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

Quoted text here. Click to load it

  Make multiple kernels and boot via a menu the one you need.

Quoted text here. Click to load it

  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..."

Re: OT: disabling a driver at boot time in Linux kernel
On a sunny day (Sat, 18 Oct 2014 02:13:29 -0700) it happened

Quoted text here. Click to load it

Don dont listen to that idiot, he or it is always wrong.

Re: OT: disabling a driver at boot time in Linux kernel
Gave us:

Quoted text here. Click to load it

  Try reading what he asked for, you retarded twerp.
It wasn't about you and your retarded cross compiling instruction from
ten years ago.

  Don...  Same tone as my last...

  "This 'Jan' is not the advisor you are looking for."

Re: OT: disabling a driver at boot time in Linux kernel

Quoted text here. Click to load it

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.



Site Timeline