Dotaz: Nalezení CD-ROM mechanik

[Jardík]

Potřeboval bych najít všechny CD-ROM mechaniky v systému. Zatím to dělám tak, že prohledávám adresář /dev, vybírám zařízení s názvy sg<číslo>, otevřu a přes ioctl pošlu SCSI_INQUIRY a pak testuju vrácená inquiry data, byte 1, bity 0-5 na hodnotu 0x05.

Jenže prohledávání /dev adresáře je docela pomalé, dochází tam k neustálému kopírování řetězců, a tak hledám nějaký lepší způsob.

---

---

Odpovědi

[ondrej]

Na debianu by ti mohl pomoct soubor /proc/sys/dev/cdrom/info

[ondrej]

prip /proc/diskstats

pokud pouzivas jine distro tak find /proc -name '*cd*'

[Jardík]

Nebudu kvůli tomu pouštět externí program. Zapomněl jsem to zmínit, ale pracuji v C/C++.

[Ondřej Kopka]

externi program ale spoustet vubec nemusis, find jsem uvedl jen pro pripad ze by u tebe byly cesty rozdilne, projdi si adresare /proc a /sys ...

[R]

To je zly postup. sg zariadenia tam vobec nemusia byt. Posielat nejake prikazy zariadeniam "len tak" tiez nie je vporiadku.

Skor by som pouzil /sys. Napr. /sys/block - v kazdom zariadeni pozriet, kam vediet symlink device/driver - (sr alebo ide-cdrom, mozno aj nieco ine).

[Jardík]

Jenže když se na to budu dívat takhle, tak tam nemusí být ani /sys/. Navíc s tím zařízením potom potřebuju dál něco dělat (posílat další SCSI příkazy) a tak ho nějak potřebuju otevřít. A nějak nejsem zastánce fixně velikých bufferů a jednorázového čtení celého souboru a spoléhat se na to, že se tam data vejdou (ze /sys/ a /proc/ jinak soubory snad číst nejdou). Nějaké systémové volání k tomu není, abych se vyhnul souborům úplně?

[R]

Ze chces jednemu zariadeniu posielat nejake prikazy, to nijako neospravedlnuje posielanie nejakych prikazov kazdemu zariadeniu.

V tom /sys nemusis citat ziadny subor. Staci ti readdir() a readlink().

[R]

A pripadne sa pozri na libsysfs.

[Jardík]

Ale já posílám příkazy jen zařízením sgXXX, což by měli být SCSI zařízení a každé SCSI zařízení musí INQUIRY příkaz podporovat. Ano, je tu moňost, že by tam mohlo být ne-SCSI zařízení, pokud si ho někdo takto pojmenuje.

readdir() neustále kopíruje název souboru do bufferu v dirent struktuře, navíc do fixního (256B), readlink vyžaduje fixní velikost bufferu a realokovat 10x buffer, pokud bude cílová cesta dlouhá je taky opruz.

libsysfs stejně čte /sys, cesta je tam hardcodována (jde sice přepsat proměnnou prostředí) a to už rovnou můžu hardcodovat /dev/sgXXX. To není jediné systémové volání na zjištění připojených zařízení?

[R]

Zariadenia sg sa vytvaraju aj pre USB mass storage - a pozri sa do jadra, kolko je tam workaroundov ohladne INQUIRY pri tychto zariadeniach.

Co sa stane, ak zariadenie prave vykonava nejaky prikaz a ty mu do toho nieco posles? Preco by mal nejaky program posielat prikazy vsetkym zariadeniam? Pripomina mi to programovanie ako vo Windows.

Inak ty mas nejaku uchylku na zbytocnu mikrooptimalizaciu? Kolkokrat stihne procesor nakopirovat tie retazce, kym ti nejake SCSI zariadenie odpovie na INQUIRY? Hint: moze to trvat niekolko sekund.

[Jardík]

Ano, ale flashka je SCSI zařízení, ačkoliv je připojena přes USB. A pokud snad něco vykonává, tak je tam snad nastaven nějaký zámek a dojde k timeoutu (?), který se u SCSI příkazu nastavuje.

[Ash]

Na SCSI_INQUIRY bych se vykašlal, budit všechna zařízení jen proto, že hldám CD je hloupost, to se dělá tak leda ve Windows. /sys musí stačit.

[Jardík]

Ve Windows SCSI_INQUIRY posílat právě nemusím na zjištění, jestli jde o CD-ROMKU, tam jsou na to funkce. Funkcí GetLogicalDrives() dostanu zařízení a funkcí GetVolumeType() dostanu info, jestli jde o CD-ROM, aniž by se požadavek posílal mechanice, protože to už Windows "ví".

Tak mi tedy řekněte, kde v /sys ty mechaniky najdu, sice něco najdu, ale ať tam hledám jak divej, nikde nenalézám symlink na zařízení /dev/sg*

[Ash]

Nevím bohužel jak v tom C, což samozř. chápu že je pro vás zásadní, nicméně v shellu třeba takto:

find /sys/devices -name 'media' | while read media; do
  [[ "$(<$media)" == "cdrom" ]] && echo "$media"
done

[Jardík]

find /sys/devices -name 'media' mi tu nenajde vůbec nic ...

[Ash]

Aha :( Když se sebezapřením použiji hal:

hal-device $(hal-find-by-capability --capability storage.cdrom) | grep sysfs

tak mi cdrom najde podle "capabilities". Je jich více: { 'storage', 'block', 'storage.cdrom' }

Ve vygrepovaném adresáři v sysfs sice také existuje soubor capabilities, ale tam je jen "19". Kdyby to znamenalo cdrom (nedaří se mi najít význam toho souboru či čísla) tak by to mohlo pomoct:

find /sys/devices -name 'capability' | while read capability; do [[ "$(<$capability)" == "19" ]] && echo "$capability" done

ale bohužel jsem z toho jinak jelen :(

[Ash]

A protože properties jsou koukám nepovinné, tak by bylo asi bezpečnější:

hal-device $(hal-find-by-property --key storage.drive_type --string cdrom) | grep sysfs

ale jinak tomu vůbec nerozumím (to asi nemusím říkat).

[Ash]

Oprava: A protože propertiescapabilities

[Jardík]

HAL je však to, čemu jsem se chtěl vyhnout.

Zatím jsem našel něco v /sys/bus/scsi/. Jsou tam adresy zařízení ve tvaru A:B:C:D. Když do toho kouknu, jsou tam mimo jiné i údaje z inquery struktury (vendor, model, rev, ...) včetně type (5 = CD-ROM). Dále v tom adresáři je adresář scsi_generic, v něm adresář sg1 atd. Jenže tam nikde nevidím link na soubor s zařízením, který bych byl schopen otevřít a posílat SCSI příkazy, což je můj cíl (tak trochu si hraju a chci se dopracovat ke smazání cédéčka).

[R]

Link tam nie je (pretoze moze byt lubovolny pocet suborov, ktore reprezentuju toto zariadenie) - ale v adresari block najdes subor dev, v ktorom je MAJOR a MINOR.

[Jardík]

Super, takže kromě prohledávání /sys budu ještě prohledávat /dev, na každý soubor dělat stat a zjišťovat major/minor, zkusit ho otevřít a prohledávat další, protože tam může být třeba 20x pokaždé s jiným oprávněním. Nebo spíš prohledat celý filesystém, co když si náhodou root vzpomněl zařízení vytvořit v uživatelově adresáři místo v dev. Tady je vidět hezké a přehledné "API" linuxu. Radši zůstanu u svého způsobu a počkám si na inquiry a budu předpokládat SCSI zařízení jako /dev/sgX, než trávit půl hodiny prohledáváním filesystému.

[Jardík]

... než trávit půl hodiny prohledáváním filesystému ... a stejně předpokládat 100 jiných věcí.

[R]

Dufam, ze sa s tvojimi programami nikdy nestretnem. Nechces to radsej urobit pre Windows?

[Ash]

To je řešení?blbost, musí to být v /sys/devices. HAL vám nenutím, měl sloužit jen k identifikaci problému.

Zatím je rozdíl v tom, že vy máte scsi a já ide cd-rom.

Chcete říct, že vám ten hal to zařízení v /sys/devices nenašel?

Osobně mám v /sys/devices jak ide tak scsi zařízení.

[Jardík]

IDE CD-ROM stejně používá SCSI rozhraní ke komunikaci, já mám SATA.

Ano, HAL mi věnuje řádek s /sys/devices/pci0000:00/0000:00:1f.2/host1/target11:0:0/1:0:0:0/block/sr0, ale z toho taky nedostanu cestu k zařízení. Navíc zařízení /dev/sr0 nemůžu SCSI příkazy posílat, jeho otevřením se totiž otevře to médium, co tam je, musí se otevřít generické scsi zařízení /dev/sgX.

Škoda, že se kvůli debilní licenci nemůžu podívat do zdrojáků cdrecordu nebo wodimu. Zkusím naně strace ... á, někdo si může stěžovat na můj přístup, co dělá wodim. Zkouší otevírat všechna zařízení /dev/hda až /dev/hdz, /dev/scd1 až /dev/scd255 a pokud se je podaří otevřít, posílá jim SCSI příkazy. Takže opravdu zůstanu u svého způsobu, když to jinak očividně nejde.

Taky nechápu, proč wodim používá flag O_EXCL pro volání open() bez O_CREAT, když manuálová stránka píše, že je pak výsledek nedefinovaný.

[Petr Šobáň]

Já si taky myslím že přes hal je to nejednoduší, než prohledávat hromadu adresářů.

Mě příkaz: "hal-device $(hal-find-by-property --key storage.drive_type --string cdrom) | grep sysfs" cdrom najde viz:

[petr@nt /sys/devices]$ hal-device $(hal-find-by-property --key storage.drive_type --string cdrom) | grep sysfs
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:11.0/host1/target1:0:0/1:0:0:0/block/sr0'  (string)
[petr@nt /sys/devices]$ 

[Jardík]

Jak jsem řekl, výsledek tohoto příkazu mi je k ničemu, protože mi nedá link na SCSI zařízení a v tom adresáři to taky nikde není. Navíc by to znamenalo závislost na obludě jménem HAL, a která je navíc označena za deprecated.

[Petr Šobáň]

Jasně já v tom neporadím, prostě buď to budeš muset skoušet a nebo použít ten hal a potom předpokládat že /dev/srX = /dev/sgX ovšem já nemám víc mechanik abych to testnul zda to platí.

[Jardík]

To neplatí, mechaniku mám sr0, ale sg0 je můj pevný disk.

[Ash]

No já nevím, ale podle mně platí to co řekl R,

Link tam nie je (pretoze moze byt lubovolny pocet suborov, ktore reprezentuju toto zariadenie) - ale v adresari block najdes subor dev, v ktorom je MAJOR a MINOR.

vám sice následně ruply nervy, ale osobně nepovažuji za velký problém projít těch pár AKTIVNÍCH sg zařízení, otevřít pár souborů dev a přečíst si major a minor, čímž mám /dev/srX (v případě scsi).

Zkuste mrknout na sg_map, v nové verzi pracuje se sysfs.

$ sg_map

# Note: the devfs pseudo file system is present

/dev/sg0 /dev/sda

/dev/sg1 /dev/sr0

/dev/sg2 /dev/sr1

Samozřejmě je pořád možnost dělat to postaru, pokud jste pod tlakem.

[Ash]

Vemte si (nevím pro co to programujete) ale asi nebude připojených těch mechanik 50, ne? A i kdyby, otevřít padesát souborů ještě nikoho nezabilo.

[Ash]

Ta novější verze se jmenuje sg_map26 (See the sg_map26 utility for a more precise way (i.e. less directory scanning) for mapping between sg device names and higher level names; including finding user defined names.)

[Jardík]

Ještě na to kouknu. Asi udělám kompromis - kouknu do /sys/bus/scsi/devices, tam vyhledám všechny adresáře ve formátu U:V:X:Y, tam vezmu typ (5=CDROM), kouknu do scsi_generic, kde je u mě jediný adresář (např. sg1), v tom mám soubor dev, kde je major:minor, pak podle toho adresáře (sg1) zkusím otevřít stat na /dev/sg1, pokud budou sedět major/minor a typ souboru device, tak otevřu (nebo otevřít a pak fstat()?) a inquiry pošlu pak k ověření a dále s ním budu pracovat. A pokud tam sg zařízení nebude (např. ho někdo smazal a udělal si ho v /home (paranoia )), tak smůla.

A může mi někdo ještě osvětlit atribut O_EXCL u open(), když není uveden O_CREAT? V manuálové stránce se popisuje nedefinované chování, ale wodim/cdrecord ho tak používají.

[R]

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=262678

[Ash]

Pro jistotu zopakuji že HAL jsem se sebezapřením použil jen jako nástroj univerzální komunikace schopný (jednorázově) najít tazatelovu scsi cdromku a její cestu v sysfs, abychom se pohnuli dále. Jinak samozřejmě HAL je přesně ten, kdo suverénně budí na co sáhne. Je možná zábavné sledovat, jak když se spustí hal, rozjíždí se všechny externí disky (a že na firewire jich může být zapojených hodně), zavrní cdromky, zablikají skenery, vrata od garáže se otevřou a zavřou, no trochu přeháním ale každopádně příklad hodný následování to není :)

[Jardík]

Fuj, tak jsem to tak udělal a můžu říct jedno - je to prasárna Hledání CD-ROM mechanik a jejich vložení do seznamu má ve Windows verzi 34 řádků (počítám i řádky, které mají jen otevírací/uzavírací závorky {,}).

V Linuxové verzi jsem teď na 174 řádcích a teď zbývá ještě dopsat kód na prohledání celého /dev pro případ, že zařízení /dev/jméno_co_se_našlo_v_sysfs neexistuje, nebo se jeho major/minor neshoduje s tím v /sys.

Kdyby někoho zajímalo, jak to vypadá ve Windows:

  TSCSIDrive *drive;
  TSCSIDrive tmpDrive;
  uint8_t device_type;
  
  /*
   * Using GetLogicalDrives() could speed up things, but there is always
   * possibility, that drive has no letter assigned, is mounted to NTFS
   * folder or it is not even mounted. This way we handle all these cases.
   */
  HANDLE hVolumeSearch;
  /*
   * Volume name is in "\\?\Volume{ITS_GUID}\" format,
   * GUID's format is AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA
   */
  WCHAR volumeName[MAX_PATH];
  
  hVolumeSearch = FindFirstVolumeW(volumeName, MAX_PATH);
  
  if (hVolumeSearch != INVALID_HANDLE_VALUE)
  {
    do
    {
      volumeName[MAX_PATH-1] = 0;
      
      if (GetDriveTypeW(volumeName) == DRIVE_CDROM)
      {
        tmpDrive._open_fn = volumeName;
        
        // remove trailing slash so that we open drive itself and not
        // the medium inserted
        if (tmpDrive._open_fn[tmpDrive._open_fn.size()-1] == '\\')
        {
          tmpDrive._open_fn.erase(tmpDrive._open_fn.size()-1);
        }
        
        if (tmpDrive.openDrive())
        {
          tmpDrive.setTimeout(10);
          
          // request inquiry data and make sure OS didn't lie to us
          if (tmpDrive.inquiry(tmpDrive._inqData, TSCSIDrive::INQUIRY_DATA_SIZE))
          {
            device_type = (tmpDrive._inqData[0] & 0x1F);
            
            if (device_type == 0x05 /* CD-ROM */)
            {
              drive = new TSCSIDrive();
              tmpDrive.readScsiAddress(drive->_address);
              drive->_open_fn = std::move(tmpDrive._open_fn);
              memcpy(drive->_inqData, tmpDrive._inqData, TSCSIDrive::INQUIRY_DATA_SIZE);
              _drives.push_back(drive);
            }
          }
          tmpDrive.closeDrive();
        }
        tmpDrive._open_fn.clear();
      }
    
    } while (FindNextVolumeW(hVolumeSearch, volumeName, MAX_PATH));
    
    FindVolumeClose(hVolumeSearch);
  }

[Ash]

Asi proto člověk občas vidí system("lsscsi | grep ...") :)

[Jardík]

Takový program (lsscsi) však nemám a byla by to další závislost (já vím, že jsem s tím už trapnej, ale to jsem prostě já )

[kralyk z abclinuxu]

Můžeš ten prográmek/knihovnu k tomu přibalit (á la windoze), a basta. Tím by ses imho ani nedostal do konfliktu s GPL, pokud vím. Ale nejsem právník.

[Ash]

Však jo, tohle rozhodně neměl být příklad lepšího řešení :) A nejedná se o knihovnu, takže v céčkovém programu je to stejně nanic.

[Jardík]

Tak spustit příkaz z Céčkového programu a parsovat jeho výstup není problém, ale jestli mám parsovat nějaký výstup, nebo prohledávat sys, to už vyjde na stejno.

[zulu]

174 řádků? Ukaž nám ten kód, ať se zasmějem.

[maertien]

Coz prolejzat /proc/ide/* ???

[Jardík]

Já se teď nemůžu podívat, ale bude tam i SATA mechanika?

[Ash]

Na proc se vykašlete když máme sysfs.

Vizte Documentation/sysfs-rules.txt a další.

[Ash]

Jinak vykašlete == jednak on má scsi, čili /proc/scsi, a potom to není spolehlivé u zařízení připojených za chodu, a takových je dneska hodně.

[maertien]

Jiste - /proc/scsci/* . Neprecetl jsem si tazateluv dotaz poradne. A je fakt, ze proc je v tomto kontextu jiz mirne obsoletni.

[kralyk z abclinuxu]

Buď bych zkusil něco v /proc/scsi, ale být tebou spíš od filesystému upustím.

Když se podíváš do dmesg, tak v něm jsou většinou příslušný devices vypsaný.
Jsem přesvědčen, že bude v linuxu existovat nějaká knihovna či rozhraní systému, která ti umožní SCSI devices vylistovat.

Zkustil jsem namátkou pár příkazů (velmi hrubé info - potřeba googlovat):

vojta|vojta-dell ~ $> pkg-config --list-all | grep -i cd
libcdt                           libcdt - Container DataType library
libudf                           libudf - UDF library of libcdio
libcdio++                        libcdio++ - C++ OO Portable CD-ROM I/O library
libcdio                          libcdio - Portable CD-ROM I/O library
libiso9660++                     libiso9660++ - C++ OO ISO-9660 library of libcdio
libiso9660                       libiso9660 - ISO-9660 library of libcdio
gstreamer-cdda-0.10              GStreamer CDDA Library - CDDA base classes
libcdio_cdda                     libcdio_cdda - CD paranoia CD-DA library from libcdio
libcdio_paranoia                 libcdio_paranoia - CD paranoia library from libcdio
libcddb                          libcddb - CDDB server access library

vojta|vojta-dell ~ $> pkg-config --list-all | grep -i devic
libgphoto2_port                  libgphoto2_port - Device-independent access to serial, USB, and other ports
devkit-power-gobject             devkit-power-gobject - DeviceKit-power is a system daemon for installing stuff.
gnome-bluetooth-1.0              gnome-bluetooth-1.0 - Widgets for Bluetooth device selection
usbutils                         usbutils - USB device database
libmtp                           libmtp - libmtp is a library for accessing Media Transfer Protocol devices
devmapper-event                  devmapper-event - device-mapper event library
pciaccess                        pciaccess - Library providing generic access to the PCI bus and devices.
libsynce                         libsynce - A helper library for SynCE, a framework to sync WinCE devices
libavdevice                      libavdevice - FFmpeg device handling library
DeviceKit-disks                  DeviceKit-disks - DeviceKit-disks daemon
blkid                            blkid - Block device id library
devmapper                        devmapper - device-mapper library
libv4l2                          libv4l2 - v4l2 device access library
hal-storage                      hal-storage - hal library for storage devices and volumes
libudev                          libudev - Library to access udev device information

vojta|vojta-dell ~ $> pkg-config --list-all | grep -i dvd
dvdread                          libdvdread - Low level DVD access library
dvdnavmini                       libdvdnavmini - DVD Navigation mini library
libdvdcss                        libdvdcss - DVD access and decryption library.
dvdnav                           libdvdnav - DVD Navigation library
vojta|vojta-dell ~ $>

Především ta prostřední skupina mi přijde zajímavá.
Případně se můžeš podívat do zdrojáků různých nástrojů na zjišťování info o HW (např. hwd a mnoho dalších...).

Dále by tvým rádcem mohlo být toto hledání

Určitě existuje způsob, jak tohle řešit lépe, než prohledáváním filesystému (ať už v /dev, /sys, nebo /proc), už jen ten způsob najít
To, co jsem ti tu vypsal, jen výsledek asi pětiminutového "výzkumu", tudíž nečekej zázraky...

[kralyk z abclinuxu]

Jo, a ještě můžeš oblígátně použít google, chce to vhodný dotaz.
Například tento nebo tento.

[Jardík]

Já ty SCSI tutoriály právě četl, nějaké od IBM a pod, ale nikde tam nepíšou o nalezení, jen otevři zařízení /dev/sg0 a dělej co je tu napsáno

[Ash]

Šmarjá, asi koupím flintu a pudu na zajíce.

/proc/scsi fakt ne, tam nemáš jistotu že budou zařízení připojená za chodu. Už jsem to tu dvakrát říkal.

Jo, vylistovat scsi zařízení můžeš, jsou všechna nečekaně v /sys/devices.

Utilita tu už taky byla, jmenuje se sg_map. Nová verze sg_map26 překvapivě funguje nad /sys... Takže pokud nepoužíváš jádro 2.4...

Hovoříš o linuxu a máš něco proti souborům? Dobré ráno. V linuxu je všechno důležité soubor, a pokud ne soubor, tak alespoň virtuální filesystém. sysfs je standardní rozhraní a má světlou budoucnost (TM).

V linuxu to takto prostě funguje, filesystém a soubory jsou rozhraní k jádru, zařízením a dalším věcem. Je to základní princip fungování, ne něco špatného či nevhodného. Není lepší způsob, protože sysfs není špatný způsob.

Pět minut je fakt málo.

[kralyk z abclinuxu]

Se uklidni prosimtě, já proti filosofii "everything is file" rozhodně nic nemám.

Tím "prolejzáním filesystému" jsem myslel zmíněnou metodu vylistování /dev nebo volání různých find někde na /proc nebo /sys, to je prostě blbost.

Další věc je, že občas člověk skutečně nemusí vynalézat kolo. Tedy nemá smysl psát parser struktury sysfs (nebo něčeho jiného), když (třeba, nevim) existuje odladěná a spolehlivá knihovna pro tenhle účel.
Někdy ovčem člověk vynalézat kolo z cvičných důvodů chce, a proti tomu nic nemám (bez ironie, sám to často dělám...)

[Jardík]

Jenže knihovna = závislost a tím pádem nutnost ji instalovat kvůli jinému programu. Pak z toho vyjde prasárnička typu Hello World! v KDE, kdy kvůli jedné aplikaci, co ukáže okno s nápisem musíte instalovat půl giga závislostí.

[Jardík]

Navíc ta knihovna má špatnou licenci (tj. není pod licencí Do what the fuck you want to public license)

[Ash]

Od toho knihovny jsou, aby se přidávaly k hlavnímu programu jakožto odladěná znovupoužitelná věc. To o čem mluvíte je spíš přidat jako závislost třeba nějaký nástroj pro "hledání dvd, vypalování iso obrazů a tisk popisků DVD", to je samozřejmě špatně, ale přidat si knihovnu pro procházení sysfs, proč ne, když bude mít nějaké pěkné rozhraní. Nesmí to vést k taovému tomu "najdi mi tohle" chrocht chrocht, jo a "ještě tohle" chrocht chrocht, zatímco ve vlastním kódu by si to člověk promyslel a pak našel na jeden zátah výrazně efektivněji (asi neplatí zrovna pro sysfs, je malej, tam to je hned).