All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Oberheide <jon@focalhost.com>
To: Bill Davidsen <davidsen@tmr.com>
Cc: linux-kernel@vger.kernel.org,
	viro@parcelfarce.linux.theplanet.co.uk,
	Paul Eggert <eggert@CS.UCLA.EDU>,
	linux-kernel@vger.kernel.org, akpm@osdl.org, bug-patch@gnu.org,
	bug-gnu-utils@gnu.org
Subject: Re: [PATCH] [RFC] adding support for .patches and /proc/patches.gz
Date: Wed, 12 May 2004 00:59:28 -0400	[thread overview]
Message-ID: <1084337968.31228.35.camel@latitude> (raw)
In-Reply-To: <c7r676$gvo$1@gatekeeper.tmr.com>

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

On Tue, 2004-05-11 at 14:37, Bill Davidsen wrote:
> Jon Oberheide wrote:
> > Greetings,
> > 
> > This feature has been brought up several times before, as can be seen
> > here:
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0404.3/0798.html
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.1/0598.html
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/9803.0/0223.html
> > 
> > For those unfamiliar, a file linux/.patches would be adding to the
> > source tree.  When applying patches to the source tree, descriptive
> > information would be written to .patches.  After compilation and running
> > of this kernel, the .patches information would be accessible through
> > /proc/patches.gz; similar to the /proc/config.gz feature.
> 
> The first question would be, patches between the current kernel and 
> what? Vendor kernel, people may not have it. Kernel.org kernal, just the 
> patches to a current vendor kernel diff would be pretty huge in some cases.

Any patches applied against the current vanilla kernel.org kernel would
be listed in .patches.  This would include vendor, third-party, and even
pre/bk/mm patches.  

Keep in mind, .patches would not contain the entire patch, as that would
be WAY to large, but just a short entry such as the name, date last
modified, and date applied of the patch file.

> Let's say it looks like a high cost/benefit ratio, would be much less 
> effective unless it were used for every patch, and feels like something 
> you might want to do within an organization rather than as a general 
> practice.

Exactly as I stated, adoption would be the hardest part.  Paul's idea of
adding an option to patch w/o breaking POSIX sounds like a way to go. 
Of course that would require widespread documentation updates and
contacting vendors but would be very possible.

> Sorry, you asked for comments...

No need to be sorry, thanks!  :)

Regards,
Jon Oberheide
jon@focalhost.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2004-05-12  4:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-10  2:48 [PATCH] [RFC] adding support for .patches and /proc/patches.gz Jon Oberheide
2004-05-10 18:37 ` Paul Eggert
2004-05-10 18:51   ` viro
2004-05-11  9:34     ` Jan-Benedict Glaw
2004-05-11 18:37 ` Bill Davidsen
2004-05-12  4:59   ` Jon Oberheide [this message]
2004-05-12  8:28     ` Cef (LKML)

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=1084337968.31228.35.camel@latitude \
    --to=jon@focalhost.com \
    --cc=akpm@osdl.org \
    --cc=bug-gnu-utils@gnu.org \
    --cc=bug-patch@gnu.org \
    --cc=davidsen@tmr.com \
    --cc=eggert@CS.UCLA.EDU \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /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.