From gd78059@sac.sfbay.sun.com Fri Jun  6 12:59:04 2008
Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m56Jx3Y9003553
	for <psarc-ext@sac.sfbay.sun.com>; Fri, 6 Jun 2008 12:59:04 -0700 (PDT)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m56Jx27W028226;
	Fri, 6 Jun 2008 13:59:03 -0600 (MDT)
Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by
 nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 id <0K22003054UEKA00@nwk-avmta-1.sfbay.Sun.COM>; Fri,
 06 Jun 2008 12:59:02 -0700 (PDT)
Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0K22004044UDF6D0@nwk-avmta-1.sfbay.Sun.COM>; Fri,
 06 Jun 2008 12:59:01 -0700 (PDT)
Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65])
	by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2)
 with ESMTP id m56Jx1lU007773; Fri, 06 Jun 2008 12:59:01 -0700 (PDT)
Received: from sac.sfbay.sun.com (localhost [127.0.0.1])
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m56JwxeN003548; Fri,
 06 Jun 2008 12:58:59 -0700 (PDT)
Received: (from gd78059@localhost)
	by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m56Jwx67003544; Fri,
 06 Jun 2008 12:58:59 -0700 (PDT)
Date: Fri, 06 Jun 2008 12:58:59 -0700 (PDT)
From: "Garrett D'Amore - sun microsystems" <gd78059@sac.sfbay.sun.com>
Subject: Remove MAXIOCBSZ [PSARC/2008/367 Self Review]
To: PSARC-ext@sun.com
Cc: Garrett.Damore@sun.com
Message-id: <200806061958.m56Jwx67003544@sac.sfbay.sun.com>
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.4.1.325704
Status: RO
Content-Length: 2408


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


