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?


On Fri, 20 Apr 2012, Thomas Schwinge wrote:

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

Thanks for the explanation.  That seems reasonable as long as you don't 
have anything in sysdeps/mach that is overridden by something in 
sysdeps/mach/hurd (and so is unused).  At a glance, it looks like 
adjtime.c and bits/libc-lock.h are cases of files like that with unused 
sysdeps/mach/ versions.

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

I suspect quite a bit of sysdeps/unix/bsd is unused - not used on Hurd, 
and not used via #include from elsewhere (and currently there are no 
in-tree ports other than Hurd that use sysdeps/unix/bsd directly).  Again 
I'd say unused bits should be removed (a kFreeBSD/GNU port submission can 
always add back anything it uses).  Also I'm pretty sure the hierarchy 
bsd/bsd4.4 no longer makes sense (as in: any plausible port of glibc to a 
BSD kernel would nowadays be to a kernel based on BSD 4.4) and the extra 
bsd4.4 layer could be flattened.

Could you post the current sysdeps directory ordering for Hurd?  That 
would help people trying to work out if particular files are indeed unused 
by seeing if another version overrides them on Hurd.

Also: could you confirm that syscalls.list files are not relevant to Hurd 
at all, so they are used only for Linux at present?

-- 
Joseph S. Myers
joseph@codesourcery.com


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