From: hvis...@iafrica.com (Hendrik Visage)
Subject: Layout/Setup of Kernel
Date: 1998/07/31
Message-ID: <35C1F408.9112F4AA@iafrica.com>#1/1
X-Deja-AN: 376726600
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
Organization: SDN
Newsgroups: muc.lists.linux-kernel
Hi There,
First I have to congratulate the people who have brought Linux to the
current state of what it is.
Second, I have to complain about the size of the current 2.1.x
kernel.... (especially for modem download)
Reasons:
1) More than 10Megs of compressed source code.
2) Most of the downloaded stuff aren't needed for the average
installation (ie. no SCSI or IDE and also only using less than halve the
SCSI or IDE options, and only using one or two network adapters, not
every one have a UFS/SYSV filesystem etc. )
Isn't it time to start a break down of the kernel?
What I'd like to see is a situation where there actual "kernel" is
something which contains the stuff necesary to support the device
drivers. The device drivers are then maintained by there respective
maintainers and could then be released on a seperate schedule as and
when changes are needed for then.
I'd advise people to take a look at http://docs.sun.com under the
section 9 manual pages to see the Solaris type DDI/DDK.
If we start using something like this, a device driver developed for
eg. Solaris SPARC/x86 could then be much easier to port (or even run as
binary on the relevant architecture) to Linux and vice versa. Something
by which some OEMs might be quicker to respond to Linux versions...
In this environment, the "kernel" would then be just enough with enough
knowledge to load drivers into memory and to provide then with the
needed support etc. This would most probably include the scheduler, etc.
Thus, we shouldn't have a option to compile something as a module or
not, it should be the ONLY option available.
I do feel that the options regarding the "kernel" should be limited to
stuff like:
a) Sparc/x86/68k/ARM/SGI etc.
aa) Optimization for specific versions
b) SMP/Uniproc
c) Debugging
d) Profiling
For booting you'll then have to create a boot file for each type of FS,
like (boote2fs, bootminix, bootnfs etc.) which would create a temporary
FS for loading the kernel which the kernel would ask for the necessary
config files and driver files (like the REAL fs driver) to be loaded.
Having this "single" boot program could also help with other problems
I've encountered like running lilo (etc.) every time I've created a new
kernel, whereas this program would need an initial lilo, (stating where
it lives on the disk) and subsequent new/previous kernels would be
loaded from this program (given the right boot options like asking for
the kernel file and directories etc.)
I do feel that Linux could learn from Solaris (Yes I do like Solaris,
but prefer Linux at home because of resources) to be much more modular
and by providing a framework for others to drivers on, rather also
providing lot's and lot's of drivers with the single xxxxMeg file.
Greezt
Hendrik Visage
hvis...@iafrica.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: mhar...@ican.net (Mike A. Harris)
Subject: Re: Layout/Setup of Kernel
Date: 1998/08/01
Message-ID: <Pine.LNX.3.96.980801020429.5789E-100000@red.prv>
X-Deja-AN: 376909792
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <35C1F408.9112F4AA@iafrica.com>
Organization: Capslock Computer Consulting
Newsgroups: muc.lists.linux-kernel
On Fri, 31 Jul 1998, Hendrik Visage wrote:
> Second, I have to complain about the size of the current 2.1.x
> kernel.... (especially for modem download)
> Reasons:
> 1) More than 10Megs of compressed source code.
> 2) Most of the downloaded stuff aren't needed for the average
> installation (ie. no SCSI or IDE and also only using less than halve the
> SCSI or IDE options, and only using one or two network adapters, not
> every one have a UFS/SYSV filesystem etc. )
At 33.6k, that is 14Mb/h - about 40 minutes
At 28.8k, that is 12Mb/h - about 50 minutes
At 21.6k, that is 10Mb/h - about 60 minutes
My 33.6 connects at about 21.6, so it takes me an hour to
download 10Mb. I'm happy with that just fine. Modems suck, they
always will suck, and there is nothing we can do about it. Even
56k modems suck, don't connect at 56k or anywhere close, and even
if they did, it still sucks, and is incredibly slow. Especially
since 10Mbit ethernet has been around for about 400 years or
so...
> Isn't it time to start a break down of the kernel?
This is brought up on this mailing list about once every 3 weeks,
and the answer is a straight NO. What is the reason? It is a
developers nightmare. Maintaining a single tree is hard enough,
maintaining a bunch of separate archives is a PITA. What it all
TRULY boils down to is what Linus thinks. Linus is GOD. Linus
says "No, I will do it this way, and that is it mortal. If you
want a divided kernel, feel free to divide it yourself and
distribute.". Linus is GOD. GOD says no. No amount of arguing,
complaining or anything will change that, not now, not ever.
In fact, the only chance you've got of getting this to happen, is
if you "do it yourself" and "prove to everyone that there is some
mega benefit to both the end user and the developer". If it is
true, then the developers will likely adapt the idea and follow
suit. This is practically how EVERYTHING is done in the linux
development world. Basically, if you want some new big feature,
you do it yourself, and offer it to the Gods.
If you don't want to download 10M, then don't. Download ONE
kernel at 10M, and then download PATCHES for every release that
comes out after that. These patches are usually between around
30k and 500k, and are VERY easy to apply to an existing source
tree by following the instructions in README. A 500k download is
5 minutes at 14.4k - peanuts. At higher speeds it is done before
your coffee is heated by the nuker.
Linus has said repeatedly that his own PREFERRED method of kernel
distribution is patches only. We should be thankful he
distributes the whole tarball.
In the past, I've gotten the whole McCoy everytime, however in
the last 6 months, I too have tired slightly of waiting an hour
for the new kernel (anxiously), so I switched to patches.
Patches are fast, and solve the problem entirely.
> What I'd like to see is a situation where there actual "kernel" is
> something which contains the stuff necesary to support the device
> drivers. The device drivers are then maintained by there respective
> maintainers and could then be released on a seperate schedule as and
> when changes are needed for then.
Personally, I see this as a nightmare solution. I can just see
people reporting bugs in the 3c509 driver with kernel 2.2.34556,
and 3 weeks later after intense hacking, peeking, poking, the
development team discovers that the person must be using the
DRIVER from kernel 2.2.34550, because he forgot or didn't feel
like upgrading the driver tarball at the same time as the kernel.
This is old hat discussion, Linus is god, linus says "No".
> I'd advise people to take a look at http://docs.sun.com under the
> section 9 manual pages to see the Solaris type DDI/DDK.
This also has been a past discussion on the mailing list.
Several times I believe. Don't people read FAQ's anymore?
Geesh.
> If we start using something like this, a device driver developed for
> eg. Solaris SPARC/x86 could then be much easier to port (or even run as
> binary on the relevant architecture) to Linux and vice versa. Something
> by which some OEMs might be quicker to respond to Linux versions...
I don't remember how the discussions ended on this before, but I
don't see any code yet, so I'll bet that someone said "no".
Personally, I am happy with the way things are now, and I think
that sooner or later Solaris will be creating "Linux driver
support" instead of the other way around...
;o)
> In this environment, the "kernel" would then be just enough with enough
> knowledge to load drivers into memory and to provide then with the
> needed support etc. This would most probably include the scheduler, etc.
>
> Thus, we shouldn't have a option to compile something as a module or
> not, it should be the ONLY option available.
>
> I do feel that the options regarding the "kernel" should be limited to
> stuff like:
> a) Sparc/x86/68k/ARM/SGI etc.
> aa) Optimization for specific versions
> b) SMP/Uniproc
> c) Debugging
> d) Profiling
Well, I'm more than happy to test out the code that you've
written to do this. I'm sure many people are. At what URL can
we download your patches?
> Having this "single" boot program could also help with other problems
> I've encountered like running lilo (etc.) every time I've created a new
> kernel, whereas this program would need an initial lilo, (stating where
> it lives on the disk) and subsequent new/previous kernels would be
> loaded from this program (given the right boot options like asking for
> the kernel file and directories etc.)
>
> I do feel that Linux could learn from Solaris (Yes I do like Solaris,
> but prefer Linux at home because of resources) to be much more modular
> and by providing a framework for others to drivers on, rather also
> providing lot's and lot's of drivers with the single xxxxMeg file.
Well then lets see your code. Post the URL that provides this
support, and if it is the greatest thing since sliced bread, then
people will have to start saying "I'ts the greatest thing since
those solaris patches" instead of the former cliche.
Doesn't the subscription mechanism auto-fire the FAQ to new
subscribers anymore?
--
Mike A. Harris - Computer Consultant - Linux advocate
Escape from the confines of Microsoft's operating systems and push your
PC to it's limits with LINUX - a real OS. http://www.redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: Layout/Setup of Kernel
Date: 1998/08/01
Message-ID: <Pine.LNX.3.96.980731232522.30695B-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 376909794
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980801020429.5789E-100000@red.prv>
Newsgroups: muc.lists.linux-kernel
On Sat, 1 Aug 1998, Mike A. Harris wrote:
>
> What it all
> TRULY boils down to is what Linus thinks. Linus is GOD. Linus
> says "No, I will do it this way, and that is it mortal. If you
> want a divided kernel, feel free to divide it yourself and
> distribute.". Linus is GOD. GOD says no. No amount of arguing,
> complaining or anything will change that, not now, not ever.
[ Good dog. Sit. Jump. Roll over..
See, I have them trained to perfection. My army of mindless drones are
only months away from taking over the world. When the day comes, all
opposition will be CRUSHED ]
But yes, if somebody wants to split up the standard kernels, and if he can
do it in a way that people trust somehow, please do feel free. _I_ am way
too lazy to bother with it, but as the question does come up fairly often
there are obviously people who would like to see it done.
My only concern is that it has to be done well enough that it doesn't
cause more problems than it solves, and it has to be done in a way that
people trust the split up archives for some reason. But it could all
probably be done automatically by a reasonably simple script.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
From: mhar...@ican.net (Mike A. Harris)
Subject: Re: Layout/Setup of Kernel
Date: 1998/08/01
Message-ID: <Pine.LNX.3.96.980801043719.5789Q-100000@red.prv>#1/1
X-Deja-AN: 376927475
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.96.980731232522.30695B-100000@penguin.transmeta.com>
Organization: Capslock Computer Consulting
Newsgroups: muc.lists.linux-kernel
On Fri, 31 Jul 1998, Linus Torvalds wrote:
> > TRULY boils down to is what Linus thinks. Linus is GOD. Linus
> > says "No, I will do it this way, and that is it mortal. If you
> > want a divided kernel, feel free to divide it yourself and
> > distribute.". Linus is GOD. GOD says no. No amount of arguing,
> > complaining or anything will change that, not now, not ever.
>
> [ Good dog. Sit. Jump. Roll over..
How many times??? ;o)
> See, I have them trained to perfection. My army of mindless drones are
> only months away from taking over the world. When the day comes, all
> opposition will be CRUSHED ]
Heheheh. Well, we're not mindless, but we shall certainly take
over the world! Take no prisoners! No other OS shall survive!
;o)
> But yes, if somebody wants to split up the standard kernels, and if he can
> do it in a way that people trust somehow, please do feel free. _I_ am way
> too lazy to bother with it, but as the question does come up fairly often
> there are obviously people who would like to see it done.
Yes, but they all seem like they want YOU to do it, and I think
that is why it gets so heated. ;o) Personally, I can't see how
difficult it is to write a simple bash script which tar's up a
kernel tarball, a driver tarball, and several arch tarballs. And
so if it is that easy, I think that people should do it for
themselves and leave you to do the real work.
You know... the Transmeta "product" that is being worked on...
The subliminal world domination machine? I know its safe to
talk about because no-one would believe it anyway. The only
reason I know about it is from finding the subliminal hooks in
the kernel myself. ;o)
> My only concern is that it has to be done well enough that it doesn't
> cause more problems than it solves, and it has to be done in a way that
> people trust the split up archives for some reason. But it could all
> probably be done automatically by a reasonably simple script.
>
> Linus
Exactly. I doubt that it would get used by many nonetheless
unless you or one of the other core developers were behind it. I
don't see why people find it so hard downloading and installing
patches... but that is another story...
My personal request is that the tarballs unpack to "linux-2.x.x/"
but I know how you feel about that allready. ;o) My solution is
to unpack, and repack with a script once I've downloaded. Simple
solution. ;o)
Well, take care, and don't forget to pick on some mortals today.
;o)
TTYL
--
Mike A. Harris - Computer Consultant - Linux advocate
Escape from the confines of Microsoft's operating systems and push your
PC to it's limits with LINUX - a real OS. http://www.redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
|