This is the mail archive of the libc-alpha@sourceware.org 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: What is glibc-ports?


Hi!

On Thu, 19 Apr 2012 16:45:17 +0000 (UTC), "Joseph S. Myers" <joseph@codesourcery.com> wrote:
> I also think we should look at how appropriate the existing sysdeps 
> structure is.  [...]

I agree this topic could do with some revision -- as soon as we come to a
conclusion about what the purpose of glibc actually is, what its target
systems are.  Formerly, as I understand it, it was all various kinds of
different UNIX and even bare-metal and whatnot systems.  These days, it
just seems to be the Linux kernel, GNU Hurd, kFreeBSD out of tree, and a
few more variations.

> That fits in with the generic question of Implies files.  One idea Roland 
> mentioned in <http://sourceware.org/ml/libc-alpha/2012-04/msg00280.html> 
> was dropping implicit use of parent directories.  If you don't use parent 
> directories, maybe a flatter structure would make sense.  Have 
> sysdeps/linux for things depending on the Linux kernel, sysdeps/hurd for 
> things depending on Hurd.

In case that's not known, here is the idea behind the sysdeps/mach/hurd
hierarchy.  There is the Mach microkernel.  Some glibc bits can be
implemented directly and only using plain Mach interfaces (sched_yield,
for example), and these are implemented in sysdeps/mach.  Then, the
current GNU Hurd implementation is based on the Mach microkernel, and
thus uses Mach as well as Hurd interfaces, and goes into
sysdeps/mach/hurd.  There could also be a sysdeps/l4/hurd if there were
an Hurd port/glibc port for a Hurd implementeation based on the L4
microkernel family.

Alternatively, Roland could have chosen to have sysdeps/hurd and in that
one implement Hurd stuff that does not specifically depend on the Mach
(or any other) microkernel (that is, by using suitable microkernel
abstractions -- which are not really feasible to create), and then have
sysdeps/hurd/mach etc. for microkernel-specific Hurd implementations, but
that's more convoluted than the other way round.

As there currently is no other functional GNU Hurd port other than the
Mach one, one might want to just merge the content of sysdeps/mach and
sysdeps/mach/hurd into sysdeps/hurd, but I would not suggest to do that.

> For anything else under sysdeps/unix, work out 
> whether there is some common feature of supported systems that it relates 
> to (looking probably at kFreeBSD/GNU as well as the systems supported 
> in-tree), and put it in a directory named for that feature if we think it 
> is genuinely still relevant to multiple supported systems but shouldn't go 
> outside sysdeps - or put it outside sysdeps if it now looks appropriate 
> for all systems likely to be supported by glibc.

Yes, as per my comment at the beginning.

I have no idea how much code kFreeBSD, for example, shares (uses from
glibc's sysdeps/...) or implementes on their own.

> I suspect quite a lot of sysdeps/unix (including sysdeps/unix/<arch>) at 
> least is actually not currently used by any port and so should be removed.  
> The same applies in sysdeps/mach (there's no vaguely functional current 
> Hurd port to any architecture other than x86, why are there mach/powerpc 
> and mach/hurd/powerpc directories there?  bitrotten GCC support for other 
> architectures or Hurd was deprecated and removed).

I agree there is no use in keeping the PowerPC Mach/Hurd bits alive, and
spending maintenance time on these files.  I'll propose a patch to remove
them en bloc.

> In summary: I think libc architectures should use sysdeps directories more 
> rather than conditionals in generic code; ports architectures should move 
> back in libc architectures directly in the normal sysdeps directories 
> rather than in a ports/ subdirectory (though I don't object to temporary 
> use of such a subdirectory in the course of a move as a way of reading in 
> the history through git tricks before the files are moved);

That's what I suggested -- just in order to not tatter the history
needlessly.  (I'm offering to implement that if there's agreement about
this procedure.)

> it may well 
> make sense to look at what files in sysdeps are actually used, remove 
> unused files and rework the overall structure very carefully;

Assuming that's glibc-ports' sysdeps, in my opinion, that's the second
step after the wholistic import, just as you've now begun with
sysdeps/unix.

> and none of 
> this has a particularly high priority.


GrÃÃe,
 Thomas

Attachment: pgp00000.pgp
Description: PGP signature


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