Re: FreeBSD port (1)

[Bruno Haible <bruno at clisp dot org>]

Dear Roland,

Thanks for all the tips you've given me about the port!

> I would like to have you get things working relative to the current
> cvs head state and do any necessary tweaks instead of putting in a
> pile of inconsistent and broken code and then applying rafts of small
> patches.

Sure. I'm going to send an update soon. I consider it stable enough,
otherwise I wouldn't propose it for inclusion.

> A more major concern I have is all the new files that are copied from
> FreeBSD.  These have a copyright issue as well as a maintenance issue.
> ...
> Maybe you should have some fixincludes kind of thing ...
> I think the right thing to do is put all those BSDish headers in a separate
> add-on package that will be required for the freebsd configurations.

Thanks for the tip. I've now realized such an add-on package. The advantage
is not only it solves the copyright issue satisfactorily, it also permits
people with different kernel versions to use the same glibc sources, and
it will allow many more low-level or device centric FreeBSD packages to
build out of the box.

> But having the code that you've written
> yourself in the main source tree makes it easier for us to help you
> maintain the port by including those files in changes made en masse and so
> forth, and there is no reason to keep it out of the main sources.

And the files I've written for FreeBSD can also be useful for a NetBSD port.

> * All your new Versions files should start with GLIBC_2.3 now.

I prefer to start with GLIBC_2.2.6 - otherwise I and my collaborator need
to rebuild all our binaries, from gcc to clisp. There has to be a starting
point, and I don't see why GLIBC_2.3 would be that much better than
GLIBC_2.2.6.

> * linuxthreads has a separate ChangeLog file.

Sure. I simply had not touched the linuxthreads directory in the first round.

> Some of your files seem to be nearly or entirely copies of existing
> sysdeps headers (sys/io.h I noticed, please look over the others).  ...
> If a file differs only slightly, we can look
> at the details and might be able to modify an existing file to be close
> enough that we don't need the duplicate.

i386/sys/io.h differs from the Linux one only in the lack of an iopl function.
You mean, it's ok to introduce a <bits/io.h> header just because Linux
has iopl and FreeBSD doesn't?

In any case, I'd prefer to put the files into
glibc/sysdeps/unix/bsd/bsd4.4/freebsd first, and make the adjustments
that apply to multiple platforms afterwards. This way, all involved people
- you, Ulrich, me etc. - have a common look on all implied files; this
will make discussions easier.

> Feel free to modify the existing bsd/bsd4.4 files if the
> changes are compatible with current 4.4-derived systems (i.e. if recent
> FreeBSD and NetBSD match, then just update the bsd4.4 file even if it
> differs from what 4.4 itself had).

I'm responsible for the FreeBSD port and am not interested in NetBSD.
If someone comes along and makes a NetBSD port which uses files from the
FreeBSD port, it'll be easy for him to "mv bsd4.4/freebsd/$f bsd4.4/$f".
But since I don't know what decisions a NetBSD porter would like to make -
same as in the FreeBSD port or different - I think it's best to wait until
the NetBSD porter comes along.

> New code that would
> work or close to it on NetBSD should go into bsd4.4 (e.g. most of the
> stuff using sysctl). In some of these cases it might break hurd

If you feel confident enough for such changes, I have no objections against
"mv bsd4.4/freebsd/$f bsd4.4/$f". But I won't dare to submit a patch that
risks to break Hurd.

> I note a lot of little tweaks because foo64 == foo, which we have
> repeated on the 64-bit GNU/Linux platforms too.  Perhaps we can make a
> sysdeps/always-largefile or somesuch to consolidate those.

The off64_t == off_t case is not completely orthogonal to other system
dependencies; therefore I am more thinking about defining macros
__OFF_T_BITS (= 32 or 64) and __RLIM_T_BITS (= 32 or 64) in the corresponging
header files, and then use the following idiom in every variant of
foo.c:

     foo (...)
     {
       ...
     }
     #if __OFF_T_BITS == __OFF64_T_BITS
     strong_alias (foo, foo64)
     #endif

and the following idiom in every variant of foo64.c:

     #if __OFF_T_BITS != __OFF64_T_BITS
     foo64 (...)
     {
       ...
     }
     #endif

A sysdeps/off_t-64 directory would only contain ca. 15 functions, the
64-bit variants, and we would need #ifs in the other half of the files,
the 32-bit variants, anyway.

Anyway, I propose to handle this after the FreeBSD port is in.

> If you have added new BSD functions that could reasonably exist on other
> systems, then we might want to add them generically as we did with
> lutimes/futimes (e.g. lchown, lchmod could probably go in).

lutimes/futimes is the only one that seems worth it.

Other than that, FreeBSD has a <sys/queue.h> with some more macros than
glibc's. It seems that glibc's <sys/queue.h> is simply an older version
of the same thing. How about upgrading it?

> In general,
> please scrutinize each new exported symbol you are adding carefully and
> consider whether perhaps it ought to be a generic addition or if not then
> perhaps it ought not be there at all.

I already did that before submitting the patches.

> If you use attribute_hidden on the extern decls for __syscall_* and the
> like (nonexported functions) then you will save unwanted PLT entries.

How can I display a list of the PLT entries? objdump? readelf?

> As I mentioned, sendfile via POSIX.1 calls is not worth having.

OK, if you think so, I drop it.

> You can easily implement the Linux sendfile interface using the FreeBSD
> sendfile system call

Nope, the FreeBSD sendfile works only on sockets, according to the
documentation.

Bruno