All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Stuart MacDonald <stuartm@connecttech.com>
Cc: "'Greg Folkert'" <greg@gregfolkert.net>,
	"'LKML'" <linux-kernel@vger.kernel.org>
Subject: Re: Greg's Decree! (was Re: Linus' decrees?)
Date: Fri, 25 Feb 2005 08:48:24 -0500	[thread overview]
Message-ID: <20050225134824.GA5977@thunk.org> (raw)
In-Reply-To: <002201c51abd$712cf500$294b82ce@stuartm>

On Thu, Feb 24, 2005 at 05:08:33PM -0500, Stuart MacDonald wrote:
> The post I reference mentions that Linus once said that a standard
> method to locate the source for a particular kernel would be to have
> it at /lib/modules/`uname -r`/build. This seems to be a symlink for
> vanilla kernels, and actual source for the FC3 installed kernels I
> have handy.
>
> I guess what I'm looking for is a collection of linux kernel policies.
> Is there such a collection?

Well, the place where Linus's policy surrounding 
/lib/modules/`uname -r`/build can be found in:

	/usr/src/linux/Makefile

The distributions (by and large) honor it, but other than that, you
seem to have a slightly overinflated view how much weight and how much
formalities such statements actually have.

The problem with collecting it, as other people have pointd out, is
that it implies that all such statements are valid forever (such as a
Pope's encyclical) or that we have some formal way of blessing a
statement by sprinkling Holy Penguin Pee on it, or some way of
retracting such a blessing (probably involving some ceremony involving
turning a candle upside down and snuffing it out :-).   

If the goal is to collect some hints about of out-of-kernel modules
and device drivers, there are places where that could be done, and I'd
probably suggest writing or updating a linux HOWTO as a part of the
Linux Documentation Project.  However, with the way in-kernel
interfaces are changing, one of things you will no doubt find as you
start collecting such hints is that the first hint is: "Get that
device driver or module into the mainline kernel sources; otherwise
your life will be nasty and brutish, and while perhaps not short, you
may soon wish it to be.  :-)"

						- Ted

  parent reply	other threads:[~2005-02-25 13:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-24 20:03 Linus' decrees? Stuart MacDonald
2005-02-24 21:30 ` Greg's Decree! (was Re: Linus' decrees?) Greg Folkert
2005-02-24 22:08   ` Stuart MacDonald
2005-02-24 22:40     ` Randy.Dunlap
2005-02-25  0:55       ` Horst von Brand
2005-02-25 14:45         ` Stuart MacDonald
2005-02-25  6:56     ` Valdis.Kletnieks
2005-02-25 14:51       ` Greg's Policy! (was Re: Linus' policies?) Stuart MacDonald
2005-02-25 13:48     ` Theodore Ts'o [this message]
2005-02-25  7:07   ` Greg's Decree! (was Re: Linus' decrees?) Andre Hedrick
2005-02-25 23:56     ` jmerkey
2005-02-25  7:04 ` Linus' decrees? Andre Hedrick

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=20050225134824.GA5977@thunk.org \
    --to=tytso@mit.edu \
    --cc=greg@gregfolkert.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stuartm@connecttech.com \
    /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.