On Wednesday 14 June 2006 18:30, Ulrich Drepper wrote:
> > Eventually we'll need a dynamic format but I'll only add it
> > for new calls that actually require it for security.
> > vgetcpu doesn't need it.
>
> Just introduce the vdso now, add all new vdso calls there. There is no
> reason except laziness to continue with these moronic fixed addresses.
> They only get in the way of address space layout change/optimizations.
The user address space size on x86-64 is final (baring the architecture gets extended
to beyond 48bit VA). We already use all positive
space. But the vsyscalls don't even live in user address space.
> >>> long vgetcpu(int *cpu, int *node, unsigned long *tcache)
> >> Do you expect the value returned in *cpu and*node to require an error
> >> value? If not, then why this fascination with signed types?
> >
> > Shouldn't make a difference.
>
> If there is no reason for a signed type none should be used. It can
> only lead to problems.
Ok i can change it to unsigned if you feel that strongly about it.
>
> This reminds me: what are the values for the CPU number? Are they
> continuous? Are they the same as those used in the affinity syscalls
> (they better be)?
Yes of course.
> With hotplug CPUs, are CPU numbers "recycled"?
I think if the same CPU gets unplugged and replugged it should
get the same number. Otherwise new numbers should be allocated.
> Yes, in this one case
> you might at this point in time only need two words. But
>
> - this might change
Alan suggested adding some padding which probably
makes sense, although I frankly don't see the implementation
changing. Variable length would be clear overkill and I refuse
to overdesign this.
> - there might be other future functions in the vdso which need memory.
> It is a huge pain to provide more and more of these individual
> variables. Better allocate one chunk.
Why is it a problem? It's just var __thread isn't it?
>
> > If some other function needs a cache too it can define its own.
> > I don't see any advantage of using a shared buffer.
>
> I believe it that _you_ don't see it. Because the pain is in the libc.
> The code to set up stack frames has to be adjusted for each new TLS
> variable. It is better to do it once in a general way which is what I
> suggested.
Hmm, I thought user space could define arbitary own __threads. I certainly
used that in some of my code. Why is it a problem for the libc to do the same?
Anyways even if it's such a big problem you can put it all in
one chunk and partition it yourself given the fixed size. I don't think
the kernel code should concern itself about this.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
