FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 12-12-2007, 05:32 PM
William Case
 
Default Where did you get them there devices ?

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?

> 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.

> always be the same unless you
physically change drive connections
or
> add drives. (Or use a kernel
parameter to change the order.)
>
> With SATA drives and USB drives,
the USB drive should always be
> discovered later then the SATA
drive because the usb_storage driver
> should not be loaded until after
the root file system is mounted.
>
But if the
> usb_storage module is in the
initrd, then things are not as
clear.
> It should still find things in the
same order, but in this case, it
> isn't.
>
> One other thing that I should have
commented on earlier - there is
> nothing that says that the root
file system has to be on the first
> SCSI drive, so the system can use
that in determining what drive
> should be /dev/sda. It used to be
fairly common in dual boot systems
> to have Window on the first drive,
and Linux on the second drive.
>

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?

> Mikkel
> --

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."





--
Regards Bill

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-12-2007, 06:55 PM
"Mikkel L. Ellertson"
 
Default 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!

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 12-13-2007, 07:29 AM
William Case
 
Default Where did you get them there devices ?

Hi Mikkel;

Thanks for your info. With your explanation and a little extra
googeling I was able to learn that device registration starts with the
setup.c (Setup.S) in the kernel code with the creation and compilation
of the Interrupt Description Table and the Global Description Table. I
am just digging in now, but it seems to be all there.

On Wed, 2007-12-12 at 13:55 -0600, Mikkel L. Ellertson wrote:
> William Case wrote:
> > Hi Mikkel;

--
Regards Bill

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

Thread Tools




All times are GMT. The time now is 01:21 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org