Where did you get them there devices ?

Wed Dec 12 19:55:55 UTC 2007

William Case wrote:
> Hi Mikkel;
> 
> This post is in order to start my own thread Re: Problem with random
> disks mount sequence.
> 
> 
> 
> "Your explanation is of great
> interest to me at the moment.  I am
> trying
> to trace exactly how the devices
> attached to my computer first get
> registered.  I just need someone to
> point me to the mechanism or kernel
> code.
> 
> On Wed, 2007-12-12 at 07:59 -0600,
> Mikkel L. Ellertson wrote:
>> Tim wrote:
> 
>> A slight correction. It is not the
> BIOS oder that determines the of
>> the drives under Linux. It is the
> kernel. What I would expect to
>> happen is that you would only have
> the drivers for the drive with
>> root file system loaded in the
> initrd, 
> This is handed over by grub from
> BIOS to initrd?
> 
Nope. Grub uses the BIOS mapping, because Grub can only access the
hard drive by using BIOS calls. This is entirely separate from the
kernel. Grub uses the BIOS to load the kernel and initrd into
memory. As part of the process, it creates a "data block" that has
the command string and the location of the initrd in memory. The
initrd is not necessary if you have the drivers to access the root
file system built into the kernel. If you are using an initrd, then
the kernel will mount that. The initrd normally has the modules and
scripts necessary to mount the root file system.

>> and the scan order would
> What and where is the kernel
> function that scans?  What does
> scanning in
> functional terms mean?  If you don't
> have the name of the function off
> the top of your head, suggest where
> I might look in kernel code.
> 
I believe the scan order is part of the drivers. I have not looked
at the code in the current kernels, but it used to be a combination
of factors that controlled it. When IDE drives were treated
differently, the order depended on where they were attached to the
controller, and the address of the controller. (There were fixed
addresses for the first, second, third, etc IDE controller.) With
SCSI controllers, the order of the controllers depended on how the
buss was scanned, unless there was something in modprobe.conf.
Drives on a SCSI controller have an address, and drives are given
letter starting from the lowest number, and going to the highest
number. (I don't remember if you can reverse the scan order on the
controller.) Letter assignment continues to the next SCSI
controller. SO if /dev/sda and /dev/sdb are on the first controller,
the next drive found will be /dev/sdc, even if it is on a higher
numbered controller.

SATA drives are handled as SCSI drives, but with there connection to
the controller, instead of a drive address, determining the letter.

USB drive ordering depends on what socket they are plugged into. If
you look in /proc/bus/usb/devices, you will see that there are USB
bus numbers, and device numbers. I have not checked the USB scan
order. Each USB drive counts as a SCSI controller. It is possible to
have more then one "drive" on a USB controller. For example, I have
a USB flash memory reader that has 4 slots for different types of
cards. Each slot is a SCSI drive.

How, as for where to look, I would try the high level SCSI drive
code. Probably scsi_mod. (drivers/scsi)
> 
> I know I can view attached devices
> through cat /dev/* or cat /sys/*.
> But those file systems just reflect
> a read-only view of an existing
> kernel file struct (I think).  How
> does the kernel, as it scans, place
> the data in the struct (or table)
> and what are the structs called?
> Isn't
> hwconfig just a user view?  Again
> pointing in the right direction is
> sufficient for me?
> 
The entries in /dev are created by udev when the device driver tells
the kernel that there is a new device. (For example when the driver
loads, or when a new USB drive is plugged in.)

You can find an easier way to read by looking in /proc/scsi (And
/proc/ide in pre-F7 kernels.)  /proc/scsi/devices will list the SCSI
controllers the system know about, in order. Remember, SCSI
controllers are scanned for devices from the lowest numbered one to
the highest numbered one. On SCSI controllers, CD/DVD drives are
numbered separately from hard drives. (scdx) So are tape drives. (stx).
> 
> I have been trying to trace (for
> interest and completeness of
> understanding) how device data first
> gets into the kernel for over a
> month now.  I have read endless
> number of sites regarding standards,
> naming protocols, address protocols,
> modules, drivers, BIOS and grub.
> All have been helpful and all have
> been ultimately understandable.  But
> words like "probes for", "registers"
> etc. for devices are never
> explained.
> 
> P.S.  I even have a manual (text
> book) that purports to explain the
> kernel code (2.6.7 or greater)
> line-by-line, which mainly it does,
> but
> it seems to remain silent on
> scanning and registering devices at
> startup. Or, at least, I am
> misreading because I can't find it."
> 
I am not sure I can give an understandable explanation of this. I
have never studied it in the depth you are after. For example, I
know that the PCI bus is scanned at bootup for devices attached to
it, and I know you can reverse the order of the scan. Each device on
the PCI bus reports what it is, and based on this information, the
kernel loads the driver for it, if there is one. This can be
modified by /etc/modprobe.conf and the files in the
/etc/modprobe.conf.d directory. But I do not know the how the search
is coded. I also know that the PCI sockets are numbered, but the
order is motherboard dependent. There are also more then one PCI
bus, but some only connect to devices on the motherboard. I assume
that things are scanned from the lowest numbered bus to the highest
numbered one, but I have never checked.

One top of this, there are devices that do not identify themselves.
These tend to be ISA devices. The only way to find them, unless they
are identified in modprobe.conf, is to test specific addresses for
the proper response. You can have ISA devices, even if there are not
ISA slots on the motherboard. On-board serial and parallel posts are
the most common types you find.

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20071212/2298acf9/attachment-0001.bin 