Re: FreeBSD port (1)

[Roland McGrath <roland at redhat dot com>]

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

My pleasure!  If all contributors were as willing as you are,
to fix their changes and work to integrate them cleanly, we libc
maintainers might be a (slightly) less surly bunch.

> 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.

Sounds good.  When you submit your port changes for inclusion, it would
be good to have a FAQ entry talking about this package and where to find it,
as well as configure checks to make it hard to confuse oneself by trying
to build without it.

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

Indeed so.

> 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.

Fine by me, it's your call.  The only thing making GLIBC_2.3 canonical is
that it will be the first proper glibc version to contain the port.
But if it will in fact be binary compatible with an unofficial version
you have been using and that makes it more useful to your users, then fine.
However, if you truly have a user base of two then it is not really so
painful to change (recompiling just takes time) and it would be cleaner
a) not to use GLIBC_2.2.6 for a port that won't be in glibc-2.2.6 and
b) not to build in any shlib-compat code for old versions when you don't
really have an installed base to worry about.  (Hell, for the Hurd we have
users you might need your toes as well as fingers to count, and we did an
incompatbile rebuild not too long ago.)

> 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?

On Hurd we also have ioperm but no iopl, and use an identical header just
for simplicity.  (In fact, I think there may be Linux platforms that have
no iopl function but declare it in the header file anyway.)  Since sys/io.h
is right now always an extra header added by sysdeps/.../Makefile, it does
not make particular sense to have it split into generic and bits/io.h files.

> 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.

Ok, that is fine.  It certainly makes it easier not to worry about breaking
Hurd builds in the process.  The reasons to use bsd4.4 are a) to avoid the
misleading cvs history when files are moved later, and b) to avoid a later
*BSD porter overlooking your work as "freebsd-specific" and replicating it.
But we can just live with a) and watch out for b) when such a person comes
along.

> 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.

In any case where you are overriding a bsd4.4 file that already exists,
I would like to compare them and favor changing the common file rather
than adding a new one.  I can say when your additions are definitely
not a problem for the Hurd.  But I will be conservative in general and
put things in bsd4.4/freebsd for the most part.

> 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

I don't really see how "not completely orthogonal" relates to using 
a sysdeps dir vs using macros for this.  

> 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.

There is no reason it should use #if.  The existing 64-bit aliases don't
work that way.  Each sysdeps/off_t-64/foo.c would #include_next <foo.c>
and then define aliases.

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

Ok.  There are enough existing replicas of the foo64 -> foo aliasing
already that it won't hurt.  But I would like for this cleanup not to
get dropped on the floor, since it is an issue of easing future maintenance
and porting.  (If we'd gotten around to it before now, your life would have
been easier.)

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

And that one already went in!

> 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?

Ok.  I notice that the NetBSD and FreeBSD versions of this file differ,
though both claim to be the "8.5 (Berkeley)" version.  I don't even know
off hand that we need this file in libc or if anything ever used it,
but since we have had it we should make sure we don't break compatibility.
If there is a later version of this file from UCB, that is probably what
we should use.  Despite the lack of additional copyright notices, if the
FreeBSD and NetBSD versions of this file have had additions made by people
other than UCB, there may be a copyright issue with using those versions.

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

Either objdump -R or readelf -Wr will show you all the dynamic relocs.
All the relocs in .rel.plt (which is the same as all R_386_JUMP_SLOT type
relocs) are PLT entries.

> > As I mentioned, sendfile via POSIX.1 calls is not worth having.
> 
> OK, if you think so, I drop it.

Yes.  

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

The Linux version was never guaranteed to work with arbitrary objects
either.  The only reasonable way to use sendfile is (and has always been)
to try it and be prepared for it to fail if unsupported.