W dniu 05.03.2018 o 08:32, Jarosław Sokołowski pisze:
> Pan Zbych napisał:

>>>> Gapowate w tym przypadku jest zachowanie funkcji write i read, które
>>>> nie zwracają kodów błędów gdy próbujemy pisać/czytać ze "znikniętego"
>>>> urządzenia.
>>>
>>> Funkcje write i read nie są gapowate, robia dobrze to, co do nich należy.
>>
>> Pisanie do nieistniejących urządzeń bez sygnalizacji błędów? Chyba mamy
>> inną definicję poprawności.
>
> Chyba. W każdym razie jest to najbardziej prawdopodobne wyjaśnienie.

Zostawię tylko info dla potomnych, bo odpowiedzi Jarka są tradycyjnie
bezużyteczne:

Z manuala funkcji read i write:
On error, -1 is returned, and errno is set appropriately.

I tego wspomniane funkcje read/write nie robią jeśli urządzenie zniknie.

do góry

Zbych <a...@o...pl> wrote:

>> Plik urządzenia znika, ale nadal jest otwarty przez program. Przez to
>> nowy pojawia się pod inną nazwą.
>
> Też nie zawsze się to dzieje.

Prawda. Mówię o sytuacji "domyślnej" i ftdi.

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

Zbych <a...@o...pl> wrote:

> To jest normalny przypadek, potrafię go wywołać na zawołanie. Usunięte
> pliki w uniksach znikają po zamknięciu ostatniego uchwytu.

Jeśli mówisz o inode, to tak, ale dowiązanie nazwy do inode znika od razu,
gdy jest usunięte.

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

Zbych <a...@o...pl> wrote:

> Z manuala funkcji read i write:
> On error, -1 is returned, and errno is set appropriately.
>
> I tego wspomniane funkcje read/write nie robią jeśli urządzenie zniknie.

Spodziewałbym się EIO. Ciekawe, czemu tak się nie dzieje (nie sprawdzałem,
bo teraz nie mam jak, ale wierzę).

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

W dniu 05.03.2018 o 10:22, Adam Wysocki pisze:
> Zbych <a...@o...pl> wrote:
>
>> Z manuala funkcji read i write:
>> On error, -1 is returned, and errno is set appropriately.
>>
>> I tego wspomniane funkcje read/write nie robią jeśli urządzenie zniknie.
>
> Spodziewałbym się EIO. Ciekawe, czemu tak się nie dzieje (nie sprawdzałem,
> bo teraz nie mam jak, ale wierzę).

Ja zazwyczaj używam IO w wersji nieblokującej (O_NONBLOCK), z ciekawości
muszę sprawdzić czy bez tej flagi też jest problem z sygnalizacją błędów.

do góry

On Mon, 5 Mar 2018 08:44:37 +0100, Zbych <a...@o...pl> wrote:
> I tego wspomniane funkcje read/write nie robią jeśli urządzenie
> zniknie.

Problem nie jest w prymitywach read/write, bo one nie wiedzą, że
piszą do urządzeń to raz. Dwa to jest konsekwencja VFS, trzymania
otwartego uchwytu w kontekście VFS io. Zjawisko, które powoduje
opisywany problem jest bardziej skomplikiwany, nie jest wadą ale
kkonsekwecja użycia wartswy API gdzie mamy read//write Ominięcie
tego problemu to komunikacja zurządzeniem nie przez read/write ale
bezpośrednio z driverem urządzenia (i tracąc wszystkie inne zalety
użycia warstwy gdzie mamy read/write).

--
Marek

do góry

Zbych <a...@o...pl> wrote:

> Ja zazwyczaj używam IO w wersji nieblokującej (O_NONBLOCK), z ciekawości
> muszę sprawdzić czy bez tej flagi też jest problem z sygnalizacją błędów.

W sumie nie powinno to nic zmieniać. Spodziewałbym się, że po odpięciu
urządzenia select() zwróci odczytywalność, a read() zwróci 0 (ale nie
sprawdzałem).

Tak się składa, że mam teraz na tapecie program, który gada z ttyACM
(moduł cdc_acm) blokującym I/O (naprzemiennie pisze do portu i czeka na
odpowiedź). Po odpięciu kabelka blokujący read() zwrócił 0 (EOF), a
późniejszy tcdrain (wywołujący ioctl TCSBRK) -1 (errno = EIO).

Dodatkowy test pokazał, że gdy read() zwróci EOF, to kolejny read()
również zwraca EOF, ale kolejny write() zwraca -1 z errno = EIO. Kołacze
mi się po głowie, że w przypadku socketów zachowanie read() było inne (gdy
zwrócił EOF, to kolejny read() zwracał błąd), ale głowy za to uciąć nie
dam -- może mi się coś przywidziało.

Nie wiem czy cokolwiek zmienia fakt, że urządzenie nie jest podłączone
bezpośrednio, tylko przez "przejęcie" portu w VirtualBox (ten Linux chodzi
w wirtualce na Windows 7). Niby nie powinien.

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

Mario <M...@...pl> wrote:

> Zapalarka może pomóc.

Byle nie tak :) https://www.youtube.com/watch?v=RtlYi1yLTVQ#t=46

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

W dniu 07.03.2018 o 10:37, Adam Wysocki pisze:
> Zbych <a...@o...pl> wrote:
>
>> Ja zazwyczaj używam IO w wersji nieblokującej (O_NONBLOCK), z ciekawości
>> muszę sprawdzić czy bez tej flagi też jest problem z sygnalizacją błędów.
>
> W sumie nie powinno to nic zmieniać. Spodziewałbym się, że po odpięciu
> urządzenia select() zwróci odczytywalność, a read() zwróci 0 (ale nie
> sprawdzałem).
>
> Tak się składa, że mam teraz na tapecie program, który gada z ttyACM
> (moduł cdc_acm) blokującym I/O (naprzemiennie pisze do portu i czeka na
> odpowiedź). Po odpięciu kabelka blokujący read() zwrócił 0 (EOF), a
> późniejszy tcdrain (wywołujący ioctl TCSBRK) -1 (errno = EIO).
>
> Dodatkowy test pokazał, że gdy read() zwróci EOF, to kolejny read()
> również zwraca EOF, ale kolejny write() zwraca -1 z errno = EIO. Kołacze
> mi się po głowie, że w przypadku socketów zachowanie read() było inne (gdy
> zwrócił EOF, to kolejny read() zwracał błąd), ale głowy za to uciąć nie
> dam -- może mi się coś przywidziało.
>
> Nie wiem czy cokolwiek zmienia fakt, że urządzenie nie jest podłączone
> bezpośrednio, tylko przez "przejęcie" portu w VirtualBox (ten Linux chodzi
> w wirtualce na Windows 7). Niby nie powinien.

Zacząłem to jeszcze raz sprawdzać i na ubuntu 14 (kernel 4.4.0) mam tak:

1. write zwraca błąd i errno=5 (EIO, Input/output error) jeśli
urządzenie zniknie, niezależnie czy używam trybu blokującego czy nie.

2. read w trybie blokującym czeka na dane, jak wypnę w trakcie czekania
wtyczkę to przerywa czekanie zwracając 0, czego nie traktuję jako błąd.
Kolejne wywoływania read zwracają cały czas 0

3. read w trybie nieblokującym zwraca mi błąd i errno=11 (EAGAIN,
Resource temporarily unavailable) gdy wtyczka jest wpięta i nie ma
danych do odbioru czyli zachwuje się prawidłowo. Ale za to zwraca 0
(brak błędu) jak wtyczkę wypnę.

Testy z read powtórzyłem też na ubuntu 16 z kernelem 4.4, zachowanie
identyczne.

Problem polega na tym, że mam urządzenia z który tylko czytam dane
(skanery, klawiatury) i takie zachowanie read jest delikatnie mówiąc
irytujące.

do góry

Zbych <a...@o...pl> wrote:

> 2. read w trybie blokującym czeka na dane, jak wypnę w trakcie czekania
> wtyczkę to przerywa czekanie zwracając 0, czego nie traktuję jako błąd.
> Kolejne wywoływania read zwracają cały czas 0

Wartość 0 oznacza EOF ("koniec pliku", zamknięte połączenie, koniec
strumienia danych). To coś innego niż brak danych (bo wtedy jak sam
zauważasz blokujący read poczeka, a nieblokujący zwróci EAGAIN).

> Problem polega na tym, że mam urządzenia z który tylko czytam dane
> (skanery, klawiatury) i takie zachowanie read jest delikatnie mówiąc
> irytujące.

Hmm, jak dla mnie jest prawidłowe. Po prostu read() nie ma prawa zwrócić
0, jeżeli urządzenie jest podłączone i działa, ale nie ma danych. Wartość
0 oznacza, że kanał komunikacyjny został zamknięty i dane się skończyły
(to nie to samo, co chwilowy brak danych, które mogą przyjść później, bo
strumień jest otwarty; gdy read() zwróci 0, to dane już nie przyjdą).

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry