Following self-review case on my own behalf, with possible benefits for some
STREAMS device drivers.
Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Remove MAXIOCBSZ
1.2. Name of Document Author/Supplier:
Author: Garrett D'Amore
1.3 Date of This Document:
06 June, 2008
4. Technical Description
Self-Review: Removal of MAXIOCBSZ
Binding: Patch
Description:
In <sys/stream.h>, there is a macro called MAXIOCBSZ, which is assigned value
1024.
This macro is used in only one place, uts/common/os/strsubr.c, in the function
putiocd(). The macro limits the amount of data that will be copied into
a single msgb data block, when the data is being copied in either in response
to I_STR ioctls, or as part of a driver initiated request via M_COPYIN.
Note that the macro doesn't limit the amount of data copied in, as that
check is handled via strmsgsz (but only for I_STR data; drivers are
expected to provide sane values for the data size in M_COPYIN messages).
Rather what it does is cause a single copyin to be split across smaller M_DATA
messages. This is a piece of SVR3 legacy that actually inhibits performance,
since the stream head must now perform extra processing, and the receiving
driver may need to copy the data via msgpullup() if it desires a contiguous
amount of data.
We therefore propose to remove the MAXIOCBSZ macro. We further propose to
promise device drivers that on Solaris versions with this change, they can
avoid the check and msgpullup() if they so desire. (Basically, we can promise
that the data will already be contiguous.) Drivers that don't care to depend
on this promise, or that are from older releases of Solaris, should still
check for additional trailing message blocks and do msgpullup() if
appropriate.
We don't believe that any consumers have ever used, referenced, or relied on
MAXIOCBSZ (at least in "modern" times), and we can find no evidence that the
old behavior was ever specifically documented. So we don't think this
represents any compatibility issues for older drivers. (There is absolutely
*no* change for userland applications.)
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: Automatic
6.6. ARC Exposure: open
