> 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 advocateEscape 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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html