Date: Mon, 1 Aug 2005 22:44:46 +0300 From: victor cruceru <victor.cruceru@gmail.com> To: ticso@cicely.de Cc: Marc Olzheim <marcolz@stack.nl>, freebsd-hackers@freebsd.org Subject: Re: O_NONBLOCK for devices with removable media Message-ID: <494025505080112441ac23dfa@mail.gmail.com> In-Reply-To: <20050801192000.GE26656@cicely12.cicely.de> References: <494025505080104427c3f91f6@mail.gmail.com> <20050801130502.GA39470@stack.nl> <494025505080106336a329bb@mail.gmail.com> <20050801173047.GC26656@cicely12.cicely.de> <4940255050801114161c1cea3@mail.gmail.com> <20050801184731.GD26656@cicely12.cicely.de> <494025505080112043f8a0554@mail.gmail.com> <20050801192000.GE26656@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
See below. On 8/1/05, Bernd Walter <ticso@cicely12.cicely.de> wrote: >=20 > 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 thi= s > > kind of devices? > > Because man 2 open says: > >=20 > -------------------------------------------------------------------------= --------------------------- > > If the O_NONBLOCK flag is specified and the open() system call would=20 > result > > in > > the process being blocked for some reason (e.g., waiting for carrier on= =20 > a > > dialup line), open() returns immediately. The descriptor remains in non= - > > blocking mode for subsequent operations. > >=20 > -------------------------------------------------------------------------= --------------------------- >=20 > Then make it always fail for disk devices. This is not a solution.=20 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= =20 not to do it? On the other hand all the HW is broken somehow... So this O_NONBLOCK should= =20 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. >=20 > 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 als= o=20 too complicated for getting the capacity of a damn media (this is my=20 situation). > On 8/1/05, Bernd Walter <ticso@cicely12.cicely.de> 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=20 > events) > > > > which is blocked in this open syscall, even 1 second is not=20 > 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= =20 > 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. >=20 > -- > B.Walter BWCT http://www.bwct.de > bernd@bwct.de info@bwct.de Thanks victor cruceru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?494025505080112441ac23dfa>