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
