File: 2.html

package info (click to toggle)
lg-issue57 2-1
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 1,704 kB
  • ctags: 189
  • sloc: sh: 251; makefile: 34
file content (247 lines) | stat: -rw-r--r-- 11,014 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
<!--startcut ======================================================= -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<META NAME="generator" CONTENT="lgazmail v1.3E.d">
<TITLE>The Answer Gang 57: File with Device Information</TITLE>
</HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000"
	LINK="#3366FF" VLINK="#A000A0">
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<P> <hr> 
<CENTER>
<!-- *** BEGIN navbar *** -->
<!-- *** END navbar *** -->
</CENTER>
</p>
<P> <hr> <P>
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<center>
<H1><A NAME="answer">
	<img src="../../gx/dennis/qbubble.gif" alt="(?)" 
		border="0" align="middle">
	<font color="#B03060">The Answer Gang</font>
	<img src="../../gx/dennis/bbubble.gif" alt="(!)" 
		border="0" align="middle">
</A></H1> 
<BR>
<H4>By James T. Dennis,
	<a href="mailto:linux-questions-only@ssc.com">linux-questions-only@ssc.com</a><BR>
	LinuxCare,
	<A HREF="http://www.linuxcare.com/">http://www.linuxcare.com/</A> 
</H4>
</center>

<p><hr><p>
<!--  endcut ======================================================= -->
<!-- begin 2 -->
<H3 align="left"><img src="../../gx/dennis/qbubble.gif" 
	height="50" width="60" alt="(?) " border="0"
	>File with Device Information</H3>
	<h4 align="center">System Inventory File?</H4>


<p><strong>From Paul Haigh on Thu, 17 Aug 2000  
</strong></p>
<p align="right">Answered By: Jim Dennis</p>

<P><STRONG>
Hi
</STRONG></P>
<P><STRONG>
I once looked at a file in linux which had a listing of all devices
found during the installation process.  For example it listed the
Video card of the PC I had just installed.  I was using Redhat 6.0.
What is the name of this file?  Where is it?  I for the life of me can't
remember. nor find it  I thought it was in <TT>/proc</TT> but that isn't correct.
Sorry to be so forgetful.  Thanks, your help is appreciated.
</STRONG></P>
<P><STRONG>
Paul
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	>
Hmm.  The installation process is specific to each distribution.
So that list would depend on whether you were using <A HREF="http://www.redhat.com/">Red Hat</A>,
<A HREF="http://www.debian.org/">Debian</A>, Mandrake, etc.  I also don't know what filename it would
be under, nor which distributions and versions store this
information.
</BLOCKQUOTE>
<BLOCKQUOTE>
Indeed the whole issue is rather more complicated than you
question implies.
</BLOCKQUOTE>
<BLOCKQUOTE>
A Linux kernel does a certain amount of probing to find devices.
This depends on the list of device drivers that were linked into
the kernel.  Obviously if you leave a device driver out of a kernel,
that kernel won't probe for those devices.  It's not as obvious, but
the kernel also won't probe for devices for which the drivers were
compiled as modules.  To be more precise the kernel won't probe for
any device until its device driver is loaded.
</BLOCKQUOTE>
<BLOCKQUOTE>
So, you may find that some devices are completely ignored
(undetected) until you've loaded the appropriate kernel module, or
rebuilt a kernel with the necessary support.
</BLOCKQUOTE>
<BLOCKQUOTE>
Some devices may also go undetected because they are set at some
set of addresses (I/O or memory mapping) that is unusual for them,
or is likely to be in conflict with other devices.  The kernel
doesn't scan the entire I/O address space for each card.  Not only
would that be slow, it would probably hang the system.  Devices must
be accessed using the correct protocols <TT>---</TT> and some of those
will go into a catatonic state, or will lock up the whole system
if they are accessed incorrectly.  (The Linux kernel avoids most of
these "dangerous regions" by default, and only looks for most devices
in the common places).
</BLOCKQUOTE>
<BLOCKQUOTE>
All of this much less of a problem in recent years.  Most platforms
have adopted the PCI bus which has standard methods for discovering
and identifying devices, and for avoided conflicts among them.  In
essence your PCI bus is a network of semi-intelligent adapter cards
interoperating over the PCI "protocol."  This has always been true
of SCSI as well (though with SCSI we still need to manually set
unique device IDs).  USB and firewire are also much more intelligent
and less problematic than the old ISA PC bus.
</BLOCKQUOTE>
<BLOCKQUOTE>
That brings us back to the question at hand.  How do we determine
what hardware is installed in a PC without opening the case and
getting the (all-too-often unavailable and/or inadequate)
specification sheets.
</BLOCKQUOTE>
<BLOCKQUOTE>
You can start with <TT>/var/log/dmesg.</TT>  This file should have a
copy of all the messages that your kernel printed during the
initial boot process.
</BLOCKQUOTE>
<BLOCKQUOTE>
Then take a look at <TT>/proc/pci.</TT>  As you probably know, the <TT>/proc</TT>
directory is usually a mount point for a special "virtual"
filesystem.  The various "files" and directories that appear under
<TT>/proc</TT> don't exist as real files on any disk drive.  They are sort of
like a "RAMdisk" except that they don't take up memory in the same
way.  The "files" under <TT>/proc</TT> are actually a representation of the
kernel's state or of specific data structures as they are maintained
by the kernel.  The entries under <TT>/proc</TT> are dynamic <TT>---</TT> the
contents of these "files" will appear to change as the state of the
kernel changes.  (In fact under the <TT>/proc/sys</TT> directory tree there are
many nodes or "files" which can be modified by the system administrator
to change the state of the kernel).
</BLOCKQUOTE>
<BLOCKQUOTE>
After looking at <TT>/proc/pci</TT>, peruse <TT>/proc/interrupts</TT> and <TT>/proc/ioports</TT>
and explore some of the other files thereunder.  Note:  All of the
<TT>/proc/XXXX</TT> dircectories, where XXXX is a number are "processes."  These
represent all of the state about each process that is accessible to
programs like 'ps' and 'top'. The original purpose of the <TT>/proc</TT>
directory in UNIX (and Linux) was to allow for a cleaner interface
to process data and to allow programs like 'ps' to be run without
requiring them to have 'root' access.  The Linux <TT>/proc</TT> goes beyond
that to contain lots of information about the process state.
</BLOCKQUOTE>
<BLOCKQUOTE>
In the next version of the kernel (2.4.x) you'll see yet another way
to discover hardware that's installed in your system.  The 2.4.x
kernels will support a feature called "devfs" (a "device filesystem").
This is similar to <TT>/proc</TT> in that it's virtual and  that it dynamically
represents the state of a system as the kernel "sees" it.  There are
significant differences.  However, we'll skip further comparison of
<TT>/devfs</TT> to <TT>/proc.</TT>
</BLOCKQUOTE>
<BLOCKQUOTE>
What's more interesting here is a comparison of <TT>/devfs</TT> to the
traditional <TT>/dev/</TT> directory.  The <TT>/dev/</TT> directory normally contains a
set of "nodes" (basically special empty files with funny numbers
instead of a filesize).  Those "nodes" have all the attributes of
regular files (owners, group associations, permissions, and dates.
They come in two types, character and block.  On a typical UNIX or
Linux system the <TT>/dev/</TT> directory contains a list of all the common
devices that might be on a system.   This list can be quite large
(over a thousand entries on my laptop).  Obviously no system actually
has all of those devices.  However, most systems contain the entries
for them as a bit of bookkeeping baggage.
</BLOCKQUOTE>
<BLOCKQUOTE>
With <TT>/devfs</TT> we'll see only a list of those devices which were
detected by the kernel.  As we load kernel modules we'll see
new nodes appear under <TT>/devfs.</TT>  It's also possible to manually
create nodes under <TT>/devfs.</TT>  Those will persist until the next
reboot.  Thus it may be necessary for some systems to restore
a list of device nodes under their <TT>/devfs</TT> directory every time
you reboot.  (That would probably be most easily done by simply
adding an rc.* script to extract a .tar or cpio file into the
newly mounted <TT>/devfs</TT> directory).
</BLOCKQUOTE>
<BLOCKQUOTE>
Of course this new model won't just appear overnight.  It will be
interesting to see how the distribution maintainers (<A HREF="http://www.caldera.com/">Caldera</A>,
<A HREF="http://www.turbolinux.com/">TurboLinux</A>, etc) each choose to integrate this new feature into
their offerings.
</BLOCKQUOTE>
<BLOCKQUOTE>
Meanwhile there are things like Red Hat's "kudzu" package which
tries to detect newly added hardware when it is first installed into
your system (upon the next reboot).  That may also help you.
</BLOCKQUOTE>
<BLOCKQUOTE>
Sometimes, you'll probably still have to grab a screw driver and
pop open the case.  Worse, sometimes you probably will have no
practical way of knowing about some of the hardware that's in your
systems.  PC manufacturers have gotten lax about providing
technical documentation with their equipment.
</BLOCKQUOTE>

<!-- sig -->
<!-- sig -->


<!-- end 2 -->
<!--startcut ======================================================= -->
<P> <hr> </p>
<H5 align="center"><a href="http://www.linuxgazette.com/copying.html"
	>Copyright &copy;</a> 2000, James T. Dennis 
<BR>Published in the <I>Linux Gazette</I> Issue 57 September 2000</H5>
<H6 ALIGN="center">HTML transformation  by
	<A HREF="mailto:star@tuxtops.com">Heather Stern</a> of
	Tuxtops, Inc.,
	<A HREF="http://www.tuxtops.com/">http://www.tuxtops.com/</A> 
</H6>
<P> <hr> 
<!-- begin tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::-->
<p align="center">
<table width="100%" border="0"><tr>
<td align="right" valign="center"
	><IMG ALT="" SRC="../../gx/navbar/left.jpg"
        WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="middle" border="0">
<A HREF="../lg_answer57.html"
	><IMG SRC="../../gx/dennis/answertoc.jpg" align="middle"
              ALT="[ Answer Guy Current Index ]" border="0"></A></td>
<td align="center" valign="center"><A HREF="../lg_answer57.html#greeting"><img align="middle"
	src="../../gx/dennis/smily.gif" alt="greetings" border="0"></A> &nbsp;
  <A HREF="1.html">1</A> &nbsp;
  <A HREF="2.html">2</A> &nbsp;
  <A HREF="3.html">3</A> &nbsp;
  <A HREF="4.html">4</A> &nbsp;
  <A HREF="5.html">5</A> &nbsp;
  <A HREF="6.html">6</A> &nbsp;
  <A HREF="7.html">7</A></td>
<td align="left" valign="center"><A HREF="../../tag/kb.html"
	><IMG SRC="../../gx/dennis/answerpast.jpg" align="middle"
              ALT="[ Index of Past Answers ]" border="0"></A>
<IMG ALT="" SRC="../../gx/navbar/right.jpg" align="middle"
        WIDTH="14" HEIGHT="45" BORDER="0"></td></tr></table>
</p>
<!-- end tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::::-->
<P> <hr> 
<CENTER>
<!-- *** BEGIN navbar *** -->
<!-- *** END navbar *** -->
</CENTER>
</p>
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
</BODY></HTML>
<!--endcut ========================================================= -->