Re: Synopsis

[JF Martinez <jfm2@club-internet.fr>]

> 
> On Mon, 12 Jun 2000, JF Martinez wrote:
> 
> > > 
> > > JF Martinez wrote:
> > 
> > That is a defragmented fat filesystem.  But the whole process is
> > painful.  Defragment under Windows then go to DOS and use FIPS then
> > reboot we need something better.
> 
> Well, parted can resize even with non defragmented drive, it relocates all
> the stuff at the end of the dos partition. So that is definitively a
> good tool.
> 
> > Windows is picky (read ist is an MS tactic to make things harder for
> > other systems) about where its partitions can go.  It won't boot if it
> > is not in the first partition of the first disk to begin with.
> 
> The problem is not here, I have a first windows partition, on the first
> disk, and also another (a fat 16)  at the end of the disk, but windows see
> one more drive, totally abnormally. 
>  
> > > Parted can be used in two ways, there is a C library that does all the
> > > stuff, and a "front-end" command line oriented, interactive or not.
> > > So it is possible to use the library (its API is documented) or the
> > > whole stuff in scripts. 
> > 
> > Nice.
> > 
> > > [I told here about a windows app that automates setup programs with
> > > windos]
> > > > 
> > > > Yes, very interesting.
> > > >
> > > So, what to do with ?
> > >  
> > Try to integrate it of course.
> 
> If parted or something like that is used, IMO, the only thing to do in
> windows is to ask the user where he wants linux stuff (like dosutils,
> kernels for loadlin..) to be put. All the other things can be done from
> linux, the directory (and the windows partition ?) being given to the
> kernel as a parameter and used after that for installation.
> 

Hum Is it possible to start Linux from Windows or is it manually going
DOS mandatory.

> > In 2.0 there was not much difference between a kernel compiled for
> > Pentium and one compiled for 386 (most optimizing was done at runtime)
> > except for selective invalidation of TLB entries and that made little
> > difference.  In 2.2 what I have seen in the source points to far
> > greater optimizations and in addition there is the question of SMP boxes.
> 
> ???
> 

SMP kernels are supposed to be very suboptimal for UP boxes and of
course UP kernels allow using one processor.  However this is what
Caldera is doing: ship an SMP capable kernel whatever the box.

> > Anyway the method presently used is to use an install kernel compiled
> > for 386 and during the install look at /proc/cpuinfo and select the
> > kernel suitable for the processor.
> 
> Ok.
> > 
> > Also presently kernels are built with -m486 whatever the real
> > processor (and use alignment restrictions with higher processors),
> > this is probably old gcc 2.7 did not generate correct code with
> > -mpentium however my benchmarks show a clear improvement if you
> > compile for the specific processor.  However we nee  
> > 
> > It is.  I was referring to including readonly support for NTFS.
> 
> Ok.
> 
> > > Well, in the projects I talk about, there was such ideas, to recompilate
> > > for a peculiar hardware. It goes further as it recompilate everything.
> > > It is still a project, but if they go further, it could save us a lot of
> > > work. I keep watching.
> > > 
> > 
> > I thought about it years ago.  I also had the curiosity to quantify
> > the memory savings between a properly compiled distribution kernel and
> > an optimized one.  My conclusion was that it is not worth the trouble
> > on 32 megs boxes, and probaly not on 16 megs boxes.  8 megs boxes in
> > 
> 
> It is not about memory, I agree the kernel doesn't use much, and even less
> with modules, but it is for speed.
> In the project I am thinking about, one goal was to have a "database" of
> the compile flags optimized for a peculiar processor.
>

But the problem is that first of all processor flags have little or no
effect on gcc 2.7 and egcs 1.1.2 (I benchmarked them) the official C
compilers at this time.  It is a bit better on gcc-2.95 but 1) gcc
2.95 is still beta 2) Alan Cox told that performance gains will be
worth the trouble with gcc-2.96 and gcc-3.0 but not with gcc-2.95.  I
tend to agree with his conclusions.  3) Even when we get gcc-3.0 it
can happen that processors can be regrouped into relatively
homogeneous classes in such way that the class flags provide above 99%
of the performance of the processor-tuned flags.

Given the present state of compilers I am not interested in an install
time automatic compiling (I prefer providing a small set of kernels
and pick the right one automatically).  However I am interested into
inevstigation about the limit of what is tolerable when compiling the
kernel.

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org