2000-12-07 23:42:25

by Bryan Whitehead

[permalink] [raw]
Subject: Disableing USB.

Is there a way I can disble a part of the kernel that is compiled into the
kernel? For example I'd like to pass this to lilo: "usb=disable" and then
the usb code is not loaded even though USB has been built into the kernel.

Is such a feature stupid? Or has this already been implemented?

It would be nice if this was generic and I could also pass things like
"procfs=disabled".

The resone I ask is a friend of mine got a new Sony Vaio Laptop that has
the ethernet card and USB device stepping on eachother. It would be nice
to pass to the Redhat/Mandrake/whatever installation boot disk usb=disable
so the ethernet card can work freely (he's doiung a ntwork install becasue
he has no CD-ROM), as he doesn't use any USB devices anyway.

--
---
Bryan Whitehead
Email: [email protected]
WorkE: [email protected]


2000-12-08 01:53:45

by David Riley

[permalink] [raw]
Subject: Re: Disableing USB.

Bryan Whitehead wrote:
>
> Is there a way I can disble a part of the kernel that is compiled into the
> kernel? For example I'd like to pass this to lilo: "usb=disable" and then
> the usb code is not loaded even though USB has been built into the kernel.
>
> Is such a feature stupid? Or has this already been implemented?
>
> It would be nice if this was generic and I could also pass things like
> "procfs=disabled".
>
> The resone I ask is a friend of mine got a new Sony Vaio Laptop that has
> the ethernet card and USB device stepping on eachother. It would be nice
> to pass to the Redhat/Mandrake/whatever installation boot disk usb=disable
> so the ethernet card can work freely (he's doiung a ntwork install becasue
> he has no CD-ROM), as he doesn't use any USB devices anyway.

Er... Well, the traditional solution has been "don't build it into your
kernel if you don't want it", but in the case of stock kernels, that
isn't always an option, I suppose. Theoretically, the two devices
shouldn't step on each other, but this is a computer. Theory is so far
removed from practice that it's... Well, I can't think up a good
analogy. It's far.

*looks at kernel config options*

Well, it looks like the usb cores (UHCI and OHCI) can be modular. Why
aren't they in the stock kernel, other than possibly autodetection
problems? If they are built as modules, using expert mode in RedHat or
whatever equivalent may be in other dists may let you avoid insmodding
the USB stuff...

Beyond that, having a command-line disable feature does seem pretty
neat. Although why would you want to disable procfs? Maybe I missed
something there, but it seems awful darn important to leave out. :-)

--
"Windows for Dummies? Isn't that redundant?"

2000-12-08 21:42:15

by Bryan Whitehead

[permalink] [raw]
Subject: Re: Disableing USB.

> Er... Well, the traditional solution has been "don't build it into your
> kernel if you don't want it", but in the case of stock kernels, that
> isn't always an option, I suppose. Theoretically, the two devices
> shouldn't step on each other, but this is a computer. Theory is so far
> removed from practice that it's... Well, I can't think up a good
> analogy. It's far.
>
> *looks at kernel config options*
>
> Well, it looks like the usb cores (UHCI and OHCI) can be modular. Why
> aren't they in the stock kernel, other than possibly autodetection
> problems? If they are built as modules, using expert mode in RedHat or
> whatever equivalent may be in other dists may let you avoid insmodding
> the USB stuff...

Nope. Expert just means you'll be doing allot of stuff manually, Like
partitioning, package selection, configureing X, and some net stuff.

> Beyond that, having a command-line disable feature does seem pretty
> neat. Although why would you want to disable procfs? Maybe I missed
> something there, but it seems awful darn important to leave out. :-)

I was just using that as an example. Being able to disbale whatever part
of the kernel you want might be really helpfull in many cases... Maybe
procfs was a bad example... :P


--
---
Bryan Whitehead
Email: [email protected]
WorkE: [email protected]