[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: future of libfreebsd



On Wed, Aug 05, 2009 at 10:55:45AM +0200, Petr Salinger wrote:
> Hi,
Hi!

> currently we have libfreebsd source package,
> which provides some functions. Recently some
> of these functions have been moved info libbsd.
>
> Similarly sysctlnametomib() will be in our glibc 2.10.
> We may consider to drop libfreebsd at all.

Yes, this has always been the long term goal, libfreebsd being nothing
more than a hack.

> IMHO, we could move needed functions in
>
> * libbsd: functions which can be provided on linux
> * eglibc: functions which are provided under plain FreeBSD in libc
> * in some library from freebsd-libs (i.e. in libkvm0)
> * directly in the place where it is needed
>
> The current libfreebsd exports:
>
> LIBFREEBSD_0.0 {
>   global:
>     link_addr; link_ntoa;
>     strmode;
>     devname; devname_r;
>     getbootfile;
>     sysctlbyname; sysctlnametomib;
>     nlist; __fdnlist;
>   local:
>     *;
> };
>
>> From libbsd are already available:
> 	strmode, nlist, __fdnlist

The thing is that we have to keep those symbols to not break existing
software, but yes, those functions should not be considered as part 
of libfreebsd anymore.

>> From glibc 2.10 will be available (at least):
> 	sysctlbyname, sysctlnametomib

sysctlbyname() is actually already available in glibc 2.9. 
sysctlnametomib() is planned for 2.10.

> The remaining functions are:
>     link_addr; link_ntoa;
>     devname; devname_r;
>     getbootfile;
>
> I didn't check, which are the needed functions used by packages
> depending on libfreebsd0. Could this check be done easily ?

Probably UDD can do that for the packages that are already in the
debian.org archive, but not for the one that are not yet available.
That said I doubt that a lot of packages depends on libfreebsd0, so
doing the work by hand should not be that difficult.

> We have to decide, before eglibc 2.10 will go into unstable,
> which functions could/should be moved into eglibc and do it.

Agreed. Or have to wait for 2.11 :(

> My candidates for eglibc are devname_r()/devname().

Indeed, they looks good candidate for that. 

getbootfile() *may* be implemented in libbsd. For link_addr() and 
link_ntoa(), I currently don't have an opinion, we should probably look
where they are used.

Also note that I am currently working on a setproctitle() function to
put in libbsd.

Cheers,
Aurelien

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: