Re: kern/41889: st(4) driver splits larger IO request into peaces - compability problem with other OS's

[Wolfgang.Stukenbrock%nagler-company.com@localhost]

The following reply was made to PR kern/41889; it has been noted by GNATS.

From: Wolfgang.Stukenbrock%nagler-company.com@localhost
To: gnats-bugs%NetBSD.org@localhost, "David Holland" 
<dholland-bugs%NetBSD.org@localhost>
Cc: kern-bug-people%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, 
netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/41889: st(4) driver splits larger IO request into peaces
        - compability problem with other OS's
Date: Sun, 16 Aug 2009 13:38:12 +0200

 Hi again,
 
 I haven't seen 38643 before - OK.
 
 The problem there has the same cause.
 A tape device has a little bit different semantic in reading and =20
 writing as a "normal" block device.
 Blocknumber have no meaning for a tape and a tape block is the atom =20
 for a transfer.
 Therefore a write should write exaclty one tape block - or should fail.
 And a read should try to read exactly on tape block - or should fail.
 A read my succeeed only if the requested size is at least the size of =20
 the tape block.
 There is absolutly no way to get only "a second" half of a tape block =20
 from a tape.
 
 This problem needs a fix as soon as possible!
 
 My fix will "just" remove the silent misbehaviour for simple read and =20
 write calls.
 A fix fore readv and writev is mentioned, but perhaps someone has a =20
 better idea ..
 
 W. Stukenbrock
 
 Zitat von "David Holland" <dholland-bugs%NetBSD.org@localhost>:
 
 > The following reply was made to PR kern/41889; it has been noted by GNATS.
 >
 > From: David Holland <dholland-bugs%netbsd.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:
 > Subject: Re: kern/41889: st(4) driver splits larger IO request into peaces
 > =09- compability problem with other OS's
 > Date: Sun, 16 Aug 2009 05:20:37 +0000
 >
 >  On Fri, Aug 14, 2009 at 11:50:00AM +0000, =20
 > Wolfgang.Stukenbrock%nagler-company.com@localhost wrote:
 >   > The current implementation of physio() (in kern_physio.c)
 >   > determines the maximum possible transfer size of the underlying HW
 >   > be fist clamping to MAXPHYS and then asking the driver for further
 >   > restrictions.
 >
 >  See also PR 38643. :-|
 >
 >  --
 >  David A. Holland
 >  dholland%netbsd.org@localhost
 >
 >