This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FreeBSD port (1)


Firstly, thanks a lot for doing all this work!  

I have now incorporated all of your fixes to existing code, or responded
with specific reasons why some of your changes were left out.  Please take
a look at the cvs head state and if there is anything that I've overlooked,
let me know.  (I just culled all the "FreeBSD port (N)" messages from the
July mailing list archives, so I could well have missed some things.)

There is nothing wrong with your abi-tags and shlib-versions additions, but
I decided not to put them in until we are ready to put in all the files to
make the port work.  I have not put in any of your new unix/bsd/bsd4.4/freebsd
subdirectories, for several reasons.

First, it has been a while with a lot of libc changes since you sent your
patches, so 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.

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.  For
the files with copyright owners other than UCB, we can't put them into
glibc.  For all of the files mostly or wholly copied from FreeBSD, I am
highly dubious as to whether we'd want to just from a maintenance
perspective.  It seems like a maintenance nightmare to copy and edit all
those headers and track future changes in FreeBSD.  Maybe you should have
some fixincludes kind of thing, or maybe that is a worse nightmare.  Any
way you slice it, it's a maintenance nightmare for you (but I guess that's
what you signed on for).  It would be even more of a nightmare to funnel
all those changes back through us to get them into the glibc source tree.
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.  (The
add-on can have decently short pathnames for the new headers, since they
needn't be stuck under sysdeps/... if they are extra headers.)  You can
maintain and distribute this separately (not that we won't redistribute it
alongside glibc) and not go through the glibc maintainers to update it.
(In fact, arbitrary amounts of the port could be in the add-on rather than
in the main glibc source tree.  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.)


I have not examined every new file in detail, but here are some nits I have
come across.  In general, the code looks very good.


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

* linuxthreads has a separate ChangeLog file.  The conventions are the
  same, but linuxthreads changes go in the separate file and use file names
  relative to the linuxthreads subdirectory.

* 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 is identical, then it really should be located in some sysdeps
  directory that the various appropriate configurations all use in common,
  rather than having a copy.  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.  It is fine to rearrange
  existing sysdeps files into new directories of common code if that avoids
  duplication.  Please look for places this could be done, and places where
  your duplicate file differs but is largely identical to an existing one,
  and for each one we can figure out if there is anything we can do that
  will be cleaner and easier to maintain in the long run than duplicating
  that file.  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).  If there are changed or new files
  that match on all current BSDs for a machine, make a bsd4.4/CPU subdir
  with appropriate bsd4.4/freebsd/CPU/Implies file.  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 and in
  that case we should have a bsd4.4/something subdir for stuff common to
  modern post-4.4 BSDs but not to Hurd, or something like that.

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

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

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

* As I mentioned, sendfile via POSIX.1 calls is not worth having.  You can
  easily implement the Linux sendfile interface using the FreeBSD sendfile
  system call, and that will be fine.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]