Re: Where did you get them there devices ?



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!

Attachment: signature.asc
Description: OpenPGP digital signature

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Relevant Pages

  • [PATCH 18-rc2] Fix typos in /Documentation : N-P
    ... Again, if you're not gonna do synchronization with disk drives (dang, ... -the kernel. ... There are two options specific to PSX driver portion. ... The driver uses the settings from the EEPROM set in the SCSI BIOS ...
    (Linux-Kernel)
  • Re: 3B2 Disks
    ... being able to read the disk in its present format. ... 2 MFM drives on a custom controller. ... SCSI came much later as an add on card. ...
    (comp.sys.3b1)
  • Re: 3B2 Disks
    ... 2 MFM drives on a custom controller. ... what it came out of) but the only SCSI I heard about on the 3B's used ... any software out and would more likely have recycled the floppy disks. ...
    (comp.sys.3b1)
  • Re: Loss of SCSI boot after CMOS battery replacement
    ... result of my old motherboard BIOS after all. ... controller takes priority over the SCSI ... IDE first to SCSI first. ... SCSI drives and Win98. ...
    (comp.periphs.scsi)
  • Re: ahc driver now borked in -current?
    ... of those pesky 3.5" floppy drives, ... > controller (one of the older ASUS motherboards we all used to covet when they ... Using a kernel compiled ... > said, with the non-functioning kernel, we don't get any further than waiting ...
    (freebsd-current)