On Tue, Apr 03, 2001 at 12:30:14PM -0700, Mike Castle wrote:
> Some patches, such as the RAID patches, sets up EXTRAVERSION to a specific
> value.
- If you apply such a patch first, and after that you edit EXTRAVERSION,
your value will be used - no problem.
- If you edit EXTRAVERSION before app
J . A . Magallon wrote:
> On 04.03 Ben Ford wrote:
>
>> J . A . Magallon wrote:
>>
>>> If this has not been done for System.map, that is a much more important
>>> info for debug and oops, and the de facto standard is to put it aside
>>> kernel with some standadr naming, lets use the same method
On Tue, Apr 03, 2001 at 09:12:18PM +0200, J . A . Magallon wrote:
> Just like the Alan Cox for 2.4 or Andrea Arcangeli for 2.2. Lets say you
> have 2.4.2-ac27. For each of your compiles, set EXTRAVERSION to -ac27-bf1,
> -ac27-bf2, etc. Your files will be:
Some patches, such as the RAID patches, s
> That would be great and all, but can you tell me how to do it when I
> have 3 or 4 different compiles of the same kernel version?
Each compile you do already gets assigned a version #, if thats not enough then
add your own id string
-
To unsubscribe from this list: send the line "unsubscribe l
On 04.03 Ben Ford wrote:
> J . A . Magallon wrote:
> >
> > If this has not been done for System.map, that is a much more important
> > info for debug and oops, and the de facto standard is to put it aside
> > kernel with some standadr naming, lets use the same method for config.
> >
> That woul
J . A . Magallon wrote:
> On 04.03 David Lang wrote:
>
>> if the distro/sysadmin _always_ installs the kernel the 'right way' then
>> the difference isn't nessasarily that large, but if you want reliability
>> on any system it may be worth loosing a page or so of memory (hasn't
>> someone said t
> method) have these dependencies checked by insmod? It would be simply
> smashing to have it all inherently bullet proof. (i know never say never, but
> lower maintenance then or simpler for users or something)
The goal of modversions is to do this. It isnt perfect. Keith Owens was talking
abou
On 04.03 David Lang wrote:
>
> if the distro/sysadmin _always_ installs the kernel the 'right way' then
> the difference isn't nessasarily that large, but if you want reliability
> on any system it may be worth loosing a page or so of memory (hasn't
> someone said that the data can be compressed
Alan Cox wrote:
> > a module for 2.4.3 will work for any 2.4.3 kernel that supports modules
> > at all (except for the SMP vs UP issue) so it's not the same thing as
> > trying to figure out which if the 2.4.3 kernels matches what you are
> > running.
>
> Nope. The 2.4 kernel ABI depends upon a m
> a module for 2.4.3 will work for any 2.4.3 kernel that supports modules
> at all (except for the SMP vs UP issue) so it's not the same thing as
> trying to figure out which if the 2.4.3 kernels matches what you are
> running.
Nope. The 2.4 kernel ABI depends upon a mixture of config options inc
> a module for 2.4.3 will work for any 2.4.3 kernel that supports modules
> at all (except for the SMP vs UP issue) so it's not the same thing as
No, no, no. This is absolutely and dangerously wrong.
A module depends on the kernel configuration, because it may access
internal data structures of
On Mon, Apr 02, 2001 at 05:39:19PM -0700, David Lang wrote:
>
> if the distro/sysadmin _always_ installs the kernel the 'right way' then
> the difference isn't nessasarily that large, but if you want reliability
> on any system it may be worth loosing a page or so of memory (hasn't
> someone said
, 02 Apr 2001 20:49:09 -0400
> From: Jeff Garzik <[EMAIL PROTECTED]>
> To: Jeremy Jackson <[EMAIL PROTECTED]>
> Cc: Ian Soboroff <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: /proc/config idea
>
> Jeremy Jackson wrote:
> > If you have a lot of kernels
Jeremy Jackson wrote:
> If you have a lot of kernels around, which Config-2.4.3 applies to kernel 2.4.3
> given 5 to choose from...the idea (same for System.map) is that it being in the
> same
> file they can't be confused. Kinda like forks under Mac (but let's not go there
> now)
The same appli
g
On Mon, 2 Apr 2001, Jeff Garzik
wrote:
> Date: Mon, 02 Apr 2001 20:23:28 -0400
> From: Jeff Garzik <[EMAIL PROTECTED]>
> To: Jeremy Jackson <[EMAIL PROTECTED]>
> Cc: Ian Soboroff <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: /proc/config idea
>
Jeff Garzik wrote:
> Jeremy Jackson wrote:
> > Yes, I like this. I do this manually, it allows reproducability, and
> > incremental
> > modifications, tracing how that kernel on that problem system was made...
> >
> > I think the ultimate would be to put all of .config (gzipped?) in a new ELF
>
Jeremy Jackson wrote:
> Yes, I like this. I do this manually, it allows reproducability, and
> incremental
> modifications, tracing how that kernel on that problem system was made...
>
> I think the ultimate would be to put all of .config (gzipped?) in a new ELF
> section without the Loadable at
I see benefit in having the .config file in the kernel. It being a non
loadable elf section would be a plus. However I also see merit to having
it available as a proc entry.
Say that we decide to go with /proc/config. In that case I think that
Jeremy is right on with the compressing of the in
Jeremy Jackson wrote:
>
> Ian Soboroff wrote:
>
> > [sorry this doesn't have proper References: headers, i read the list
> > off the hypermail archive.]
> >
> > there was some discussion of whether the kernel should emit a
> > /proc/config or some such for purposes of bug reporting, but that
> >
Ian Soboroff wrote:
> [sorry this doesn't have proper References: headers, i read the list
> off the hypermail archive.]
>
> there was some discussion of whether the kernel should emit a
> /proc/config or some such for purposes of bug reporting, but that
> seems to be a lot of bloat.
>
> instead,
[sorry this doesn't have proper References: headers, i read the list
off the hypermail archive.]
there was some discussion of whether the kernel should emit a
/proc/config or some such for purposes of bug reporting, but that
seems to be a lot of bloat.
instead, why not try to point to a canonic
21 matches
Mail list logo
