See below. On 8/1/05, Bernd Walter <[EMAIL PROTECTED]> wrote: > > On Mon, Aug 01, 2005 at 10:04:25PM +0300, victor cruceru wrote: > > In conclusion: > > any difference between open with O_NONBLOCK and open without it for this > > kind of devices? > > Because man 2 open says: > > > ---------------------------------------------------------------------------------------------------- > > If the O_NONBLOCK flag is specified and the open() system call would > result > > in > > the process being blocked for some reason (e.g., waiting for carrier on > a > > dialup line), open() returns immediately. The descriptor remains in non- > > blocking mode for subsequent operations. > > > ---------------------------------------------------------------------------------------------------- > > Then make it always fail for disk devices.
This is not a solution. I really don't know what you expect to win with this. > There is no other choice. There are many short time blocks you won't noice, e.g. openeing a > device requiring GIANT or any other lock. > You can't open any kind device without a risk to block for a very > short time. It is OK if this is short (10-20 ms). But still you are talking about a broken device - replace or fix it > and return to real problems. Yes, this it is maybe true, but why to block in a driver if the user told not to do it? On the other hand all the HW is broken somehow... So this O_NONBLOCK should be a way to deal with this kind of silly devices. Really - a disk should know if it is ready or not and I won't call > it blocking if you ask a disk about it. > > If you want a workaround then fork another process opening the device > for you and passing the descriptor back to you via domain socket. This is too complicated to be useful. Maybe to spawn a thread - this is also too complicated for getting the capacity of a damn media (this is my situation). > On 8/1/05, Bernd Walter <[EMAIL PROTECTED]> wrote: > > > > > > On Mon, Aug 01, 2005 at 09:41:30PM +0300, victor cruceru wrote: > > > > Well, if you are doing this from a daemon (multiplexing a lot of > events) > > > > which is blocked in this open syscall, even 1 second is not > reasonable. > > > In > > > > my case it is something more than 30 of seconds (again, on a 5.4box). > > > I'll > > > > give it a try on FreeBSD 6. I'm currently investigating if there is > > > > something like TEST_UNIT_READY (for both ATAPI and SCSI) which can > be > > > issued > > > > on a control device (i.e. /dev/ata) > > > > > > What do you expect it to do? > > > Ask the device about the state or always fail, because it is not > > > allowed to ask the device? > > > In your case you have a broken device, this isn't much of an argument. > > > A resonable reply time for a USB device would be less then 10ms. > > -- > B.Walter BWCT http://www.bwct.de > [EMAIL PROTECTED] [EMAIL PROTECTED] Thanks victor cruceru _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
