4 o libdevmapper : comes with device-mapper-XXXX.tar.gz
6 o libsysfs : comes with sysutils
7 See ftp.kernel.org/pub/linux/utils/kernel/hotplug/
12 Fill the all_paths array. Each path store this info :
15 char dev[FILE_NAME_SIZE];
16 char sg_dev[FILE_NAME_SIZE];
17 struct scsi_idlun scsi_id;
23 scsi_id, sg_dev and sg_id are only really useful for 2.4
24 kernels, for which SG cmnds must go through sg devs.
25 In 2.5+ we have the nice opportunity to send SG cmnds
28 For 2.4 compat, we pivot on idlun tupple to map sg devs
31 2.4 does not do device enumeration, so we must scan a
32 defined number of sg devs and scsi bdevs. Good enough.
33 In 2.5+, we rely on libsysfs (sysutils) to access to
36 the wwid is retrieved by a switch fonction. Only White
37 Listed HW can filled this field. For now only
38 StorageWorks HW is White Listed. (See notes)
40 When all_paths is filled, we coalesce the paths and store
41 the result in mp array. Each mp is a struct like this :
46 int pindex[MAX_MP_PATHS];
49 When mp is filled, the device maps are fed to the kernel
50 through libdevmapper. Stale paths (failed TUR) are
56 o make sure you have enough /dev/sg* nodes
57 (/dev/MAKEDEV if necesary)
59 o path coalescing relies on a path unique id being found.
60 This unique id, lacking a standard method, is vendor
61 specific. A switch function (get_unique_id) is present
62 and an example function is provided for storageworks
63 arrays (get_storageworks_wwid). Feel free to enrich
64 with hardware you have at hand :)
66 o Something goes wrong with sd.o, qla2200 & dm-mod
67 refcounting : I can't unload these modules after exec.
69 o The kernel does NOT manage properly ghosts paths
70 with StorageWorks HW. Seems nobody cares after a load
71 of posts to linux-scsi.
73 o 2.4.21 version of DM does not like even segment size.
74 if you enconter pbs with this, upgrade DM.
79 o Heavy cut'n paste from sg_utils. Thanks goes to D.
81 o Light cut'n paste from dmsetup. Thanks Joe Thornber.
82 o Greg KH for the nice sysfs API.