Note about the "ethernet cable" q... what's "kernel" and what's "not"
When you are considering the cause of a problem that appears to be "related to hardware," don't assume that it has too-much to do with the kernel. In many cases it does not.
Fact of the matter is, "the kernel, proper" is a very specialized, very special-purpose part of the total system which is constrained to operate under some very peculiar rules. It is actually only one of several parts of the total software layer which is responsible for "system" concerns such as the insertion or removal of devices.
That is to say, in many cases the kernel will instead "do something" that is designed to be reacted to by a user-level process. In other words, even though it might necessarily be "the first one to hear the phone ring," in a great many cases what it does is to immediately forward that notification to (suitably privileged, not available to just-everyone) user-land-level software. A daemon. Something that very easily knows how to read a file, and that can operate in the luxurious environment that the kernel makes available to "all user-land processes, privileged or not."
For example, the udev mechanism, along with hotplug and of course coldplug, are designed to "abstract away" key functionality ... functionality which is, quite un-arguably, "a system-level concern," so that it can be handled on behalf of the kernel by (suitably privileged, not available to everyone, but...) userland-side code.
Say you plug-in a USB device. That, unlike (I think...) connecting or disconnecting a network cable, triggers a hardware event. But the majority of the system's response to that event is configurable. The kernel notifies an appropriate user-land process, which in turn eventually tells the kernel what to do about it. (The kernel naturally makes the "tell me what to do about it" interfaces available only to this guy ... only Billy Batson can say, "Shazam!" and hear a thunderclap.)
Thus, what might superficially appear to be a legitimate entry here in the "kernel..software" thread of this forum, might not actually be a kernel-programming concern.
Thus... before "immediately asking here," poke around a little bit. The /Documentation folder in the kernel source-code tree. (It will be a separate package that you can download... go ahead, do it.) Or, find the documents online. When you do this, you'll get not only the necessary answer to your question, but you'll get it in full context.
Last edited by sundialsvcs; 11-30-2012 at 02:47 PM.