From owner-freebsd-current@FreeBSD.ORG Fri Aug 5 20:40:44 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63D4D16A41F for ; Fri, 5 Aug 2005 20:40:44 +0000 (GMT) (envelope-from Lonnie.Vanzandt@ngc.com) Received: from xcgca810.northgrum.com (xcgca810.northgrum.com [208.12.122.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1769143D48 for ; Fri, 5 Aug 2005 20:40:43 +0000 (GMT) (envelope-from Lonnie.Vanzandt@ngc.com) Received: from xcgca800.northgrum.com ([157.127.103.70]) by xcgca810.northgrum.com with InterScan Messaging Security Suite; Fri, 05 Aug 2005 13:40:43 -0700 Received: from xcgco501.northgrum.com ([158.114.104.53]) by xcgca800.northgrum.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Aug 2005 13:40:43 -0700 Received: from [192.168.217.128] ([158.114.106.12]) by xcgco501.northgrum.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Aug 2005 14:40:04 -0600 From: Lonnie VanZandt Organization: Northrop Grumman To: freebsd-current@freebsd.org Date: Fri, 5 Aug 2005 14:33:19 -0600 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508051433.21117.lonnie.vanzandt@ngc.com> X-OriginalArrivalTime: 05 Aug 2005 20:40:04.0411 (UTC) FILETIME=[DBD8A0B0:01C599FD] Subject: ALQ API suggestions - from newbie ALQ user X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lonnie.vanzandt@ngc.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2005 20:40:44 -0000 1. Although it is a rather obvious requirement, it would help newcomers to the ALQ service to note in the man 9 alq page that "options ALQ" has to be added to the kernel configuration in order to gain access to ALQ. 2. The alq_post and alq_write methods always write alq.aq_entlen bytes to the vnode. This is fine for record-oriented, fixed-size "protocols" where one is basically writing out a C struct on each write. But, if one wants to output arbitrarily-sized strings or binary sequences and does want the consumer to have to know that internally the output file was generated in fixed-sized chunks, then a method prototype like this would be very useful: int alq_write_bytes( struct alq * const, const void * const data, unsigned int maxByteCnt ); // returns byte count actually "written" Here, the ALQ internal code would post an ALE with a data length equal to min( pAlq->aq_entlen, maxByteCnt ). The ALD then would write to the vnode not alq.aq_entlen bytes but ale.data_len bytes. The alq_write caller could implement a "while bytes left" loop around the alq_write_bytes to write out sequences larger than the ALQ entry size. The destination file then would be contiguous without padding at the end of the last partial entry. The needed changes would be: a. add a data_len field to struct ale b. implement a new alq_write_bytes method in kern_alq.c c. set ale.data_len to alq.aq_entlen in alq_get() (to set the default size) d. modify alq_post() to write ale.data_len, not alq.ag_entlen bytes to the vnode Lonnie. PS: If there is some other kernel facility for doing just what I suggest, then my newbie ignorance has been revealed and I would appreciate being so informed.