[head tinderbox] failure on amd64/amd64
victor.cruceru at gmail.com
Thu Jan 12 04:36:36 PST 2006
Please find below.
> Message: 16
> Date: Wed, 11 Jan 2006 18:44:03 -0700
> From: Scott Long <scottl at samsco.org>
> 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.
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
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
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.
More information about the freebsd-current