Re: What is glibc-ports?

[Roland McGrath <roland at hack dot frob dot com>]

> I think NPTL is sufficient to show add-ons adding sysdeps directories do 
> work.

That's different from everything an add-on port needs.

> Anyway, if the generic mechanism isn't used by glibc it's for people
> using it - people who wish to use it for out-of-tree ports - to keep
> testing it and ensure it keeps working, rather than for it to be used
> artificially for that purpose.

In practice, that's just saying that it will bit-rot and not be fixed.
People working on new ports are not usually experts on libc internals.
They just bang away until they get something working.  The purpose of the
infrastructure is to let the libc experts worry about picayune libc
infrastructure issues and leave the porters just to worry about their ports.

> I don't think this extra directory level is a good idea.  [...]

I'm ambivalent about it myself.  But I do like the notion of something
testing the infrastructure for add-on ports.

> So I'd rather just have all ports directly under sysdeps/ (and 
> nptl/sysdeps/) - but I'd also like existing libc architectures to look 
> more like ports by using files in sysdeps for various things that have 
> architecture conditionals in supposedly architecture-independent files.

I'm in agreement with the latter.  It's just cleaner.

> I also think we should look at how appropriate the existing sysdeps 
> structure is.

That may have some merit, but I think it would be better not to shake this
all up very soon.  Of course, it all depends on the details of concrete
specific proposals.


Thanks,
Roland