Hi,
I was reading through the include/linux/limits.h file in order to
generate a cleanup patch for it -- a large number of #defines within
that file are no longer being used, as I surmise that they are simply
remnants of earlier implementations.
A snippet from include/linux/limits.h:
#define PIPE_BUF 4096 /* # bytes in atomic write to a pipe */
PIPE_BUF is a bit of an oddity. It is defined there, then redefined in
the arm header files, even though those header files are never included
anywhere. Also, PIPE_BUF is never referenced by name in any of the Linux
code. And yet, it is still being mentioned in some Big And Scary
Warnings (tm): fs/autofs4/waitq.c or include/linux/pipe_fs_i.h, for
example.
What's the deal with PIPE_BUF? Is its value used in the code indirectly,
so that more comments would help make this fact obvious? Or is it now
deprecated, and therefore a viable target for include/linux/limits.h
cleanups?
- Vadim Lobanov
On Wed, 2006-05-03 at 22:55 -0700, Vadim Lobanov wrote:
> Hi,
>
> I was reading through the include/linux/limits.h file in order to
> generate a cleanup patch for it -- a large number of #defines within
> that file are no longer being used, as I surmise that they are simply
> remnants of earlier implementations.
>
> A snippet from include/linux/limits.h:
> #define PIPE_BUF 4096 /* # bytes in atomic write to a pipe */
>
> PIPE_BUF is a bit of an oddity. It is defined there, then redefined in
> the arm header files, even though those header files are never included
> anywhere. Also, PIPE_BUF is never referenced by name in any of the Linux
> code. And yet, it is still being mentioned in some Big And Scary
> Warnings (tm): fs/autofs4/waitq.c or include/linux/pipe_fs_i.h, for
> example.
it's for userland to tell it what the size of the atomic pipe operations
we can do is.
05/04/2006 07:55 AM, Vadim Lobanov wrote/a écrit:
> Hi,
Hi!
:
>
> A snippet from include/linux/limits.h:
> #define PIPE_BUF 4096 /* # bytes in atomic write to a pipe */
>
> PIPE_BUF is a bit of an oddity. It is defined there, then redefined in
> the arm header files, even though those header files are never included
> anywhere.
Actually, here, on a 2.6.16 source code, PIPE_BUF is used in
arch/sparc/kernel/sys_sunos.c, arch/sparc64/kernel/sys_sunos32.c, and
arch/sparc64/solaris/fs.c . It seems it's some kind of compatibility
value with Sun's OS...
> Also, PIPE_BUF is never referenced by name in any of the Linux
> code. And yet, it is still being mentioned in some Big And Scary
> Warnings (tm): fs/autofs4/waitq.c or include/linux/pipe_fs_i.h, for
> example.
Maybe they wanted to say PIPE_BUFFERS ? (just wild guess)
c u,
Eric
On Thu, 4 May 2006, Arjan van de Ven wrote:
> On Wed, 2006-05-03 at 22:55 -0700, Vadim Lobanov wrote:
> > A snippet from include/linux/limits.h:
> > #define PIPE_BUF 4096 /* # bytes in atomic write to a pipe */
> >
> > PIPE_BUF is a bit of an oddity. It is defined there, then redefined in
> > the arm header files, even though those header files are never included
> > anywhere. Also, PIPE_BUF is never referenced by name in any of the Linux
> > code. And yet, it is still being mentioned in some Big And Scary
> > Warnings (tm): fs/autofs4/waitq.c or include/linux/pipe_fs_i.h, for
> > example.
>
> it's for userland to tell it what the size of the atomic pipe operations
> we can do is.
>
How does userland get this value from the kernel? How does the kernel
code ensure that this value is honored, considering that PIPE_BUF is not
referenced in any of the pipe code?
- Vadim Lobanov
On Thu, 4 May 2006, Eric Piel wrote:
> 05/04/2006 07:55 AM, Vadim Lobanov wrote/a écrit:
> > Hi,
> Hi!
>
> > A snippet from include/linux/limits.h:
> > #define PIPE_BUF 4096 /* # bytes in atomic write to a pipe */
> >
> > PIPE_BUF is a bit of an oddity. It is defined there, then redefined in
> > the arm header files, even though those header files are never included
> > anywhere.
> Actually, here, on a 2.6.16 source code, PIPE_BUF is used in
> arch/sparc/kernel/sys_sunos.c, arch/sparc64/kernel/sys_sunos32.c, and
> arch/sparc64/solaris/fs.c . It seems it's some kind of compatibility
> value with Sun's OS...
Yes, I saw those. But they're really just "magic numbers" that userland
expects to see. In my opinion, the constant values should be inlined
into that compat code. Or, at best, moved into the sparc compat header
files.
> > Also, PIPE_BUF is never referenced by name in any of the Linux
> > code. And yet, it is still being mentioned in some Big And Scary
> > Warnings (tm): fs/autofs4/waitq.c or include/linux/pipe_fs_i.h, for
> > example.
> Maybe they wanted to say PIPE_BUFFERS ? (just wild guess)
Doesn't look like it to me. PIPE_BUFFERS stands for something else
entirely, if my understanding is correct. PIPE_BUF is the one that
"guarantees" atomicity.
> c u,
> Eric
>
- Vadim Lobanov
On Thu, 2006-05-04 at 09:39 -0700, Vadim Lobanov wrote:
> How does the kernel
> code ensure that this value is honored, considering that PIPE_BUF is
> not
> referenced in any of the pipe code?
the kernel implementation guarantees one page basically, and on all
architectures that I know of that's at least 4096 bytes
On Thu, 4 May 2006, Arjan van de Ven wrote:
> On Thu, 2006-05-04 at 09:39 -0700, Vadim Lobanov wrote:
> > How does the kernel
> > code ensure that this value is honored, considering that PIPE_BUF is
> > not
> > referenced in any of the pipe code?
>
>
> the kernel implementation guarantees one page basically, and on all
> architectures that I know of that's at least 4096 bytes
>
Alright, so sounds like this constant should remain inside the
include/linux/limits.h file. What about #defining it to be equal to
PAGE_SIZE, like ARM (include/linux-arm/limits.h, for example) does?
- Vadim Lobanov
On Thu, 2006-05-04 at 10:50 -0700, Vadim Lobanov wrote:
> On Thu, 4 May 2006, Arjan van de Ven wrote:
>
> > On Thu, 2006-05-04 at 09:39 -0700, Vadim Lobanov wrote:
> > > How does the kernel
> > > code ensure that this value is honored, considering that PIPE_BUF is
> > > not
> > > referenced in any of the pipe code?
> >
> >
> > the kernel implementation guarantees one page basically, and on all
> > architectures that I know of that's at least 4096 bytes
> >
>
> Alright, so sounds like this constant should remain inside the
> include/linux/limits.h file. What about #defining it to be equal to
> PAGE_SIZE, like ARM (include/linux-arm/limits.h, for example) does?
there is a certain elegance in providing the same value on all
architectures; it means apps don't suddenly break if you port it to
a "lesser" one. Also there is a problem with PAGE_SIZE itself, that's a
config option on several architectures, so it'd have to be a define for
get_page_size() or something, at which point you change semantics since
apps can't do
char foo[PIPE_BUF];
anymore
On Thu, 4 May 2006, Arjan van de Ven wrote:
> On Thu, 2006-05-04 at 10:50 -0700, Vadim Lobanov wrote:
> > On Thu, 4 May 2006, Arjan van de Ven wrote:
> >
> > > On Thu, 2006-05-04 at 09:39 -0700, Vadim Lobanov wrote:
> > > > How does the kernel
> > > > code ensure that this value is honored, considering that PIPE_BUF is
> > > > not
> > > > referenced in any of the pipe code?
> > >
> > >
> > > the kernel implementation guarantees one page basically, and on all
> > > architectures that I know of that's at least 4096 bytes
> > >
> >
> > Alright, so sounds like this constant should remain inside the
> > include/linux/limits.h file. What about #defining it to be equal to
> > PAGE_SIZE, like ARM (include/linux-arm/limits.h, for example) does?
>
> there is a certain elegance in providing the same value on all
> architectures; it means apps don't suddenly break if you port it to
> a "lesser" one. Also there is a problem with PAGE_SIZE itself, that's a
> config option on several architectures, so it'd have to be a define for
> get_page_size() or something, at which point you change semantics since
> apps can't do
>
> char foo[PIPE_BUF];
>
> anymore
>
Good point.
I suppose this means that the limits.h header file is used, either
directly or indirectly, by both us (the kernel) and by user-space? If
so, blech! What's the policy on keeping around config values that don't
do anything inside the kernel anymore? The short list is:
NR_OPEN
ARG_MAX
CHILD_MAX
OPEN_MAX
LINK_MAX
MAX_CANON
MAX_INPUT
RTSIG_MAX
- Vadim Lobanov