Re: Synopsis

[dumas patrice <dumas@rip.ens-cachan.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.

> 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.

???

> 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.

Pat