Need help on understanding hardware detection

Hi All:
I did some search on "how does linux kernel detect hardware?" and got what udev is.
I konw Linux kernel will send a netlink message to udevd.
But I still do not understand how the kernel can decide to send a netlink message.
What happend before the netlink message?
Take an usb stick for example, what will happen and what the kernel do from the very beginning of it been plugged in? Thank you for advance. Any references will be appreciated.

--------------
Tao Jiang (??)
2013-08-19

have a look at http://blogas.sysadmin.lt/?p=141 will give you a nice idea...

Cheers,
Saqlain.

Kind Regards,
Saqlain Abbas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130819/05c90648/attachment.html 

Saqlain:
Thanks for your reply.
The article really opened my eyes.
But in that article wrote as
1. " Linux kernel constantly scans all your computer bus?es for any changes and new hardware. Once any change on any bus is detected magic begins " And in the comments at the bottom,
2. "a bus controller notifies the CPU through an interrupt which allows the kernel to query the controller back for information" So my question is which one is right?
And can you show me more details on Linux kernel's implementation about "constantly scans" or "notifies the CPU through an interrupt"?

------------------
Tao Jiang (??)
2013-08-20

-------------------------------------------------------------
????Saqlain Abbas <[email protected]> ?????2013-08-19 19:53
????Tao Jiang (??)
???kernelnewbies
???Re: Need help on understanding hardware detection

have a look at http://blogas.sysadmin.lt/?p=141 will give you a nice idea...

Cheers,
Saqlain.

Kind Regards, 
Saqlain Abbas. 

I believe "CPU through an interrupt" is correct, dude there is lot material on Google on this topic, just try to search using terms "how kernel detect a hardware" or "kernel plug and play" etc, try to use different queries and you will find lot of stuff.

Cheers,

Kind Regards,
Saqlain Abbas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130820/fc32d3da/attachment.html 

Saqlain:
Thanks for your guide.
I'll do more search.

------------------
Tao Jiang (??)
2013-08-20

-------------------------------------------------------------
????Saqlain Abbas <[email protected]> ?????2013-08-20 11:28
????Tao Jiang (??)
???kernelnewbies
???Re: Re: Need help on understanding hardware detection

I believe "CPU through an interrupt" is correct, dude there is lot material on Google on this topic, just try to search using terms "how kernel detect a hardware" or "kernel plug and play" etc, try to use different queries and you will find lot of stuff.

Cheers,

Kind Regards,
Saqlain Abbas.

Hello List,

Is there any way to reverse map device name? /dev/sda to a the ata_host structure the drive is attached to?

I can go with a misc driver and register ata_host at AHCI? detectation time, but I would like to get ata_host pointer anytime I load my module.

Thanks

Cam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130819/56caab4d/attachment.html

What problem are you trying to solve with this reverse mapping?

(Hint - I'm not convinced that all devices named /dev/sd* have an ata_host structure. I'm reasonably sure that the large disk arrays I have on some systems at work are *not* ATA, as they present as SCSI fiberchannel devices.

% ls -l /dev/sdaaw
brw-r----- 1 root disk 133, 576 Aug 17 07:57 /dev/sdaaw

and dmesg tells me:

Vendor: IBM Model: DCS9550 Rev: 4.03
Type: Direct-Access ANSI SCSI revision: 05
sdaaw : very big device. try to use READ CAPACITY(16). SCSI device sdaaw: 15628087296 512-byte hdwr sectors (8001581 MB)
sdaaw: Write Protect is off
sdaaw: Mode Sense: a7 00 10 08
SCSI device sdaaw: drive cache: write through w/ FUA sdaaw : very big device. try to use READ CAPACITY(16). SCSI device sdaaw: 15628087296 512-byte hdwr sectors (8001581 MB)
sdaaw: Write Protect is off
sdaaw: Mode Sense: a7 00 10 08
SCSI device sdaaw: drive cache: write through w/ FUA
sdaaw: unknown partition table
sd 3:0:7:96: Attached scsi disk sdaaw
sd 3:0:7:96: Attached scsi generic sg731 type 0

I'm suspecting there's no ata_host involved here, as we never notice it as an ATA drive.

(And no, that device name isn't a boo-boo - the box really *does* have visibility to 768 8T LUNs (OK, so it's actually 8 fiberchannel paths to 96 LUNs. ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130820/cd0e09e9/attachment.bin

Yes, you are right not all drives are ata_host. But if you connect a SATA drive it is assigned ata_host

look at ahci driver and how it attaches to libata.

I am doing some custom work and I am not interested in recompiling kernel with

ahci and libata compiled separately.

Thanks

________________________________
From: "Valdis.Kletnieks at vt.edu" <[email protected]>
To: Com Developer <[email protected]>
Cc: kernelnewbies <[email protected]>
Sent: Monday, August 19, 2013 11:09 PM
Subject: Re: /dev/sda to ata_host

What problem are you trying to solve with this reverse mapping?

(Hint - I'm not convinced that all devices named /dev/sd* have an ata_host structure.? I'm reasonably sure that the large disk arrays I have on some systems at work are *not* ATA, as they present as SCSI fiberchannel devices.

% ls -l /dev/sdaaw
brw-r----- 1 root disk 133, 576 Aug 17 07:57 /dev/sdaaw

and dmesg tells me:

? Vendor: IBM? ? ? Model: DCS9550? ? ? ? ? Rev: 4.03
? Type:? Direct-Access? ? ? ? ? ? ? ? ? ? ? ANSI SCSI revision: 05 sdaaw : very big device. try to use READ CAPACITY(16). SCSI device sdaaw: 15628087296 512-byte hdwr sectors (8001581 MB)
sdaaw: Write Protect is off
sdaaw: Mode Sense: a7 00 10 08
SCSI device sdaaw: drive cache: write through w/ FUA sdaaw : very big device. try to use READ CAPACITY(16). SCSI device sdaaw: 15628087296 512-byte hdwr sectors (8001581 MB)
sdaaw: Write Protect is off
sdaaw: Mode Sense: a7 00 10 08
SCSI device sdaaw: drive cache: write through w/ FUA
sdaaw: unknown partition table
sd 3:0:7:96: Attached scsi disk sdaaw
sd 3:0:7:96: Attached scsi generic sg731 type 0

I'm suspecting there's no ata_host involved here, as we never notice it as an ATA drive.

(And no, that device name isn't a boo-boo - the box really *does*
have visibility to 768 8T LUNs (OK, so it's actually 8 fiberchannel
paths to 96 LUNs. ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130820/d8cc35d4/attachment-0001.html

That still doesn't actually explain what problem you're trying to solve
by finding the ata_host structure. I suspect it's something along the
lines of "Once I have the ata_host structure, then I can XYZ in order
to ABC". There's a very good chance that either (a) there's a better way
to XYZ already in-kernel, so there's no need to find the ata_host structure
first (and thus no easy way to do so), or (b) you probably should be doing DEF
instead of ABC.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130820/43492dd7/attachment.bin

Libata is a self admitted kludge.

/dev/sdx => scsi disk

Libata has stuck itself under the scsi disk driver, so you are right that not all scsi disks have a ata_host kludge, only the imposers should have one.

One path I have never chased is for an external usb connected drive. Scsi commands are sent a across the usb bus so there is probably not any libata involvement.

Greg

Sent from my Android phone with K-9 Mail. Please excuse my brevity.