From owner-freebsd-current@FreeBSD.ORG Thu Jan 12 12:36:36 2006 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 818D116A422 for ; Thu, 12 Jan 2006 12:36:36 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2764343D5E for ; Thu, 12 Jan 2006 12:36:28 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: by wproxy.gmail.com with SMTP id i14so339796wra for ; Thu, 12 Jan 2006 04:36:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mIWErsx4LH5dA0I2a6EU0zJbDpf7wHKr36qr3fvr0qDrhgbyLDYO3ZMK5lXjn2Tfv6iKqTqsP7qJTMUbPyuStbBfinREKJKoPwEMj8l2tTWISEkoY4YILaHWHfT1A2gVOIYvRAqczn+4UG73DEhx2xEHvQ6VK7z5Uza2yi8ukR0= Received: by 10.54.63.9 with SMTP id l9mr105878wra; Thu, 12 Jan 2006 04:36:28 -0800 (PST) Received: by 10.54.91.14 with HTTP; Thu, 12 Jan 2006 04:36:27 -0800 (PST) Message-ID: <49402550601120436x1228e447o21e4bf13ecf12edc@mail.gmail.com> Date: Thu, 12 Jan 2006 14:36:27 +0200 From: victor cruceru To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soc-victor@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2006 12:36:36 -0000 Hi All, Please find below. > Message: 16 > Date: Wed, 11 Jan 2006 18:44:03 -0700 > From: Scott Long > Subject: Re: [head tinderbox] failure on amd64/amd64 > > As a safe measure, we can build and install a special PIC archive, > > similar to libc_pic.a and libgcc_pic.a, and use it here. This is > > all in an assumption that it's still unsafe to produce the libdisk.so. > > > > > > Cheers, > > One way or another, please fix it. Why is bsnmp linking to libdisk > anyways? It's an absolutely horrible library. > > Scott > Because it was my decision to use libdisk I have to answer to this question= . First, only one bsnmp module is linking to this libdisk (a module for HOST-RESOURCES-MIB). I have to agree that this libdisk is not the nicest library I have ever seen (I don't like these kind of APIs/libs allocating memory for the user - but sometimes we can't avoid them for the sake of =20 execution speed), but at that time I only could think at one alternative solution to libdisk: to call the respective sysctl to programmatically detect the disks/partitions in the running system. This would make my code dependant to any change in the respective sysctl implementation (not to mention that this sysctl approach will reinvent the wheel - this is exactly what the libdisk is doing or was doing at that time). Seeing this libdisk used in a very sensitive part of the system -the installer - this gave me confidence that the usage of libdisk is a good approach, beside its ugliness. Also I was thinking that -on a long term- this libdisk will be well maintained and thus we could rely on it for this bsnmp modules. The final thing to say is that I haven't seen anything saying that this libdisk is ugly and should not be used (At that time I was looking for any hints in the FreeBSD mailing lists and in its manual page). I can try to replace the usage of libdisk with something else which will do the job of detecting the disks and the partitions in a running system. Any suggestion is greatly appreciated. Thanks, -- victor cruceru