Hi all.
As a result of private email correspondance I have recently received, I
became aware that the current system of identifying the versions of the
various subsystems required to support any particular kernel version is
inadequate, and decided to do something about it. The enclosed patch is
my offering to rectify this.
The problems identified are:
1. Different subsystems are identified in Documentation/Changes and in
scripts/ver_linux, probably due to the difficulty of maintaining two
files in sync with each other. As a result, it is not clear what the
required versions of some subsystems are.
2. The existing script does not make it clear which subsystems need to
be updated. The user is expected to decide by cross-referencing the
details it provides with those provided elsewhere.
3. The command to perform this analysis is not immediately obvious.
My offering (developed against the 2.4.2 kernel source tree) does away
with all three of these problems by:
A. Making Documentation/Changes the sole source of information on the
subsystems required. The script I have developed then reads the
table in this file, and uses commands listed therein to determine
the installed versions of the relevant subsystems. The format of
this table had to be changed slightly to accommodate the script,
but this was done without impairing the readability thereof.
B. Adding lines to Documentation/Changes to document those subsystems
listed by scripts/ver_linux that were not already in the table in
Documentation/Changes so that all relevant subsystems are considered.
This was done by adding a separate table formatted identically to the
existing one, but indicating that the subsystems therein may not be
required.
Note that the "required versions" listed in this new table are those
installed on my system, with the exception of the Linux C++ library
which is apparently not installed here. These versions need to be
tweaked to reflect the actual requirements for that kernel.
C. Comparing the installed and required versions of each subsystem, and
indicating the results of that comparison in the displayed results
by colouring the name of the subsystem. A facility to disable this
is also included, and is activated by providing a parameter to the
script. Any parameter will serve this function.
D. Inserting lines in the primary Makefile to allow `make vsn` to run
the relevant command to generate the results with colouring, and
`make vsnbw` to do so without colours. Both change the permissions
of the script to make it an executable.
There is ONE problem with this method, which I have not been able to
solve. This is that the command used by scripts/ver_linux to determine
the installed version of the Gnu C Library can't be replicated using
the method this script is based on, and I have had to replace it with a
simpler script which may produce different results in some cases. If this
is a problem, it is open to others to solve as I have licensed this under
version 2 (only) of the Gnu General Public Licence.
Best wishes from Riley.
On Wed, Mar 14, 2001 at 10:39:53AM +0000, Riley Williams wrote:
> -o util-linux 2.10o # fdformat --version
> +o util-linux # 2.10o # fdformat --version
Looking at fdformat to get the util-linux version is perhaps
not the most reliable way - some people have fdformat from fd-utils or so.
Using mount --version would be better - I am not aware of any
other mount distribution.
> +In addition, it is wise to ensure that the following packages are at least
> +at the versions suggested below, although these may not be required,
> +depending on the exact configuration of your system:
> +
> +o Console Tools # 0.3.3 # loadkeys -V
> +o Mount # 2.10e # mount --version
Concerning mount: (i) the version mentioned is too old,
(ii) mount is in util-linux. Conclusion: the mount line
should be deleted entirely.
Concerning Console Tools: maybe kbd-1.05 is uniformly better.
I am not aware of any reason to recommend the use of console-tools.
Andries
On Wed, 14 Mar 2001 [email protected] wrote:
> > +o Console Tools # 0.3.3 # loadkeys -V
> > +o Mount # 2.10e # mount --version
>
> Concerning mount: (i) the version mentioned is too old,
> (ii) mount is in util-linux. Conclusion: the mount line
> should be deleted entirely.
Many systems have mount (and bsdutils) separated from util-linux
as a binary package. Built from the same source, indeed, but...
> Concerning Console Tools: maybe kbd-1.05 is uniformly better.
> I am not aware of any reason to recommend the use of console-tools.
Debian has console-tools with priority:required and kbd with priority:extra.
Take it with Yann Dirson...
Cheers,
Al
> Many systems have mount (and bsdutils) separated from util-linux
> as a binary package. Built from the same source, indeed, but...
I hope that this habit is dying. Long ago that was
reasonable, but these days (years) it only causes extra work.
>> Concerning Console Tools: maybe kbd-1.05 is uniformly better.
>> I am not aware of any reason to recommend the use of console-tools.
> Debian has console-tools with priority:required and kbd with priority:extra.
> Take it with Yann Dirson...
I am not aware of any reason to recommend the use of console-tools.
Andries
[email protected] writes:
>Looking at fdformat to get the util-linux version is perhaps
>not the most reliable way - some people have fdformat from fd-utils or so.
>Using mount --version would be better - I am not aware of any
>other mount distribution.
Bad idea. RedHat has mount and util-linux in different RPMs (at least 6.x).
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
Hi Andries.
>> -o util-linux 2.10o # fdformat --version
>> +o util-linux # 2.10o # fdformat --version
> Looking at fdformat to get the util-linux version is perhaps not
> the most reliable way - some people have fdformat from fd-utils
> or so.
{Shrug} That's the command that was in both Documentation/Changes and
in scripts/ver_linux and I just left what was already there, as shown
by your quote. Somebody MUCH more knowledgable than me regarding
kernel requirements can sort that out.
> Using mount --version would be better - I am not aware of any
> other mount distribution.
RedHat distribute mount separately from util-linux and I wouldnae be
surprised if others do the same...
>> +In addition, it is wise to ensure that the following packages are at least
>> +at the versions suggested below, although these may not be required,
>> +depending on the exact configuration of your system:
>> +
>> +o Console Tools # 0.3.3 # loadkeys -V
>> +o Mount # 2.10e # mount --version
> Concerning mount:
>
> (i) the version mentioned is too old,
Probably. As stated, that's what's currently installed here, and I
havenae the foggiest whether any of them need upgrading as there's
nothing I've been able to find to say what the minimum version is.
> (ii) mount is in util-linux.
Not on RedHat systems.
> Conclusion: the mount line should be deleted entirely.
Maybe, but that's not for me to decide. Whoever wrote ver_linux
obviously thought it important.
> Concerning Console Tools: maybe kbd-1.05 is uniformly better.
> I am not aware of any reason to recommend the use of console-tools.
Neither am I. The ver_linux script has lines for determining the
versions for both Console Tools and Kbd but on EVERY system I've
tried, including Slackware, RedHat, Debian, Caldera, and SuSE based
ones, the line for determining Kbd versiondoesnae work. I've just
included the line that worked, and ignored the Kbd one as I can see no
point including something that doesnae work.
Best wishes from Riley.
From: Riley Williams <[email protected]>
[Yes, I wrote, replying to your mail, just because I happened
to notice the incorrect or debatable lines in your patch.
Let me cc the Changes maintainer - maybe Chris Ricker.]
>> -o util-linux 2.10o # fdformat --version
>> +o util-linux # 2.10o # fdformat --version
> Looking at fdformat to get the util-linux version is perhaps not
> the most reliable way - some people have fdformat from elsewhere.
> Using mount --version would be better - I am not aware of any
> other mount distribution.
RedHat distribute mount separately from util-linux and I wouldnae be
surprised if others do the same...
I am not aware of any distribution that ships some version of
util-linux, but replaces its mount part by an older version.
I think that even in cases where, because of historical reasons, util-linux
is repackaged in several parts, mount --version gives the right answer.
>> +In addition, it is wise to ensure that the following packages are
>> +at least at the versions suggested below, although these may not
>> +be required, depending on the exact configuration of your system:
>> +
>> +o Console Tools # 0.3.3 # loadkeys -V
>> +o Mount # 2.10e # mount --version
> Concerning mount:
>
> (i) the version mentioned is too old,
> (ii) mount is in util-linux.
Not on RedHat systems.
There is no other source. Some people like to repack but that
has no influence on versions.
> Conclusion: the mount line should be deleted entirely.
> Concerning Console Tools: maybe kbd-1.05 is uniformly better.
> I am not aware of any reason to recommend the use of console-tools.
Neither am I. The ver_linux script has lines for determining the
versions for both Console Tools and Kbd but on EVERY system I've
tried, including Slackware, RedHat, Debian, Caldera, and SuSE based
ones, the line for determining Kbd versiondoesnae work. I've just
included the line that worked, and ignored the Kbd one as I can see no
point including something that doesnae work.
You are mistaken, as is proved by the reports that contain a kbd line:
a grep on linux-kernel for this Februari shows people with
Kbd 0.96, 0.99 and 1.02.
Andries
On Wed, Mar 14, 2001 at 08:29:53PM +0100, [email protected] wrote:
> There is no other source. Some people like to repack but that
> has no influence on versions.
I believe that RedHat don't build mount and util-linux from the same tree.
Maybe they do internally, but when you look at the RPMs, they appear
separate:
Name: mount
Source RPM: mount-2.10m-6.src.rpm
Name: util-linux
Source RPM: util-linux-2.10m-12.src.rpm
There don't appear to be any explicit dependencies between these two
packages either, but they do just happen to have the same version.
(I'm looking at the RH7.0 RPMs here).
This of course means that the version of mount may not match the version
of util-linux installed on the system.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Alexander Viro writes:
> On Wed, 14 Mar 2001 [email protected] wrote:
>>> +o Console Tools # 0.3.3 # loadkeys -V
>>> +o Mount # 2.10e # mount --version
>>
>> Concerning mount: (i) the version mentioned is too old,
Exactly why? Mere missing features don't make for a required
upgrade. Version number inflation should be resisted.
>> Concerning Console Tools: maybe kbd-1.05 is uniformly better.
>> I am not aware of any reason to recommend the use of console-tools.
>
> Debian has console-tools with priority:required and kbd
> with priority:extra. Take it with Yann Dirson...
Both should be "extra". They can be removed from the version script.
I'm even one of the few remaining console users.
From: "Albert D. Cahalan" <[email protected]>
> On Wed, 14 Mar 2001 [email protected] wrote:
>>> +o Console Tools # 0.3.3 # loadkeys -V
>>> +o Mount # 2.10e # mount --version
>>
>> Concerning mount: (i) the version mentioned is too old,
Exactly why? Mere missing features don't make for a required
upgrade. Version number inflation should be resisted.
These days you can mount filesystems several places.
That means that the choice one used to have -- after
# mount dev dir
both
# umount dev
and
# umount dir
would unmount -- has disappeared, and only
# umount dir
is (guaranteed to be) right today.
These days you can mount several filesystems at the same mount point.
The old mount does not understand this at all.
Recent versions of mount act better in this respect,
even though it is still easy to confuse them.
Such things mean that it is best to have a really recent mount
(although, of course, if you only want the mount(2) system call
executed some five year old version will also do that for you).
On the other hand, there are no important changes between
mount-2.10d and 2.10e, so I see no justification for writing 2.10e.
It is difficult to say what the "right" version is. There is a
long series of minor improvements. Probably I would write 2.10r.
Andries
[email protected] wrote:
> > On Wed, 14 Mar 2001 [email protected] wrote:
>
> >>> +o Console Tools # 0.3.3 # loadkeys -V
> >>> +o Mount # 2.10e # mount --version
> >>
> >> Concerning mount: (i) the version mentioned is too old,
> On the other hand, there are no important changes between
> mount-2.10d and 2.10e, so I see no justification for writing 2.10e.
> It is difficult to say what the "right" version is. There is a
> long series of minor improvements. Probably I would write 2.10r.
Guys,
How about making a column that says: "recommended".
So in this case we'd see 2.10r as recommended, but 2.10e as required.
An explanation could state that:
if you happen to have the version under "required", but a higher
version is listed under "recommended", then that newer version is
available, and but it is likely that one you have will work for
you. There is no urgent reason to upgrade. But if you happen to be
upgrading, you are advised upgrade to at least the version in the
"recommended" column, as that has fixes over the one mentioned in the
"required" column.
Best regards,
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
Hi Andries.
> [Yes, I wrote, replying to your mail, just because I happened to
> notice the incorrect or debatable lines in your patch. Let me cc
> the Changes maintainer - maybe Chris Ricker.]
>>>> -o util-linux 2.10o # fdformat --version
>>>> +o util-linux # 2.10o # fdformat --version
>>> Looking at fdformat to get the util-linux version is perhaps not
>>> the most reliable way - some people have fdformat from elsewhere.
>>> Using mount --version would be better - I am not aware of any
>>> other mount distribution.
>> RedHat distribute mount separately from util-linux and I
>> wouldnae be surprised if others do the same...
> I am not aware of any distribution that ships some version of
> util-linux, but replaces its mount part by an older version. I
> think that even in cases where, because of historical reasons,
> util-linux is repackaged in several parts, mount --version gives
> the right answer.
Neither am I - but, according to comments from RedHat a while back,
they repackage mount separately because they provide a NEWER version
of mount than is in the util-linux package. This will ALSO result in
`mount --version` giving the wrong answer...
>>>> +In addition, it is wise to ensure that the following packages are
>>>> +at least at the versions suggested below, although these may not
>>>> +be required, depending on the exact configuration of your system:
>>>> +
>>>> +o Console Tools # 0.3.3 # loadkeys -V
>>>> +o Mount # 2.10e # mount --version
>>> Concerning mount:
>>>
>>> (i) the version mentioned is too old,
>> As stated in my original post, I've no idea what the correct
>> version should be as it's not documented anywhere I can find.
>>> (ii) mount is in util-linux.
>> Not on RedHat systems.
> There is no other source. Some people like to repack but that
> has no influence on versions.
Unless one can guarantee that the util-linux and mount packages are
the SAME version, mount can't be guaranteed to report the version of
the util-linux package installed. RedHat provide a NEWER version of
mount to util-linux so that guarantee doesnae exist.
>>> Conclusion: the mount line should be deleted entirely.
Conclusion: Both the mount and util-linux lines are REQUIRED.
>>> Concerning Console Tools: maybe kbd-1.05 is uniformly better.
>>> I am not aware of any reason to recommend the use of
>>> console-tools.
>> Neither am I. The ver_linux script has lines for determining the
>> versions for both Console Tools and Kbd but on EVERY system I've
>> tried, including Slackware, RedHat, Debian, Caldera, and SuSE
>> based ones, the line for determining Kbd versiondoesnae work.
>> I've just included the line that worked, and ignored the Kbd one
>> as I can see no point including something that doesnae work.
> You are mistaken, as is proved by the reports that contain a kbd
> line: a grep on linux-kernel for this Februari shows people with
> Kbd 0.96, 0.99 and 1.02.
{Shrug} Please explain why I was unable to get ver_linux to report a
kbd line on ANY of the systems I tried, including systems with it
definately installed. I tried it out manually on several such systems,
and ALL reported the SAME error message to the `loadkeys -h` command
used in scripts/ver_linux which is:
Q> $ loadkeys -h 2>&1 > x
Q> Usage: loadkeys [option...] [mapfile...]
Q> valid options are:
Q> -c --clearcompose clear kernel compose table
Q> -d --default load default keymap file
Q> -m --mktable output a "defkeymap.c" to stdout
Q> -s --clearstrings clear kernel string table
Q> -q --quiet be silent
Q> -v --verbose report the changes
Q> -v --verbose report more changes
Q> -h --help display this help text and exit
Q> -V --version display version information and exit
Q> $
Also, please advise where the version number is in that text...
Best wishes from Riley.
From: Riley Williams <[email protected]>
Neither am I - but, according to comments from RedHat a while back,
they repackage mount separately because they provide a NEWER version
of mount than is in the util-linux package. This will ALSO result in
`mount --version` giving the wrong answer...
There is no newer version.
In ancient times I came with frequent releases of mount, at a time
when util-linux was released very infrequently. These years mount
is part of util-linux, and util-linux is released frequently.
Unless one can guarantee that the util-linux and mount packages are
the SAME version, mount can't be guaranteed to report the version of
the util-linux package installed. RedHat provide a NEWER version of
mount to util-linux so that guarantee doesnae exist.
I do not think they do.
> You are mistaken, as is proved by the reports that contain a kbd
> line: a grep on linux-kernel for this Februari shows people with
> Kbd 0.96, 0.99 and 1.02.
{Shrug} Please explain why I was unable to get ver_linux to report a
When other people can and you cannot, why should I explain your failure?
Let me just check. A version from 1993:
% ./loadkeys -h 2>&1 | head -1
loadkeys version 0.81
A version from 2001:
% ./loadkeys -h 2>&1 | head -1
loadkeys version 1.06
Maybe nothing has changed here the past eight years. It just works.
Perhaps you tried some modified version.
Andries
[email protected] writes:
> From: Riley Williams <[email protected]>
> {Shrug} Please explain why I was unable to get ver_linux to report a
>
> % ./loadkeys -h 2>&1 | head -1
> loadkeys version 1.06
>
> Maybe nothing has changed here the past eight years. It just works.
> Perhaps you tried some modified version.
Debian 2.2 has loadkeys from a console-tools package, which can be found
at http://lct.sourceforge.net/
$ loadkeys --version
loadkeys: (console-tools) 0.2.3
--
`O O' | [email protected]
// ^ \\ | http://www.pyrites.org.uk/
Hi Andries.
> Neither am I - but, according to comments from RedHat a while back,
> they repackage mount separately because they provide a NEWER version
> of mount than is in the util-linux package. This will ALSO result in
> `mount --version` giving the wrong answer...
> There is no newer version.
Why do RedHat claim there is then?
> In ancient times I came with frequent releases of mount, at a time
> when util-linux was released very infrequently. These years mount
> is part of util-linux, and util-linux is released frequently.
{Shrug} Persuade RedHat of that, not me - they're the ones who release
it separately. Taken directly from RedHat's FTP site, I note that Red
Hat 6.2 includes RPM's for both mount-2.10f-1.i386.rpm and
util-linux-2.10f-7.i386.rpm which, whilst different releases of the
same version, is sufficient to prove your argument false. I can't get
into their 7.0 tree atm to check due to network congestion, so can't
comment on that...
> Unless one can guarantee that the util-linux and mount packages are
> the SAME version, mount can't be guaranteed to report the version of
> the util-linux package installed. RedHat provide a NEWER version of
> mount to util-linux so that guarantee doesnae exist.
> I do not think they do.
{Shrug} Thinking isn't sufficient - check your facts.
> > You are mistaken, as is proved by the reports that contain a kbd
> > line: a grep on linux-kernel for this Februari shows people with
> > Kbd 0.96, 0.99 and 1.02.
>
> {Shrug} Please explain why I was unable to get ver_linux to report a
> When other people can and you cannot, why should I explain your failure?
> Let me just check. A version from 1993:
> % ./loadkeys -h 2>&1 | head -1
> loadkeys version 0.81
>
> A version from 2001:
>
> % ./loadkeys -h 2>&1 | head -1
> loadkeys version 1.06
> Maybe nothing has changed here the past eight years. It just works.
> Perhaps you tried some modified version.
I tried the version that came as part of Red Hat 6.2 as installed
unmodified on the system I'm using. According to the rpm command, I
see...
Q> $ rpm -qf `which loadkeys`
Q> console-tools-19990829-10
Q> $
I've now tried that on FOUR different systems running Red Hat 6.2, the
last of them a fresh install direct from genuine RH 6.2 CD's with NO
changes since, and all four report the same and do exactly the same to
the command in ver_linux so I have to assume that the command in
ver_linux is UNABLE to determine a version number with this release of
Linux.
Best wishes from Riley.
> {Shrug} Thinking isn't sufficient - check your facts.
Poor Riley,
Probably I should not answer, I think you know all the facts already.
But just to be sure:
(i) There are two different packages, kbd and a forked version,
console-tools. Both contain roughly the same programs.
In your earlier mails you seemed aware of that, but now you report
that the console-tools version of loadkeys does not want to
print a kbd version. No surprise there.
(ii) I am the maintainer of both mount and util-linux.
If I say that there exists no more recent version of mount
than the one found in util-linux, you can believe me.
Andries
Andries.Brouwer writes:
>> From: "Albert D. Cahalan" <[email protected]>
>>> On Wed, 14 Mar 2001 [email protected] wrote:
>>>>> +o Console Tools # 0.3.3 # loadkeys -V
>>>>> +o Mount # 2.10e # mount --version
>>>>
>>>> Concerning mount: (i) the version mentioned is too old,
>>
>> Exactly why? Mere missing features don't make for a required
>> upgrade. Version number inflation should be resisted.
...
> These days you can mount several filesystems at the same mount point.
> The old mount does not understand this at all.
> Recent versions of mount act better in this respect,
> even though it is still easy to confuse them.
The rule should be like this:
List the lowest version number required to get
2.2.xx-level features while running a 2.4.xx kernel.
Remember what the purpose of the table is. It is a list of REQUIRED
upgrades. Failure to upgrade should result in a broken system. So pppd
must be listed, since somebody changed the kernel API for 2.4.1.
If I run the mount command from Red Hat 6.2, using it as intended
for a 2.2.xx kernel, doesn't everything work? There won't be any
multi-mount confusion because 2.2.xx can't do that anyway. There
isn't any problem with NFSv3 either, since 2.2.xx lacks NFSv3.
Basically I ask: would existing scripts for a 2.2.xx kernel break?
If the old mount can still do what it used to do, then "mount" need
not be listed at all.
> If the old mount can still do what it used to do,
> then "mount" need not be listed at all.
Well, I started saying that the mount line should be deleted,
so we somewhat agree.
> If I run the mount command from Red Hat 6.2, using it
> as intended for a 2.2.xx kernel, doesn't everything work?
Roughly, yes. (In other words: no.)
Andries
Hi Andries.
>> {Shrug} Thinking isn't sufficient - check your facts.
> Poor Riley,
>
> Probably I should not answer, I think you know all the facts
> already. But just to be sure:
> (i) There are two different packages, kbd and a forked version,
> console-tools. Both contain roughly the same programs. In your
> earlier mails you seemed aware of that, but now you report that
> the console-tools version of loadkeys does not want to print a
> kbd version. No surprise there.
You make claims for me there that I've never made, so can I suggest
you get your facts right this time. For reference:
1. My claim was NOT that the loadkeys from console-tools does
not print a kbd version, as you claim in the comment quoted
above. I claimed that it doesn't print ANY version, including
one for loadkeys itself.
2. YOUR claim was that the loadkeys command ALWAYS displays the
version number, so the command in ver_linux is thus always
guaranteed to produce a version number. MY claim was that
at least one loadkeys command fails to do so, and thus that
one can't expect it to do so.
Thank you for confirming that your claim was false.
> (ii) I am the maintainer of both mount and util-linux.
> If I say that there exists no more recent version of mount
> than the one found in util-linux, you can believe me.
Neither of us has claimed otherwise, nor have we been disputing that.
YOUR claim was that all systems always have the same version of mount
and util-linux installed, even when they are from different packages.
MY claim was that no such guarantee can be given, as it's possible for
somebody to upgrade either without upgrading the other when they are
supplied separately.
Again, thank you for confirming that your claimwas false.
Best wishes from Riley.
Hi Albert.
>>>>>> +o Mount # 2.10e # mount --version
>>>>> Concerning mount: (i) the version mentioned is too old,
>>> Exactly why? Mere missing features don't make for a required
>>> upgrade. Version number inflation should be resisted.
>> These days you can mount several filesystems at the same mount
>> point. The old mount does not understand this at all. Recent
>> versions of mount act better in this respect, even though it is
>> still easy to confuse them.
> The rule should be like this:
> List the lowest version number required to get
> 2.2.xx-level features while running a 2.4.xx kernel.
That's a meaningless definition, and can only be taken as such. What
use would such a list be to somebody wishing (like I recently was) to
upgrade a system running the 2.0.12 kernel so it runs the 2.4.2
kernel instead?
The ONLY kernel version that any list can be meaningful for is that of
the kernel source tree it is a member of, and that leads to the
following definition for the versions to be included in such a list:
List the lowest version number required to compile
this kernel, and to allow the resulting kernel to
be used as the heart of a running system.
Basically, required upgrades can fall into any of the following
categories, and need to be dealt with accordingly:
1. Development tools used to compile and/or link the kernel.
2. System libraries needed to run these development tools:
3. System tools that interact intimately with the kernel. If
the kernel interface changes in an incompatible way, these
will also need to be updated.
4. System tools that analyse kernel-supplied information and
advise the user of the results.
5. Other tools that are dependant on kernel version.
6. Other tools that have been upgraded.
My opinion is that only tools that fall in category (6) should be
omitted from the list.
> Remember what the purpose of the table is. It is a list of
> REQUIRED upgrades. Failure to upgrade should result in a broken
> system. So pppd must be listed, since somebody changed the
> kernel API for 2.4.1.
> If I run the mount command from Red Hat 6.2, using it as
> intended for a 2.2.xx kernel, doesn't everything work? There
> won't be any multi-mount confusion because 2.2.xx can't do that
> anyway. There isn't any problem with NFSv3 either, since 2.2.xx
> lacks NFSv3.
Whilst that's a good question, it misses the whole point of such a
list. Can I replace it with a more realistic one:
If I take a random Linux-based system and boot it using
the kernel I've just compiled using this kernel source
tree, will it work? If not, what is the minimum that I
need to upgrade to make it work?
Remember, there's absolutely NOTHING in ANY of the kernel source trees
that depends on what a particular user is running on their system
before they get that source tree.
> Basically I ask: would existing scripts for a 2.2.xx kernel
> break? If the old mount can still do what it used to do, then
> "mount" need not be listed at all.
Replace that "a 2.2.xx" with "my current" and remove all restrictions
on what the current kernel is, and that becomes an important question.
After all, if I take the network print server I'm running with a
2.0.19 kernel and drop a 2.4.2 kernel in, will it work without any
other changes?
Best wishes from Riley.
Riley Williams writes:
>> The rule should be like this:
>>
>> List the lowest version number required to get
>> 2.2.xx-level features while running a 2.4.xx kernel.
>
> That's a meaningless definition, and can only be taken as such. What
> use would such a list be to somebody wishing (like I recently was) to
> upgrade a system running the 2.0.12 kernel so it runs the 2.4.2
> kernel instead?
...
>> Basically I ask: would existing scripts for a 2.2.xx kernel
>> break? If the old mount can still do what it used to do, then
>> "mount" need not be listed at all.
>
> Replace that "a 2.2.xx" with "my current" and remove all restrictions
> on what the current kernel is, and that becomes an important question.
No, not "my current" but "the previous stable". I say "2.2.xx" because
that is the previous stable kernel.
If you upgrade from 2.0.xx, you should read the 2.2.xx changes file.
The important thing is to avoid version number inflation. I don't
even bother reading the changes file, because I know it is bogus.
Nearly all of my old software works great with a 2.4.xx kernel.
Hi Albert.
>>> The rule should be like this:
>>>
>>> List the lowest version number required to get
>>> 2.2.xx-level features while running a 2.4.xx kernel.
>> That's a meaningless definition, and can only be taken as such. What
>> use would such a list be to somebody wishing (like I recently was) to
>> upgrade a system running the 2.0.12 kernel so it runs the 2.4.2
>> kernel instead?
> ...
>>> Basically I ask: would existing scripts for a 2.2.xx kernel
>>> break? If the old mount can still do what it used to do, then
>>> "mount" need not be listed at all.
>> Replace that "a 2.2.xx" with "my current" and remove all restrictions
>> on what the current kernel is, and that becomes an important question.
> No, not "my current" but "the previous stable". I say "2.2.xx" because
> that is the previous stable kernel.
Again, saying either "2.2.xx" or "the previous stable" is meaningless.
Saying "The 2.2 kernel series" might have some meaning if it was not
for the fact that the requirements differ for different members of
that (or any other) kernel series.
On Saturday night, I had the pleasure of upgrading a system from the
2.2.4 kernel to the 2.4.2 one, and another system from the 2.2.14
kernel to the 2.4.2 one. Although the target kernel version was the
same, several subsystems needed upgrading on the former that did NOT
need upgrading on the latter, and that was just to compile the thing!
According to you, both of these upgrades would have required EXACTLY
THE SAME upgrades to be made, but that isn't the case.
> If you upgrade from 2.0.xx, you should read the 2.2.xx changes file.
Fairy Nuff.
However, your argument still fails, simply because of its reliance on
the assumption that an entire kernel series has static requirements
when such just isn't the case.
> The important thing is to avoid version number inflation. I don't
> even bother reading the changes file, because I know it is bogus.
> Nearly all of my old software works great with a 2.4.xx kernel.
The fact that you said "Nearly all" shows that your argument is false,
since your argument has been that NO software needs upgrading.
Can I suggest that you re-read my previous missive, and actually look
at the points raised. If you do, we might just get a sensible
discussion on this subject...
Incidentally, your argument to date has assumed that everybody always
installs every single kernel version. In my opinion, that is a very
dangerous assumption to make. A more responsible assumption would be
that the person wishing to upgrade to the version in this particular
kernel source tree has a random system installed, and wishes to know:
1. What is the absolute minimum upgrades required to compile the
kernel in the source tree I have just downloaded?
2. What is the absolute minimum upgrades required to install the
kernel in the source tree I have just downloaded and compiled?
3. What is the absolute minimum upgrades required to enable me
to run the kernel I have just compiled from this source tree,
assuming that I wish to retain the use of the shell scripts
that I developed under my previous kernel?
4. What other upgrades are recommended for reasons of system
security or stability?
5. What further upgrades are required to enable me to make use
of the advertised new facilities in this kernel?
6. What additional subsystems could be upgraded if desired?
7. I note that some upgrades are only required if certain of the
subsystems are installed. Which upgrades are these, and which
subsystems are they dependant on?
Personally, I'd be quite willing to work on a system to document the
requirements and classifying each requirement according to the above
system. However, as a pre-requisite, I would need agreement that such
was (a) worth doing, and (b) of interest to the kernel developers.
Best wishes from Riley.
Riley Williams writes:
> Hi Albert.
>>>> The rule should be like this:
>>>>
>>>> List the lowest version number required to get
>>>> 2.2.xx-level features while running a 2.4.xx kernel.
>>> Replace that "a 2.2.xx" with "my current" and remove all
>>> restrictions on what the current kernel is, and that becomes
>>> an important question.
>>
>> No, not "my current" but "the previous stable". I say "2.2.xx"
>> because that is the previous stable kernel.
>
> Again, saying either "2.2.xx" or "the previous stable" is meaningless.
> Saying "The 2.2 kernel series" might have some meaning if it was not
> for the fact that the requirements differ for different members of
> that (or any other) kernel series.
Oh please. List whatever the hell is needed for an upgrade from any
of 2.2, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5, ..., 2.2.255 of course.
Also include previous 2.4.xx kernels, in case some bastard decided to
break stuff within a stable kernel series... like PPP for example.
> On Saturday night, I had the pleasure of upgrading a system from the
> 2.2.4 kernel to the 2.4.2 one, and another system from the 2.2.14
> kernel to the 2.4.2 one. Although the target kernel version was the
> same, several subsystems needed upgrading on the former that did NOT
> need upgrading on the latter, and that was just to compile the thing!
So what? Your point is??? Obviously one system was partly upgraded.
> According to you, both of these upgrades would have required EXACTLY
> THE SAME upgrades to be made, but that isn't the case.
I never claimed that.
>> If you upgrade from 2.0.xx, you should read the 2.2.xx changes file.
>
> Fairy Nuff.
>
> However, your argument still fails, simply because of its reliance on
> the assumption that an entire kernel series has static requirements
> when such just isn't the case.
There is no such assumption.
If 2.2.4 needs foo-1.7 while 2.2.5 and 2.4.4 need foo-1.8, then
foo gets listed. If 2.1.99 needs bar-0.6 while 2.2.0 and 2.4.4
need bar 0.7, then there is no need to list bar. Never mind that
both foo and bar are up to version 666, since that isn't needed.
>> The important thing is to avoid version number inflation. I don't
>> even bother reading the changes file, because I know it is bogus.
>> Nearly all of my old software works great with a 2.4.xx kernel.
>
> The fact that you said "Nearly all" shows that your argument is false,
> since your argument has been that NO software needs upgrading.
>
> Can I suggest that you re-read my previous missive, and actually look
> at the points raised. If you do, we might just get a sensible
> discussion on this subject...
Try it yourself, w/o alcohol. I didn't argue "NO software...".
> Incidentally, your argument to date has assumed that everybody always
> installs every single kernel version. In my opinion, that is a very
> dangerous assumption to make.
Nope. Most people go from one stable series to the next, often skipping
the first and last few revisions. (2.2.6, 2.2.9, 2.2.17, 2.4.3, 2.4.8...)
> A more responsible assumption would be
> that the person wishing to upgrade to the version in this particular
> kernel source tree has a random system installed, and wishes to know:
That random system should be capable of working with at least
one kernel from the previous stable series.
> 1. What is the absolute minimum upgrades required to compile the
> kernel in the source tree I have just downloaded?
>
> 2. What is the absolute minimum upgrades required to install the
> kernel in the source tree I have just downloaded and compiled?
>
> 3. What is the absolute minimum upgrades required to enable me
> to run the kernel I have just compiled from this source tree,
> assuming that I wish to retain the use of the shell scripts
> that I developed under my previous kernel?
>
> 4. What other upgrades are recommended for reasons of system
> security or stability?
Good, assuming "reasons of system security or stability" relates
to problems that a kernel upgrade might cause.
> 5. What further upgrades are required to enable me to make use
> of the advertised new facilities in this kernel?
This is noise. Such upgrades are not required.
> 6. What additional subsystems could be upgraded if desired?
This is worse noise: "...and The GIMP is now at version..."
> 7. I note that some upgrades are only required if certain of the
> subsystems are installed. Which upgrades are these, and which
> subsystems are they dependant on?
This is getting too fancy.
Hi Albert.
Since you appear to be determined to ignore reason and stick to your
misguided guns I'll leave you to destroy all the good work that has
gone into the Linux kernel's documentation and make it something even
Bill Gates would be proud of. However, I'll stick to documentation
that actually tells people what they need to know whilst you do so.
Best wishes from Riley.
*********************************************************************
On Fri, 23 Mar 2001, Albert D. Cahalan wrote:
> Riley Williams writes:
> > Hi Albert.
>
> >>>> The rule should be like this:
> >>>>
> >>>> List the lowest version number required to get
> >>>> 2.2.xx-level features while running a 2.4.xx kernel.
>
> >>> Replace that "a 2.2.xx" with "my current" and remove all
> >>> restrictions on what the current kernel is, and that becomes
> >>> an important question.
> >>
> >> No, not "my current" but "the previous stable". I say "2.2.xx"
> >> because that is the previous stable kernel.
> >
> > Again, saying either "2.2.xx" or "the previous stable" is meaningless.
> > Saying "The 2.2 kernel series" might have some meaning if it was not
> > for the fact that the requirements differ for different members of
> > that (or any other) kernel series.
>
> Oh please. List whatever the hell is needed for an upgrade from any
> of 2.2, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5, ..., 2.2.255 of course.
> Also include previous 2.4.xx kernels, in case some bastard decided to
> break stuff within a stable kernel series... like PPP for example.
>
> > On Saturday night, I had the pleasure of upgrading a system from the
> > 2.2.4 kernel to the 2.4.2 one, and another system from the 2.2.14
> > kernel to the 2.4.2 one. Although the target kernel version was the
> > same, several subsystems needed upgrading on the former that did NOT
> > need upgrading on the latter, and that was just to compile the thing!
>
> So what? Your point is??? Obviously one system was partly upgraded.
>
> > According to you, both of these upgrades would have required EXACTLY
> > THE SAME upgrades to be made, but that isn't the case.
>
> I never claimed that.
>
> >> If you upgrade from 2.0.xx, you should read the 2.2.xx changes file.
> >
> > Fairy Nuff.
> >
> > However, your argument still fails, simply because of its reliance on
> > the assumption that an entire kernel series has static requirements
> > when such just isn't the case.
>
> There is no such assumption.
>
> If 2.2.4 needs foo-1.7 while 2.2.5 and 2.4.4 need foo-1.8, then
> foo gets listed. If 2.1.99 needs bar-0.6 while 2.2.0 and 2.4.4
> need bar 0.7, then there is no need to list bar. Never mind that
> both foo and bar are up to version 666, since that isn't needed.
>
> >> The important thing is to avoid version number inflation. I don't
> >> even bother reading the changes file, because I know it is bogus.
> >> Nearly all of my old software works great with a 2.4.xx kernel.
> >
> > The fact that you said "Nearly all" shows that your argument is false,
> > since your argument has been that NO software needs upgrading.
> >
> > Can I suggest that you re-read my previous missive, and actually look
> > at the points raised. If you do, we might just get a sensible
> > discussion on this subject...
>
> Try it yourself, w/o alcohol. I didn't argue "NO software...".
>
> > Incidentally, your argument to date has assumed that everybody always
> > installs every single kernel version. In my opinion, that is a very
> > dangerous assumption to make.
>
> Nope. Most people go from one stable series to the next, often skipping
> the first and last few revisions. (2.2.6, 2.2.9, 2.2.17, 2.4.3, 2.4.8...)
>
> > A more responsible assumption would be
> > that the person wishing to upgrade to the version in this particular
> > kernel source tree has a random system installed, and wishes to know:
>
> That random system should be capable of working with at least
> one kernel from the previous stable series.
>
> > 1. What is the absolute minimum upgrades required to compile the
> > kernel in the source tree I have just downloaded?
> >
> > 2. What is the absolute minimum upgrades required to install the
> > kernel in the source tree I have just downloaded and compiled?
> >
> > 3. What is the absolute minimum upgrades required to enable me
> > to run the kernel I have just compiled from this source tree,
> > assuming that I wish to retain the use of the shell scripts
> > that I developed under my previous kernel?
> >
> > 4. What other upgrades are recommended for reasons of system
> > security or stability?
>
> Good, assuming "reasons of system security or stability" relates
> to problems that a kernel upgrade might cause.
>
> > 5. What further upgrades are required to enable me to make use
> > of the advertised new facilities in this kernel?
>
> This is noise. Such upgrades are not required.
>
> > 6. What additional subsystems could be upgraded if desired?
>
> This is worse noise: "...and The GIMP is now at version..."
>
> > 7. I note that some upgrades are only required if certain of the
> > subsystems are installed. Which upgrades are these, and which
> > subsystems are they dependant on?
>
> This is getting too fancy.
>