>> In <3629E2F2.B1A546D4@nb.net> Rob Dale (rob@nb.net) wrote:
>> RD> Khimenko Victor wrote:
>> >>
>> >> GM> First off, before you get all hot and bothered: SMP=1 SHOULD BE OFF BY
>> >> GM> DEFAULT!. No one SHOULD be running a SMP kernel on a non SMP box! Yes, it
RR> [...]
>>
>> RD> This is a distribution issue, not a kernel issue.
>>
>> No. It's kernel issue. Installation CD has image of ONE, EXACTLY ONE floppy
>> (1.44" -- even 2.88" not supported by all BIOS'es). Since this floppy MUST
>> include kernel and all drivers needed to obtain access to CD this effectively
>> means that this floppy could include EXACTLY ONE kernel -- SMP one since we
>> must detect SMP :-)
RR> You seem to be missing something here, the kernel image the install
RR> CD/floppy boots in not necessarily the image that will go into the new
RR> Linux installation.
Like a Windows9x where installer use "standard mode" while OS itself could
use only "Enhanced386 mode" ? This is doable but IMO this is braindead solution.
Plus sitiation where installation hangs on bootup is by FAR better then
situation when installation went just fine but after that system does not boot
at all :-((
RR> The distribution installer program can choose later on the most
RR> appropriate image from the CD and copy it to the hard drive.
Remeber old 1.2.13 distributions ? Where was few TENS of kernel images
(sometimes more then 100!) and STILL not all common features could be installed
without kernel recompilation ? It's was REALLY pain in the ass to install such
systems. You want to return to that times ???
RR> Also, we don't need an SMP kernel to detect SMP, just a setuid root
RR> program that can probe a few IO ports around the system. This is not
RR> optimal but making SMP 100% realiable under UP is hard and not a priority
RR> of the SMP developers, and understandably so: it is agreed that "you
RR> shalt not run SMP on UP" since performance will suck.
RR> Lastly, Linus has said (and it has been repeated a zillion times) that the
RR> current SMP=1 line in the 2.1.x Makefile is just a convenience for him and
RR> will go away on 2.2. So yes, SMP=1 *is* off by default.
One exception with SMP could be Ok since this is really hard to make sure that
all features works reliable with SMP. What about other features like MTRR ?
Back to crap "a-la 1.2.13" ?
>> >> Dists should select right kernel automatically in most cases. Windows NT do
>> >> this for last few years -- why Linux could not do this ? "Joe Average" viewpoint
>> >> of course :-))
>> >>
>>
>> RD> Look at what you said: Dists should select...
>> RD> That's exactly right! The distributions should do it.
>> RD> Not the kernel. This has nothing to do with the kernel.
>>
>> You are wrong. It's kernel issue.
>> 1. BEFORE distribution will select ANYTHING installation program MUST be
>> able to start. Since installation program is program for Linux.
RR> Simple, Boot an UP kernel, that should work on all setups, both UP and
RR> SMP.
What about multicasting, forwarding, MTRR, IPv6 (when IPv6 will not be
"experimental" anymore), framebuffer, etc ?
>> 2. [Almost] All features MUST be turned on by default. For one or two (SMP?)
>> distribution could produce special versions. Distribution COULD not include
RR> Not true, all features *essential* to installing the distro. must be
RR> enabled. This means just access to the CDROM and hard disk (and maybe the
RR> network).
Network, ftp, NFS, smbfs, ncpfs, etc.
RR> But not multicasting, APM, frame-buffer, sound, and all other
RR> extras. Think of it as booting into the dreaded Win95 safe mode. Once
RR> the hardware has been identified the a proper non-conflicting image can be
RR> selected.
This was EXACTLY biggest problem with 1.2.13: more then 100 boot-images and
system STILL only half-ready to use without kernel recompilation. That's why
modules was introduced. "Select a proper non-conflicting image" approch does
not work well -- it was proved YEARS ago. When few minor features could not
ne activated via GUI tools without kernel-recompilation it's Ok. But when
some widely used features could be activated only via kernel recompilation it's
not acceptable...
RR> It is a distribution issue.
No, no and no. It's KERNEL issue. Since our 100+ options could potentially
produce more then 1'000'000'000'000'000'000'000'000'000'000 different images
you could not put all this images on CD -- you simple could not find enough
CD's in the whole world :-) Remember RedHat 3.0.3 or Slackware 2.2 ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/