Newsgroup: it.comp.os.linux.iniziare
Titolo: Posizione del carrello del CD drive

Come posso conoscere lo status del CD tray, cioè se è chiuso o aperto, 
senza contemporaneamente alterarlo?
L'idea sarebbe quella di costruire un cronjob del tipo:
- se il tray è chiuso, fai niente; altrimenti aspetta un tot e poi 
chiudilo.
Controllare lo stato del carrello serve a garantire che passi *almeno* un 
tot di tempo fra l'apertura e la successiva autochiusura.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________________
Non sprecare i cicli idle della tua CPU, né quelli della tua GPU.
 
http://boinc.berkeley.edu
 
 
http://www.worldcommunitygrid.org/index.jsp
 
http://boincsimap.org/
 
http://www.gpugrid.net/
 

 un tot di tempo fra l'apertura e la successiva autochiusura.
for x in 1 2 3 4 5
do
eject -t /dev/scd0
sleep 20
done
con l'opzione -t chiudi e basta
con l'opzione -T ivece chiudi se e' aperto e apri se e' chiuso
-- 
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
I am not an Economist.  I am an honest man!
		-- Paul McCracken

 eject -t /dev/scd0
Ti ringrazio, ma questo lo so. :)
Non voglio che il carrello si possa autochiudere prima di tot secondi da 
quando lo apro. Non ho modo d'ottenere quest'effetto, se non posso
determinare lo status del carrello (aperto o chiuso) prima d'inviargli
il comando di chiusura.


 inziale, aspetta il tuo 'tot' e poi dai il comando di chiusura.
Eh! Se ignoro lo stato iniziale però non posso impedire che, obbedendo al
cronjob, il carrello si possa chiudere mentre lo sto aprendo, o nei 
cinque secondi successivi (durante i quali sto inserendo il disco)... con 
conseguente distruzione del disco e amputazione delle falangi... Ok, ok, 
sto estremizzando... ;)
Comunque era soprattutto una mia curiosità. Il SO non lo sa se il tray è 
aperto o chiuso? Se lo sa lui, lo posso sapere io. E me lo deve dire, me 
lo deve! Anche colle cattive. ;)


 il comando di chiusura.
Boh allora giuro che non ho capito cosa vuoi fare...Con quel sistema se 
l'apertura avviene manualmente sai che hai 20 secondi prima che si possa 
autochiudere, se invece viene provocata da un evento basta che lavori 
sull'evento inserendo uno sleep dopo che esso si sia effetivimante 
verificato. Non si puo' dare una risposta piu' precisa senza che tu dica 
quale sia la variabile che ne determina l'apertura :-)
-- 
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
I never vote for anyone.  I always vote against.
		-- W. C. Fields

 viene memorizzata da nessuna parte.
  Domanda da inespertissimo e scusami se dico una sciocchezza:
considerando quel poco che c'ho capito leggendo il manuale, 'eject
-T' sembrerebbe poterlo sapere se il carrello e' aperto o chiuso. Non
potrebbe essere un'alternativa cercare nel codice di eject la parte
interessata?
  Sempre guardare nel codice e', lo so, volevo solo sapere se come idea
poteva andare. :-D
  Saluti,
-- 
Gianfranco Bertozzi
Linux User #183585

 interessata?
  Prima di scrivere controllare sempre... eject non lo sa se il carrello
  e' aperto o chiuso. Pero' ho trovato questo:
 
http://linux.derkeiler.com/Newsgroups/comp.os.linux/2004-10/0086.html
  dove parlano di: " There is a CDROM_DRIVE_STATUS ioctl defined in
/usr/include/linux/cdrom.h. Perhaps it can help you."
   Non so se puo' servire. L'ho detto che sono inesperto! :-D
  Un saluto,


 autochiudere
Ma nemmeno per idea. :)


 adesso perche' non ci dici quale e' il tuo problema?
Guarda che l'ho già scritto tre volte. :)
Voglio che il carrello si autochiuda. Però da quando si è aperto non 
devono passare mai meno di tot secondi.
Quarta volta. :)


 viene memorizzata da nessuna parte.
Granché utile magari no. Utile almeno a fare quel che voglio io, pare di 
sì.


 Ma nemmeno per idea. :)
Aspetta, questa me la devi spiegare, perche no??
Quando la spia del lettore si accende premi il tasto di espulsione e da 
li iniziano i 20 secondi...se vuoi tenerti un po' di margine portali a 30 
ma quello e'.
-- 
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
La rovina del mondo sara' l'indifferenza.  Ma chi se ne fotte!
		-- Vincenzo Onorati


Facebook: Massimo Bacilieri

 Quando la spia del lettore si accende
Quale spia del lettore? Il tray può aprirsi (o posso aprirlo io) in
qualsiasi momento. L'apertura non è pianificabile, è un'incognita.
La soluzione sarebbe: ogni X secondi controllami se il tray è aperto o 
chiuso. Se è chiuso, basta là. Se è aperto (ed è certamente aperto da 
meno di X secondi), aspetta Y secondi e poi chiudilo. In questo modo sono 
certo che il tray resta aperto per un tempo non inferiore a Y secondi, e 
non superiore a X+Y secondi. OK?
Ecco, per ottenere quest'effetto devo essere in grado di stabilire se il 
tray è aperto o chiuso: e lasciarlo chiuso se è chiuso, e lasciarlo 
aperto (per Y secondi, poi lo chiuderò) se è aperto.


 
http://linux.derkeiler.com/Newsgroups/comp.os.linux/2004-10/0149.html
Sì, allora è proprio impossibile. :(
Infatti pensa che l'unica cosa (ben diversa, per altro) che avevo trovato 
in merito, cercando in rete, era un modo per stabilire se il lettore 
avesse dentro un disco o no. Un modo, anche lì, appunto indiretto, e 
basato su:
cdrecord -V --inq dev=DEVICE 2>&1 | grep "medium not present"
che fra l'altro a me non funziona nemmeno, perché a me cdrecord non dice 
mai "medium not present": proprio se ne frega di avvertirmi. Sarà la 
nuova versione...
Grazie lo stesso, a te e a tutti, per il tempo dedicatomi. :)
E, se non sono stato chiaro dall'inizio, mi scuso.


 aperto (per Y secondi, poi lo chiuderò) se è aperto.
Scusa, e aprirlo anche se e' chiuso, e poi chiuderlo comunque dopo X
secondi, sarebbe un problema?
-- 
Cio' che si vede, e'.

 
Il problema e' l'apertura 'random', siccome ad ora non ci e' possibile 
determinare lo stato del carrello non rimane che adattarsi a lasciare 
automatizzato tutto eccetto il controllo sullo stato del tray.
Peraltro molto dipende anche da come si imposta il cron. Per lo stato del 
tray si puo' dare un occhiata in /proc o /sys se trovi qualcosa ma 
dubito, se anche ci fosse sarebbe legato a quello specifico lettore 
quindi la soluzione sarebbe limitata a quel modello.
-- 
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
La soluzione del buon senso e' l'ultima a cui pensino gli specialisti.
		-- Bernard Grasset, "Remarques sur l'action"

 secondi, sarebbe un problema?
Eh sì. :)
Il fine di tutto è naturalmente evitare di sfasciare il tray dimenticato 
aperto, andandoci a sbattere per sbadataggine. Direi che, se mi si apre 
tipo imboscata ogni minuto, più che risolvere peggioriamo... ;)))))
Grazie comunque. :)


tipo imboscata ogni minuto, più che risolvere peggioriamo... ;)))))
Guarda IMHO c'hai qualche programma in X che lo controlla,
perche' da me che ho tolto tutti i maledetti automonta
autoapri eccetera, aperto ci resta per sempre finche' non
lo chiudo io a manina o da eject. (Debian kde)
-- 
Saluti, Dalet

 resta per sempre finche' non lo chiudo io a manina o da eject.
Eh?


Eh?
Se eh vuol dire eh, allora prova a vedere se ti si chiude
stando nel bios, cioe' prima di avviare Linux. Se ti si
chiude da solo allora e' l'hardware del mast tuo, io c'ho
un samsung e non si chiude.
-- 
Saluti, Dalet

 chiude da solo allora e' l'hardware del mast tuo
Ma quando mai avrei scritto che mi si chiude da solo? :)


 il comando di chiusura.
  Sembrerà banale, ma se sai il numero n di secondi che ti serve aspettare 
puoi mettere lo sleep prima così sai che lo script parte, passano n secondi 
e poi eventualmente si chiude il cdrom
-- 
Non pretendo che comprendiate il significato di quello che ho scritto senza 
averlo riletto un certo numero di volte. Personalmente, vi riterrei degli 
stupidi se lo faceste. Io l'ho letto sei volte ed ancora non l'ho capito.

 una questione tassonomica non mi sembra molto interessante.
]zac[
Un sistema operativo č composto da vari livelli, e i vari livelli hanno 
metodi ben specifici per poter comunicare fra di loro, e spesso questi 
metodi non sono semplici e facilmente modificabili.
Un utente essendo a livello utente puň solo utilizzare le 
funzioni/interfaccia che un driver (che č al livello kernel) mette a 
disposizione (vedi man ioctl o simili).
In sintesi, se un utente, tassonomico quanto gli pare, deve chiedere una 
informazione,  per cui non esiste una interfaccia che la fornisca, 
all'hardware o al kernel, č tassonomicamente fregato o se si preferisce 
tassonomicamente costretto a modificare il codice del driver o di una zona 
del kernel, ecc. .

 a modificare il codice del driver o di una zona del kernel, ecc. .
"Anche colle cattive. ;)", e sottolineo il ";)", per te che cosa 
significava?


 significava?
Tassonicamente ( :P )? modificare il codice via kmem (interfaccia verso la 
memoria usata dal kernel)? codice assembler iniettato direttamente nelle 
zambe del processore? dio potrebbe .... ( :) )

 nelle zambe del processore? dio potrebbe .... ( :) )
Puoi fare le modifiche che vuoi, ma se l'*apparecchio* nel suo firmware non
prevede di farti leggere lo stato del carrello (ma prevede solo di ricevere
un comando per aprirlo o chiuderlo, quale che sia il suo stato attuale) tu
hai già finito di scrivere driver...


 
 
.. visto che il post partiva dall'assunto di essere al livello di dio .... 
vorrà dire che si scriverà anche il firmware ...

 .. visto che il post partiva dall'assunto di essere al livello di dio ..
Un utente... a livello Dio. Cioè io sono il dio del mio pc, e lui è il 
mio schiavo devoto colla faccia sotto i miei piedi e se mi gira nemmeno 
sto fermo (quasi cit.). ;) E se voglio una cosa, lui la *deve* fare. ;)
Tutti sanno qui che le mie conoscenze informatiche sono ben limitate. Non 
vorrei ci fossero fraintendimenti: non ho mai millantato competenze, eh...
