From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 23 11:11:57 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38B9016A41F for ; Wed, 23 Nov 2005 11:11:57 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from viefep12-int.chello.at (viefep12-int.chello.at [213.46.255.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFADF43D5D for ; Wed, 23 Nov 2005 11:11:55 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at ([213.47.85.26]) by viefep12-int.chello.at (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20051123111153.SPUK3413.viefep12-int.chello.at@wombat.fafoe.narf.at>; Wed, 23 Nov 2005 12:11:53 +0100 Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id E9DDF3EE; Wed, 23 Nov 2005 12:11:46 +0100 (CET) Date: Wed, 23 Nov 2005 12:11:46 +0100 From: Stefan Farfeleder To: Daniel Rudy Message-ID: <20051123111143.GE1281@wombat.fafoe.narf.at> Mail-Followup-To: Daniel Rudy , freebsd-hackers@freebsd.org References: <4383F0CA.2030609@pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4383F0CA.2030609@pacbell.net> User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org Subject: Re: getdirentries_args and other kernel syscall structures X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2005 11:11:57 -0000 On Tue, Nov 22, 2005 at 08:32:10PM -0800, Daniel Rudy wrote: > > Ok, I'va got a little question here. In the structure > getdirentries_args, there seems to be duplicated fields that I'm not > entirely sure what they do. Here's the definition of a structure > verbatim from sys/sysproto.h: > > struct getdirentries_args { > char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)]; > char buf_l_[PADL_(char *)]; char * buf; char buf_r_[PADR_(char *)]; > char count_l_[PADL_(u_int)]; u_int count; char > count_r_[PADR_(u_int)]; > char basep_l_[PADL_(long *)]; long * basep; char > basep_r_[PADR_(long *)]; > }; > > Now my question is what does the l and r variables do? It seems that > they do something with padding the data based on the endian of the > machine? I look through this header file, and I see all the structures > have similar constructs. Is it something that can be safely ignored? This file is automatically generated by makesyscalls.sh. The l and r variables are a hack to correctly the member between them. One of PADL_ or PADR_ always evalutes to 0, the other one to the needed padding, depending on the passed type. This is unfortunate because it relies on the GCC extension to accept 0-sized arrays. I'd love to fix that but couldn't come up with something that isn't very involved. Stefan