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?


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

Some sysdeps/mach/ code that is overridden by sysdeps/mach/hurd/ code has
been useful in bringing up Mach/Hurd support for a new machine.  One can do
the pure Mach porting work first and get things limping along, before
tackling the larger work for Hurd porting per se.

> At a glance, it looks like adjtime.c and bits/libc-lock.h are cases of
> files like that with unused sysdeps/mach/ versions.

In fact, I think adjtime.c and some others (mlock, munlock, settimeofday)
could move up to sysdeps/mach/ since they don't really have any
Hurd-specific code in them.  (Not that we're going to bother.)

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

I think the flattening is adequately justified now.  If any of this is
done, I think that flattening should be done first in two stages.  First,
remove unused sysdeps/unix/bsd/ files that are directly overridden by
sysdeps/unix/bsd/bsd4.4/ files.  Second, move the bsd4.4/ files up to bsd/.

Only after that would I want to consider removing more code, and I'd want
to talk to the kfreebsd folks first.

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

It's true that Hurd has never used them.
Note "inhibit-unix-syscalls = yes" in sysdeps/mach/hurd/Makefile.


Thanks,
Roland


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