[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> 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
> > 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.
> > 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.
> > > 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
Jean Francois Martinez
Project Independence: Linux for the Masses