BurnApp

8.6.2010 13:25 | Přečteno: 1271× | Jiné | poslední úprava: 8.6.2010 15:03

Buď jsem fakt blbej, nebo ten způsob přístupu k zařízení je fakt na palici.

Problém 1. Místo nějakého hezkého systémového volání musím k enumeraci zařízení jak debil procházet /sys/. To bych ještě přežil. Další problém je, že tam je jenom "kernel name" zařízení - buď jen blokového (srX), popř. ještě generic SCSI device (sgX). Pak tam ještě najdu major:minor čísla zařízení. Pak nastávají 2 možnosti:

• Tipnu si název zařízení (např. pro sr0 zkusím /dev/sr0), pokud zařízení neexistuje, nebo se jeho major:minor neshoduje, přejdu k dalšímu bodu.
• Požádám udev o přeložení major:minor na soubor se zařízením (např. /dev/sr0)

Otázkou je, jestli není lepší rovnou enumerovat zařízení pomocí udevu ... asi ano a na procházení /sys se vykašlu.

Problém 2 Detekce připojení/odpojení zařízení, výměny média, ... Pro detekci připojení/odpojení hlídám /proc/self/mountinfo, pro detekci nového zařízení, odebrání zařízení (např. USB palírny) používám udev. Při změně média mě taky informuje udev - problém udev informuje jen o změně média pro zařízení srX, né však o změně sgX.

Po změně zařízení se kouknu (v druhém threadu, abych neblokoval GUI), jestli je tam médium, popř. jaké médium tam je. Problém - otevřít srX nebo sgX

V případě srX si můžu dovolit posílat SCSI příkazy pouze přes ioctl(), které vždycky blokuje - a když něco mechaniku používá (např. HAL nebo udisk, když se marně snaží provádět heuristiku média, tak mi zablokuje thread, který zjišťuje typ média a ani pthread_kill nepomůže ioctl() přerušit, i když podle manuálu ioctl() je signálem přerušeno.

V případě zařízení sgX můžu SCSI příkazy posílat přes neblokující write() a read(), použít poll() a pokud to trvá dlouho, můžu to prostě zrušit (tj. nevolat read() a zavřít zařízení). Ale je tu problém - když už nějaký program vypaluje přes zařízení srX, tak i když má exkluzivní přístup, mně je umožněno si otevřít zařízení sgX taky pro exkluzivní přístup a zavolat nějaký příkaz, by se mohlo rovnat podělání vypalování (TEST UNIT READY by sice nic zkazit nemělo, ale o tom, jestli něco vyvede GET CONFIGURATION (pro zjištění typu média), už nic dokumentace neříká).

Takže - zatím to vypadá na hybrida - vše budu provádět přes zařízení sgX (tak to dělá např. Nero), ale zároveň si pro exkluzivní přístup otevřu srX zařízení, aby mi další programy (cdrecord, dvd+rwtools, HAL, udisk) nepodělávaly vypalování. Škoda, zatím jsem nenašel žádný způsob, jak zabránit přístupu přes druhé zařízení, když používám to první. Ve Windows je např. k tomuto účelu IOCTL_CDROM_EXCLUSIVE_ACCESS, kdy mi žádný jiný program nebude kecat do vypalování (a popř. ani já jemu). V Linuxu je však API asi značně omezeno a asi se předpokládá, že si uživatel nespustí 2 takové programy, nebo fakt nevím. V případě hybridního přístupu bych musel v případě nepřítomnosti "scsi_generic" modulu přistupovat jen přes srX zařízení - to je další kompikace, se srX můžu, jak jsem již řekl, pouze blokující ioctl() = zablokování vlákna, když bude HAL/udisk provádět svoje prasárničky.

CHANGELOG:
20100608-1502 - opraveno pár chybek

       

Komentáře

[pc2005]

Holt vývoj typu bazar . Ale já bych si asi udělal speciální mezivrstvu a dál bych se o to nestaral.

[Jardík]

Tak všaku tu taky dělám (bude to pro Windows a Linux), ale potřebuju, aby fungovala ...

[pc2005]

Njn ale nic co by nešlo řešit pomocí semaforů, cyklů a vláken .

[Vojta Drbohlav]

Nejde k enumeraci zařízení použít taky udev s vyhledáváním podle major a minor čísel? Já pro enumeraci sériových portů v PC používám tenhle kód:

{
	QStringList ret;
	struct udev * udev = udev_new();

	if(udev == NULL)
	{
		qCritical() << "udev_new() failed";
		return ret;
	}

	for(quint8 minor = 64; minor <= 255; ++minor)
	{
		struct udev_device * udev_device = udev_device_new_from_devnum(udev, 'c', makedev(4, minor));
		if(udev_device != NULL)
		{
			ret.append(udev_device_get_devnode(udev_device));
			udev_device_unref(udev_device);
		}
		else
			break;
	}

	udev_unref(udev);

	return ret;
}

Seznam a vysvětlení major čísel je v dokumentaci kernelu.

[Jardík]

Viz druhý odstavec, druhý puntík:

Požádám udev o přeložení major:minor na soubor se zařízením (např. /dev/sr0)

Tím jsem měl na mysli právě použitím udev_device_new_from_devnum

[Grunt]

Co zamykání souborů? To by nepomohlo?

[Jardík]

To jsem nezkoušel, ale i kdyby to fungovalo, tak bych pravděpodobně musel stejně zamknout oba. Vyzkouším, díky za tip.

[Grunt]

Co oba? Když prostě nechceš aby ti do souboru nikdo lezl, zamkneš si ho pro svůj proces (dá se zamknout pro čtení a zápis zvlášť) a hotovo. Dokuď neodemkneš tak mají jiní smůlu. Ale nevím jestli to bude fungovat pro blokové zařízení. No ale nějak to musí mít současné vypalovací programy řešené. Proč nemrkneš do nich? Tady nejsi na Windech.

[Grunt]

Jinak je to docela zajímavé. Jak by se to vlastně teďka mělo dělat? Dřív se člověk zeptal HALu a odtud dostal všechny vypalovačky, včetně jmen, schopností, blokových zařízení, atd. Ale jak se to má dělat teď když byl HAL označen za zastaralý a má se na to používat udev?

[DjAARA]

Co se podívat po možnostech DeviceKit-u. Měl by sloužit jako náhrada HAL-u pro oblast zařízení.

[Jardík]

DeviceKit byl přejmenován na udisks.

[Grunt]

It is in the process of being merged into udev (main udev, libudev, and udev-extras) and existing udev and kernel functionality. Initially a new daemon DeviceKit was planned to replace certain aspects of HAL, but in March 2009, DeviceKit was deprecated in favor of adding the same code to udev as a package: udev-extras, and some functions have now moved to udev proper.

[DjAARA]

Bože, to by s jedním seklo jak rychle jsou nové věci deprecated.

[Grunt]

O to líp. Pokud bude místo deseti démonů stačit jeden, který už ke všemu téměř všude je a ještě to bude tak jednoduché, tak čím dřív tím líp.

[Jardík]

Udev pro základní věcičky, popř. udisks pro seznam schopností a tak. Problém udisku - závislost na glib a gdbus, komunikace přes hnusné dbus zprávy. Pro zjištění typu média a schopností si radši pošlu pár SCSI příkazů a mám jistotu, že si udisk nevymýšlí, navíc řeší hodinovou heuristikou kraviny typu prázdného DVD+RW když se po prvním naformátování už nikdy nejeví jako "fyzicky" prázdné.

[Grunt]

udisks

According to DeviceKit devel mailing list, DeviceKit is getting merged with udev-extra and the existing DeviceKit programs such as DeviceKit-disks and DeviceKit-power will be switched over to use libudev.

Takže by bylo fajn se začít poohlížet jak se vlastně vůbec pracuje s libudev. Jinak by ale na toto měl snad mít Qt svoje serepetičky, ne?

[Grunt]

Čoveče, ono to asi nebude zas taková hrůza jak se na první pohled může zdát. Takže na /sys rozhodně kašli, to je pro low-level, ne pro tebe.

[kralyk z abclinuxu]

Jo, tohle jsem už Jardíkovi taky linkoval několik měsíců zpátky Takže buď udělal někde chybu, nebo udev potřebné schopnosti nemá. Každopádně stále je možné prostě počkat, než to vývojáři všechno do udevu namergují. Imho by to nemělo trvat zas tak strašně dlouho.

Problém ale bude určitě v tom, že distribucím bude dost dlouho trvat, než nový model přijmou. Například Arch stále ještě jede na HALu. Nebo prostě bude někdo mít nainstalovanou starší verzi nějaké konzervativní ditribuce s HALem, a bude problém...

[Jardík]

Jó no, ona to fakt taková hrůza není

void bla()
{
  struct udev_enumerate* enumerate = udev_enumerate_new(_udev);
  if (!enumerate) return;
  
  udev_enumerate_add_match_subsystem(enumerate, "block");
  if (udev_enumerate_scan_devices(enumerate) == 0)
  {
    struct udev_list_entry *e;
    const char *syspath, *prop;
    struct udev_device *dev, *parent_dev;
    
    e = udev_enumerate_get_list_entry(enumerate);
    while (e)
    {
      syspath = udev_list_entry_get_name(e);
      
      dev = udev_device_new_from_syspath(_udev, syspath);
      if (dev)
      {
        prop = udev_device_get_property_value(dev, "ID_TYPE");
        if (prop && strcmp(prop, "cd") == 0)
        {
          qDebug() << "Found CD-ROM device" << udev_device_get_devnode(dev);
          //printAttrs(dev);
        }
        udev_device_unref(dev);
      }
      
      e = udev_list_entry_get_next(e);
    }
  }
  udev_enumerate_unref(enumerate);
}

Snad se to nějak dá do kupy. Ale mě by spíše potěšilo, aby se ta CD-ROMka dala zamknout pro exkluzivní přístup nezávisle na typu zařízení, přes které se přistupuje.

Problém ale bude určitě v tom, že distribucím bude dost dlouho trvat, než nový model přijmou. Například Arch stále ještě jede na HALu. Nebo prostě bude někdo mít nainstalovanou starší verzi nějaké konzervativní ditribuce s HALem, a bude problém...

Tak ten program nebudu vydávat zítra. Než to dám do nějakého použitelného stavu, aby se kvůli každé operaci nemusel rekompilovat zdroják (), tak už to ve všech distrech bude (kromě debianu )

[Grunt]

Jó no, ona to fakt taková hrůza není

Ber to z té pozitivní stránky. Zas se nemusíš drbat s komunikací pomocí DBUSu.

Ale mě by spíše potěšilo, aby se ta CD-ROMka dala zamknout pro exkluzivní přístup nezávisle na typu zařízení, přes které se přistupuje.

Tak flock(2) to nebere. Ale jak jsem řekl. Inspiruj se u konkurence. Tady nejsi ve Widlích, ale na otevřené platformě. Co jsem se tak zběžně díval do cdrecord, tak si první autor udělá v paměti buffer a ten si všelijak pozamyká s následujícím komentářem:

/*
		 * Try to lock us im memory (will only work for root)
		 * but you need access to root anyway to send SCSI commands.
		 * We need to be root to open /dev/scg? or similar devices
		 * on other OS variants and we need to be root to be able
		 * to send SCSI commands at least on AIX and
		 * Solaris (USCSI only) regardless of the permissions for
		 * opening files
		 *
		 * XXX The folowing test used to be
		 * XXX #if defined(HAVE_MLOCKALL) || defined(_POSIX_MEMLOCK)
		 * XXX but the definition for _POSIX_MEMLOCK did change during
		 * XXX the last 8 years and the autoconf test is better for
		 * XXX the static case. sysconf() only makes sense if we like
		 * XXX to check dynamically.
		 */

, kde když se zámek nepovede, tak: errmsgno(EX_BAD, "WARNING: This causes a high risk for buffer underruns.\n"); a pak se na tu zamknutou paměť snaží připojit (fs = init_fifo(fs); /* Attach shared memory (still one process) */) a následně nějak propojit s nějakou scg což vypadá na knihovnu, viz komentář:

/*
	 * Call scg_remote() to force loading the remote SCSI transport library
	 * code that is located in librscg instead of the dummy remote routines
	 * that are located inside libscg.
	 */

A IMHO je za dostání do stavu kdy jednotka nebude komunikovat s ničím jiným je zodpovědná právě ta knihovna nebo ta komunikace skrze SCSI příkazy. Jinak celý proces vypalování vypadá opravdu dost brutálně, takže pokud sis myslel, že to bude jen otevření blokového zařízení, uzamknutí přístupu pro exkluzivní přístup a pár writů, tak ses IMHO docela zmýlil.

[Jardík]

To vypadá na přístup na nějaké vzdálené SCSI zařízení. Pro posílání SCSI příkazů CDROMce být rozhodně root nemusím, když mám práva k přístupu l zařízení. Asi to prostě vyřeším tak, že prostě otevřu s O_EXCL jak srX tak sgX, i když srX používat nebudu, aby mi do toho nic nešahalo. BTW takové vypalování obrazu na DVD+RW vypadá takto, to mě funguje:

PREVENT/ALLOW MEDIUM REMOVAL - zamknu eject mechanismus
TEST UNIT READY - test jestli je tam médium a jestli je jednotka ready
GET CONFIGURATION - získání aktuálního profilu (podle profilu se určí typ vloženého média (u příkladu DVD+RW))
READ DISC INFORMATION - zkontroluju jestli je naformátováno
SET STREAMING - nastavím rychlost pálení
FORMAT UNIT - pokud není naformátováno, spustím background format
série WRITE(10) popř. WRITE(12) - zapíšu data
SYNCHRONIZE CACHE - flush
(DVD+RW se nezavírá, nikdy)
Pokud stále běží background format tak CLOSE TRACK/SESSION na ukončení formátování
PREVENT/ALLOW MEDIUM REMOVAL - povolím eject

Snad jsem nic nezapomněl

[Grunt]

Ty jo. S tou sérií write si moc nejsem jistý. Nemají tyto jednotky nějaký vnitřní vypalovací buffer, který je nutné plnit a který také plánuje vypalování tak aby při nedostatku dat nedošlo ke zkurvení média?

[Jardík]

Děláte WRITE a při tom se plní buffer a vypalovačka pálí. DVD+RW lze vypalovat "náhodně", není třeba sekvenční pálení, určíte si start sektor, počet sektorů, co pálíte a prostě pálíte. To samé platí o DVD-RAM a DVD-RW v Restricted overwrite módu (tj. naformátované). A pro zbytek ve write parameters mode page nastavíte BUFE bit (ochrana proti podtečení). Pokud nestíháte posílat WRITE a buffer palírny se vyprázdní, tak může dojít a) k průseru, b) provedení "linkingu".

Každopádně prostě vy děláte WRITE, vypalovačka si plní buffer daty, co jí posíláte a pálí. Data čtu v extra vlákně (SW buffer jsem pro zatím zvolil 64 MB, ale dneska asi nemá cenu šetřit, tak bych se nebál půl giga (vtip, samozřejmě půjde nastavit)).

[Grunt]

Ty jo, Jardo. Fakt nevím. Mrknul jsem i do druhé vypalovací aplikace a shluk writů jsem tam nikde nezahlédl. Zatím to pro moje oči vypadá na pěknou magii.

[Jardík]

A co by tam mohlo být, když né WRITE (rozumíme si, že se nejedná o systémové volání write(), ale o SCSI příkaz WRITE(10), který posíláte přes ioctl(SG_IO) či write()?) Možná tam mají v cyklu ještě další věci, jako zjištěcí stavu bufferu palírny ...

[Grunt]

rozumíme si, že se nejedná o systémové volání write(), ale o SCSI příkaz WRITE(10), který posíláte přes ioctl(SG_IO) či write()?

Aha, tak už jo.

posíláte

My? No my toho neposíláme.

[Jardík]

My? No my toho neposíláme.

sry