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: ppc64 vDSO in mainline


On Sun, 2005-03-13 at 00:56 -0800, Roland McGrath wrote:
> The cache flush entrypoints you are talking about are for the dynamic
> linker's own use in relocation, right?

Yes, and also for things like Mozilla/Oofice/XFree/JVM/etc... (I don't
think there is a standard glibc function to expose this functionality
though, and I would like to avoid those guys to "know" how to directly
call into the vDSO, so it may be useful to define something.

The reason to get it into the vDSO at this point is that some CPUs don't
need the flush (just a single sync and it's not even clear we need it),
some CPUs don't need the dcbf part of it, only icbi, and there may be
more variations on that theme and/or cpu erratas ...

>   That is actually probably the
> easiest thing to do first.  The data structures pointing at the vDSO are
> set up fairly early on, before any relocation is done.  So I don't think it
> will be hard to do lookups and initialize hooks used by the relocation code.
> Put together a patch that works and we'll see how easy it is to integrate;
> I think it will be very straightforward.

Great, thanks !

> It's obviously not too hard to make use of the vDSO gettimeofday in some
> kludgey way with special code in libc just for that call.  To use vDSO
> entry points in the optimal way, i.e. with no intermediate jumps necessary
> when the vDSO entry point matches the user ABI, will require some
> contemplation about a clean general approach for this in the dynamic
> linker.

I agree. That's why I'm not putting more calls in there for now. Only
those 2 ones which are considered "critical" by lots of folks around. In
the future, I want to provide more, in order to better isolate userland
of some CPU implementation details, that includes atomics, locks,
optimized memcpy's etc... but that will wait for a better mecanism to
link to those calls.

>   If you would like to see the dynamic linker point the function
> descriptors it sets up directly at your entry points, then we'll have to
> work on that plan.

That would be interesting to obtain that result yes. I don't know enough
about the guts of the dynamic linker to dare hacking that myself for
now, but at least, now we have a base to work from.

> As to providing various information useful to libc such as available
> syscalls: I have been playing with some similar stuff (providing the
> version information to save the startup uname call).  Using syscall bitmaps
> directly will require some hacking to standardize the somewhat haphazard
> code arrangements we have now for runtime handling of sometimes-missing
> system calls.  (What I've prototyped is cruder, but simply optimizes what
> we're already doing rather than needing other code cleaned up.)  The
> necessary changes are straightforward and probably a worthwhile cleanup.
> But we may not get to them right away.  Moreover, it's very easy to export
> all sorts of information from the kernel in this fashion and there is
> little platform-specific about doing it, so we should figure out what
> information and in what forms are most useful to libc, and then it's not
> hard to implement the kernel part uniformly across all the platforms that
> have vDSOs.

Sure. If you want me to tweak the kind of informations the ppc vDSO
exports in anyway, don't hesitate to ask.

Thanks,
Ben.



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