From: Alex S. <ml...@os...> - 2009-09-04 08:52:52
|
Hello, i`m still working on moving from CONTROLLER_* constants in os_freebsd.cpp to the new interface and now I found references about "sat" device type. Is it really used on BSD or is a copy-paste from linux? I see that it is referenced in 5.38 also, but i don`t see any code working with it. |
From: Christian F. <Chr...@t-...> - 2009-09-04 09:23:39
|
Alex Samorukov wrote: > i`m still working on moving from CONTROLLER_* constants in > os_freebsd.cpp to the new interface and now I found references about > "sat" device type. Is it really used on BSD or is a copy-paste from > linux? I see that it is referenced in 5.38 also, but i don`t see any > code working with it. > > The "-d sat" and "-d usb*" options are handled in the OS independent default implementation of smart_interface::get_smart_device(). If SAT works through the default SCSI ("-d scsi") I/O control, there should be no need to handle "-d sat" in freebsd_smart_interface::get_custom_smart_device(). Cheers, Christian PS: Could you please put related changes (e.g. os_freebsd.cpp+CHANGELOG) in one single svn commit? These are easier to review then. |
From: Alex S. <ml...@os...> - 2009-09-04 09:48:48
|
Christian Franke wrote: > Alex Samorukov wrote: >> i`m still working on moving from CONTROLLER_* constants in >> os_freebsd.cpp to the new interface and now I found references about >> "sat" device type. Is it really used on BSD or is a copy-paste from >> linux? I see that it is referenced in 5.38 also, but i don`t see any >> code working with it. >> >> > > The "-d sat" and "-d usb*" options are handled in the OS independent > default implementation of smart_interface::get_smart_device(). > > If SAT works through the default SCSI ("-d scsi") I/O control, there > should be no need to handle "-d sat" in > freebsd_smart_interface::get_custom_smart_device(). Yes, found that. For now it should work correctly. BTW, I found that usb* device types are not exported to the help, i did ticket in the TRAC for this. > > PS: Could you please put related changes (e.g. > os_freebsd.cpp+CHANGELOG) in one single svn commit? These are easier > to review then. Ok, i`ll do. |
From: Dan L. <da...@ob...> - 2009-09-04 09:32:58
|
Alex Samorukov napsal/wrote, On 09/04/09 10:52: > i`m still working on moving from CONTROLLER_* constants in > os_freebsd.cpp to the new interface and now I found references about > "sat" device type. Is it really used on BSD It returned from parse_ata_chan_dev() when user manually specified type (-d sat). The return code is then used in freebsd_smart_device::open() where mean "known controller that doesn't require controller-type specific handling here". You can discard such constant, bud you need another constant with the similar meaning unless you rewrite the freebsd_smart_device::open() logic. Dan |
From: Alex S. <ml...@os...> - 2009-09-04 09:44:45
|
Dan Lukes wrote: > Alex Samorukov napsal/wrote, On 09/04/09 10:52: > >> i`m still working on moving from CONTROLLER_* constants in >> os_freebsd.cpp to the new interface and now I found references about >> "sat" device type. Is it really used on BSD >> > > It returned from parse_ata_chan_dev() when user manually specified type > (-d sat). > > The return code is then used in freebsd_smart_device::open() where mean > "known controller that doesn't require controller-type specific handling > here". > > You can discard such constant, bud you need another constant with the > similar meaning unless you rewrite the freebsd_smart_device::open() logic. > > Thanks, already found this. Yes, my final goal is to rewrite logic of the guess_type and open to be more like to os_linux.cpp. Also I did USB autodetection for the FreeBSD8 (completely different USB stack) and commited patches from the freebsd port. When i will have some time i`ll try to convert existing logic to something more readable. |
From: Dan L. <da...@ob...> - 2009-09-04 10:04:40
|
Alex Samorukov napsal/wrote, On 09/04/09 11:44: >>> i`m still working on moving from CONTROLLER_* constants in >>> os_freebsd.cpp to the new interface and now I found references about >>> "sat" device type. > Yes, my final goal is to rewrite logic of the guess_type and open to be > more like to os_linux.cpp I didn't monitor the progress of os_linux.cpp so much. Do Linux's gueess device type from /dev/* entry name ? If yes, then we shall not follow such way. We can use system enumeration to found devices (and indirectly - device types as well) - see os_freebsd.cpp:get_dev_names_{ata|scsi}() It's more flexible way. > Also I did USB autodetection for the FreeBSD8 (completely different USB stack) I hope I will found the reason why USB devices are not reachable via standard CAM (SCSI) layer. When patched then nobody needs distinguish USB devices as special case. Also, SAT devices should be accessible as standard ATAPICAM devices, but it's long run way now. > When i will have some time i`ll try to convert existing logic to > something more readable. I tried it, but failed. I have no sufficient experience with object-oriented programming. Dan |
From: Dan L. <da...@ob...> - 2009-09-04 11:10:01
|
Alex Samorukov napsal/wrote, On 09/04/09 12:15: >> Do Linux's gueess device type from /dev/* entry name ? If yes, then we shall not >> follow such way. >> >> > We already using this way in os_freebsd if there is no -d switch. More > than this - even with -d switch we are using device names to find 3ware > controller type (there are 3 different types, mapped to twa or twe nodes). It seems to be a misunderstanding. I told we should avoid to use device names for detection of device type. I know this is the method currently used in os_freebsd.cpp, but if you are going to rewrite such code then I wish you will move off from this hack as much as possible. Well, it may be the only available method in some cases, but it should be last-resort method. I don't know if the twa/twe is such case. >> It's more flexible way. >> > I think they are currently used in the smartd. Yes and should be used in smartctl also, IMHO. >> >>> Also I did USB autodetection for the FreeBSD8 (completely different >>> USB stack) >>> >> >> I hope I will found the reason why USB devices are not reachable via >> standard CAM (SCSI) layer. When patched then nobody needs distinguish >> USB devices as special case. >> > They ARE accessible. It seems we have different meaning of "accesible". I'm not speaking about "is mountable as a data volume" - it works, of course. We are speaking about smartmontools, so I mean "accesible for smartmontools functions". The USB devices I have can't be acceses as common SCSI devices (e.g. with -d scsi) using current CAM layer. > But some of them need to be distinguish as special > case because they use different driver (e.g. usbsubnplus which i own), It is CAM (Common access layer) responsibility to hide differences between underlying implementations. It's what FreeBSD have CAM/SCSI layer for. So "special cases" should be handled here, primarily. Dan |
From: Alex S. <ml...@os...> - 2009-09-04 11:35:06
|
Dan Lukes wrote: > > It seems to be a misunderstanding. I told we should avoid to use device > names for detection of device type. I know this is the method currently > used in os_freebsd.cpp, but if you are going to rewrite such code then I > wish you will move off from this hack as much as possible. > > Well, it may be the only available method in some cases, but it should > be last-resort method. I don't know if the twa/twe is such case. > > Yes, thanks for the idea. I think that auto-detection (no -d type) algorithm should be done this way: 1) get device name from user (e.g. /dev/ad0) 2) ask ATA and SCSI enumerators do they know anything about this device name. 3) If it is ATA - treat device as ATA. 4) If it is SCSI - check if we have corresponding umass* device and get type from USB vid/pid, or return it as scsi dev. 5) If it is !scsi && !ide - check if name is like cissN, tweN, twaN and if it is - write message about wrong syntax (-d should be used). 6) Return unknown device error if nothing is found. > Yes and should be used in smartctl also, IMHO. > Yes, i don`t see any potential problems with this method. > > >>> I hope I will found the reason why USB devices are not reachable via >>> standard CAM (SCSI) layer. When patched then nobody needs distinguish >>> USB devices as special case. >>> >>> >> They ARE accessible. >> > > It seems we have different meaning of "accesible". I'm not speaking > about "is mountable as a data volume" - it works, of course. We are > speaking about smartmontools, so I mean "accesible for smartmontools > functions". > > The USB devices I have can't be acceses as common SCSI devices (e.g. > with -d scsi) using current CAM layer. > They should not be accessible as common scsi devices, because they are not :) There are different USB bridges. Some of them are using standard SAT translation, some - internal pass through interface (usbsunplus, jmicron) and some are not supported at all. See usb_ids[] array in the scsiata.cpp for more details. I have only usbsunplus device and it works perfectly with smartctl-svn (tested on FBSD 7 and 8), of course using cam-scsi pass through (-d usbsunplus or USB auto-detection). Please, tell me usb vid/pid of your device to check if it is supported at all. > > It is CAM (Common access layer) responsibility to hide differences > between underlying implementations. It's what FreeBSD have CAM/SCSI > layer for. So "special cases" should be handled here, primarily. > CAM is not responsible to provide ATA path thrue at all. But it provides interface to implement it using standard scsi functions. |
From: Dan L. <da...@ob...> - 2009-09-04 14:46:21
|
Alex Samorukov napsal/wrote, On 09/04/09 13:35: > I think that auto-detection (no -d type) algorithm should be done this way: > 1) get device name from user (e.g. /dev/ad0) > 2) ask ATA and SCSI enumerators do they know anything about this device > name. > 3) If it is ATA - treat device as ATA. > 4) If it is SCSI - check if we have corresponding umass* device and get > type from USB vid/pid, or return it as scsi dev. > 5) If it is !scsi && !ide - check if name is like cissN, tweN, twaN and > if it is - write message about wrong syntax (-d should be used). > 6) Return unknown device error if nothing is found. It sounds good. By the way, the ciss/twe/twe class drivers should expose the "passX" devices that allow (limited) communication with underlying disc. It's the clean way how to expose such disc to application. Yes, I know they doesn't offer them, so '-d' workaround is required now, but it's ugly hack. Dan P.S. rest of discussion is going off-topic here, so I will respond in separate mail only to you. |
From: Alex S. <ml...@os...> - 2009-09-04 10:15:07
|
Dan Lukes wrote: > Alex Samorukov napsal/wrote, On 09/04/09 11:44: > >>>> i`m still working on moving from CONTROLLER_* constants in >>>> os_freebsd.cpp to the new interface and now I found references about >>>> "sat" device type. >>>> > > >> Yes, my final goal is to rewrite logic of the guess_type and open to be >> more like to os_linux.cpp >> > > I didn't monitor the progress of os_linux.cpp so much. Do Linux's gueess > device type from /dev/* entry name ? If yes, then we shall not follow > such way. > > We already using this way in os_freebsd if there is no -d switch. More than this - even with -d switch we are using device names to find 3ware controller type (there are 3 different types, mapped to twa or twe nodes). > We can use system enumeration to found devices (and indirectly - device > types as well) - see os_freebsd.cpp:get_dev_names_{ata|scsi}() > > It's more flexible way. > I think they are currently used in the smartd. > >> Also I did USB autodetection for the FreeBSD8 (completely different USB stack) >> > > I hope I will found the reason why USB devices are not reachable via > standard CAM (SCSI) layer. When patched then nobody needs distinguish > USB devices as special case. > They ARE accessible. But some of them need to be distinguish as special case because they use different driver (e.g. usbsubnplus which i own), so there is usb vid/pid table with mapping to sat or usb* drivers. So we need to interact with USB stack to know vid/pid of the da* device. |