Mail Archives: cygwin/2005/12/14/10:51:16
We downloaded cygwin-inst-20051213.tar.bz2 and implemented the solution
recommended below. So far, our cursory testing indicates that we are
able to do unbuffered read. However, we are not seeing any "bug" that
was referenced here. What is the "bug" that is being referenced here?
Here's the read from the strace showing that the read did what we ask
for, which is 512 bytes.
57 222458 [unknown (0x940)] lightning 3480 readv: readv (3,
0x10EED60, 1) blocking, sigcatchers 7
51 222509 [unknown (0x940)] lightning 3480 readv: no need to call
ready_for_read
132 222641 [unknown (0x940)] lightning 3480
fhandler_dev_floppy::read_file: 1 (err 0) = ReadFile (1580, 268575744,
to_read 512, read 512, 0)
59 222700 [unknown (0x940)] lightning 3480 fhandler_base::read:
returning 512, binary mode
52 222752 [unknown (0x940)] lightning 3480 readv: 512 = readv (3,
0x10EED60, 1), errno 0
Thanks,
Joe
-----Original Message-----
From: Corinna Vinschen [mailto:corinna-cygwin AT cygwin DOT com]
Sent: Thursday, December 08, 2005 4:57 AM
To: cygwin AT cygwin DOT com
Subject: Re: Error reported dd'ing close of end of block device with
skip
On Dec 7 19:35, Corinna Vinschen wrote:
> On Dec 7 11:55, Loh, Joe wrote:
> > QUESTION:
> >
> > Is there a way in Cygwin to do a read of a block device using "C"
> > that does not do a read-ahead? We needed to develop an application
> > that will issue the exact transfer size to the target device as
requested.
> > Looking at the strace, it appears that read() less than 61440-bytes
> > gets translated to reading 61440 bytes into buffer and then a subset
> > of that read is returned to the caller.
>
> There's a non-portable (only Cygwin) way to set the buffer size after
> opening a device:
>
> #include <cygwin/rdevio.h>
>
> struct rdop rd;
>
> fd = open ("dev/sda", ...);
>
> rd.rd_op = RDSETBLK;
> rd.rd_parm = 0; /* Unbuffered reading */
> rd.rd_parm = 1; /* Unbuffered reading */
> rd.rd_parm = n; /* Buffered reading with buffer size n */
>
> ioctl (fd, RDIOCDOP, &rd);
>
> Note that the ioctl fails if the buffer already contains data, so
> ioctl should be called before the first read. Also note that in
> unbuffered mode the usual Windows blocking rule applies, the length
> given to read must be a multiple of 512.
>
> Sigh, it seems that I introduced a bug into this ioctl also not long
ago.
> I fixed this in CVS. Recent code will probably not work very well
> when setting it to unbuffered mode. Please wait for the next
> developers snapshot.
I just added another requirement, that rd.rd_parm must be either 0, 1,
or a multiple of 512. Other sizes for buffers don't make much sense.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -