All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Helsley <matthltc@us.ibm.com>
To: kernel-janitors@vger.kernel.org
Subject: Re: [KJ] Re: [PATCH] bug fix to include/linux/cn_proc.h for 2.6.16-rc5
Date: Tue, 28 Mar 2006 23:29:51 +0000	[thread overview]
Message-ID: <1143588591.12783.9.camel@stark> (raw)
In-Reply-To: <1142312124.24621.82.camel@stark>

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

On Thu, 2006-03-16 at 10:44 -0800, Nishanth Aravamudan wrote:
> On 16.03.2006 [09:56:13 -0800], Narasimha Sharoff wrote:
> > If time.h need not be included in cn_proc.h, is there
> > a reason not to apply this patch?
> 
> This only applies if there is no reason to include it *in the kernel*.
> The fact that it breaks an (arbitrary) userspace build is irrelevant (at
> least as far as KJ is concerned).
> 
> > As i see, not having time.h in cn_proc.h resolves user space problem i
> > am seeing. Kernel compilation seems to go ok (tried it on a ppc
> > system,2.6.16-rc5).
> 
> I would suggest giving the kernel side justification only, then, as
> uerspace should not be using kernel headers directly anyways.
> 
> > I do not know how the header files end up in /usr/include/linux
> > directory. Is there a standard process followed while packaging or is
> > this distro specific? Can someone forward me a pointer?
> 
> Distro specific, there's probably a package you can find that put the
> header there (apt-file search filename or dpkg -S filename can help on
> Debian-based distros). I would figure out why it's there (and if it
> should be). Complain to the connector folks about it, as well (or just
> bring it to their attention).
> 
> Thanks,
> Nish

	OK, I looked into it and the #include <time.h> is cruft leftover from
an attempt to add a nanosecond-scale timestamp function to the kernel. I
eventually stopped pushing that patch because I found a suitable
replacement however I accidentally left #include<time.h> in cn_proc.h

	I'll run some compile-tests with Narasimha's patch and then Ack it
assuming it doesn't break compilation.

Cheers,
	-Matt Helsley


[-- Attachment #2: Type: text/plain, Size: 168 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

      parent reply	other threads:[~2006-03-28 23:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-14  4:55 [KJ] Re: [PATCH] bug fix to include/linux/cn_proc.h for 2.6.16-rc5 Matt Helsley
2006-03-14  5:01 ` Matthew L Helsley
2006-03-14  7:17 ` Narasimha Sharoff
2006-03-14 14:38 ` Nishanth Aravamudan
2006-03-14 19:19 ` Matt Helsley
2006-03-16 17:56 ` Narasimha Sharoff
2006-03-16 18:44 ` Nishanth Aravamudan
2006-03-16 21:03 ` Matt Helsley
2006-03-28 23:29 ` Matt Helsley [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1143588591.12783.9.camel@stark \
    --to=matthltc@us.ibm.com \
    --cc=kernel-janitors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.