Standalone driver question

[Chris Lewis]

In article <1991Jan26.191859.14609 at cs.olemiss.edu> dave at sam.cs.olemiss.edu (David E. Johnson) writes:
>Is a standalone driver required to handle requests whose character
>count is not a multiple of the block size?  In other words, is the
>driver responsible for extracting the character count of bytes out of
>a full block to place in the user buffer or should this be done by a
>higher level routine?

>In the standalone drivers I have seen, they seem to use the character
>count in the transfer, however, since the driver must deal with blocks
>of a set size it would seem to me that it should be done at a higher
>level. The user code calling the drivers normally wants a set amount
>of bytes and does not allocate a structure of block size therefore I
>assume that it *must* be handled somewhere.

>Any information about buffer handling in standalone I/O routines would
>be helpful.  Many thanks...

What do you mean by standalone?  Drivers for systems without a UNIX
kernel?  Or, UNIX drivers?

In UNIX, block mode devices only deal with blocks.  Character mode
device driver *may* handle things other than blocks, especially if the
physical device can.  It depends on what you want.

For example, a 1/2" tape drive can read and write arbitrary length blocks.
In block mode, you know that the requests will always be a multiple
of the block size - and the buffers are allocated in the kernel.  In
character mode, you're given the buffer of the requested length, and you
can issue a request of that size to the device with the buffer as
given (modulo some remapping you might have to do).

However, if your physical device doesn't handle requests smaller
than a block, it's probably not worth while having to allocate
a block sized buffer for reading/writing and copying to the user's
buffer.

There are exceptions of course - as the time I implemented 1K physical
blocks under a 1/2K file system block size.  Read-modify-write had
to be implemented.
-- 
Chris Lewis, Phone: (613) 832-0541, Internet: clewis at ferret.ocunix.on.ca
UUCP: uunet!mitel!cunews!latour!ecicrl!clewis
Moderator of the Ferret Mailing List (ferret-request at eci386)
Psroff enquiries: psroff-request at eci386, current patchlevel is *7*.