From owner-freebsd-emulation@FreeBSD.ORG Wed Apr 23 12:03:00 2008 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 665D610656AF for ; Wed, 23 Apr 2008 12:03:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id A68118FC0C for ; Wed, 23 Apr 2008 12:02:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JodND-0002F0-8j; Wed, 23 Apr 2008 14:42:52 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m3NBgnYW023670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Apr 2008 14:42:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m3NBghn1095538; Wed, 23 Apr 2008 14:42:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m3NBghv8095537; Wed, 23 Apr 2008 14:42:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Apr 2008 14:42:43 +0300 From: Kostik Belousov To: Roman Divacky Message-ID: <20080423114242.GY18958@deviant.kiev.zoral.com.ua> References: <20080423112543.GA20954@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i6jgfrJswdyoXnQp" Content-Disposition: inline In-Reply-To: <20080423112543.GA20954@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: b88a486dba0f71889b871e8b63a4ea3b X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2695 [Apr 23 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: emulation@freebsd.org Subject: Re: [RFC]: a place for [f]truncate64 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2008 12:03:05 -0000 --i6jgfrJswdyoXnQp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 23, 2008 at 01:25:43PM +0200, Roman Divacky wrote: > hi, >=20 > Linux defines two syscalls ftruncate64 and truncate64 that are > defined only on 32bit archs, currently Linuxulator implementes > ftruncate64 which is defined in linux[32]_machdep.c, ie. in > machine dependant file. >=20 > I plan to commit truncate64 but I prefer it to be placed in > linux_file.c which is machine independent. Kostik and I had > a discussion about this yesterday and we didnt agree what > is the best place for these functions. >=20 > I think it's better to have it in linux_file.c because the > only problem that can arise is that on platforms that don't > use these syscalls there will be unused function in linux_file.c > Kostik prefers each linux[32]_machdep.c to have it's own copy. >=20 > So I ask emulation@ what should be done, do we want this in linux_file.c > or linux[32]_machdep.c It is wrong to limit the discussion to not quite interesting case of the truncate64. There is a lot more duplication, see the linux{,32}_machdep.c. I would prefer to have some definite word on the reason for this. --i6jgfrJswdyoXnQp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkgPILIACgkQC3+MBN1Mb4i47gCg90CGs1Aw/QXQ2yklOKLAK0IN gwkAnjoRFZ3HaTUbR2wlzgqWySbgvkzp =FriD -----END PGP SIGNATURE----- --i6jgfrJswdyoXnQp--