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: [PATCH 1/3] Avoid duplication of _CLOEXEC and _NONBLOCK values


I've was looking into this but I'm unsure about the proper way.
Looking at the kernel includes, only 4 arch (mips, alpha, parisc and
sparc) do redefine O_CLOEXEC and/or O_NONBLOCK.

Moreover, in the kernel, every _CLOEXEC and _NONBLOCK value are taken
from O_CLOEXEC and O_NONBLOCK.

Now, looking at what is already in the libc, I can see that
bits/fcntl.h just serves this purpose of defining all the O_* values.
This file is architecture specific and defined for each of them.

So if I take the route of creating a new kernel-defines.h, I feel like
it will just do as what bits/fcntl.h is supposed to do.

Would including <bits/fcntl.h> instead of <fcntl.h> be good enough ?
As far as I can see, it won't :)

If not, shall I create bits/kernel-defines.h for each and every arch ?
Should this file be at some other place ?

Also, how should I name the values ? I was thinking about K_CLOEXEC and
K_NONBLOCK in order not to collide with already existing defines.
So far I can only see those two values, should any other be redefine
while I'm working on this ?


Other thoughts ?

Thanks,
  Guy


On Fri, 13 Aug 2010 21:34:40 -0400
"Carlos O'Donell" <carlos@systemhalted.org> wrote:

> On Fri, Aug 13, 2010 at 7:23 PM, Ulrich Drepper <drepper@redhat.com>
> wrote:
> > On 08/13/2010 12:11 PM, Carlos O'Donell wrote:
> >> Using the values from fcntl.h is not the only solution. One could
> >> centralize the constants in a new header file,
> >
> > That's what I meant by making things worse for the supported
> > architectures. ÂNo way. ÂI'm not making compiling slower just
> > because of these crappy architectures with maintainers who cannot
> > think straight.
> 
> Thanks, that argument makes sense.
> 
> I'll coordinate with ports to create a clean set of headers that can
> be used by all ports.
> 
> Cheers,
> Carlos.


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