In <20000108132859.C11842@xmission.com> Erik Andersen (andersen@xmission.com) wrote:
>> > It seems to me that having this patch in the kernel, thereby de-coupling
>> > the kernel from the initrd would be much better.
>>
>> So you think its more important to ship 3.5Mb less code to a small number
>> of embedded systems people than to slap another chunk of code into the kernel
>> that needs maintaining, updating and downloading by zillions of mainstream
>> users.
>>
>> I don't.
> We seem to be at an impass then. You have a good point. But if you carry
> that point to its conclusion you are effectivly saying that things in
> the kernel that are not commonly used by everyone should be deleted.
When there are exist userspace solution - yes.
> How many peple have 64 Gigs of ram installed? Delete that code.
Where is your userspacesolution to handle 64 Gigs or RAM ?
> There goes 90% of drivers/net/, 99% of drivers/cdrom/.
The same.
> Most folks use x86, and the kernel would be easier to maintain and would
> download faster if we delete the source for all those other obnoxious
> architectures...
When you'll show way to use x86 kernel on Sparc, Alpha and so all that can
be safely removed...
> I'm being ridiculous of course,
You are.
> but my point is that the kernel already supports lots of things that are not
> intrusive upon the lives and thoughts of folks that don't use them, but are
> extremely useful for the few folks that do.
And all such things donothave userspace solutions. When clean enough userspace
solution is there (like rarpd) feature is usually removed from kernel.
> Furthermore, it is going to be a while before Linux takes over the desktop.
Linus do not care :-)
> It is taking over embedded systems _now_, just like it is taking over the big
> iron machines. Adding 64Gig ram support to x86 is code that is not used by
> many folks but is "another chunk of code ... that needs maintaining, updating
> and downloading".
Sadly... Of course if can show way to pull out that code in userspace it'll be
done for sure.
> I really don't think obscure features for big iron systems are any different
> then obscure features for embedded systems.
They ARE. You can do what you want from userspace. You can not support obscure
CD-ROM's, 64GiB RAM, etc. in sane way without kernel modifications. If (and
ONLY if!) some obscure feature for embedded system can not be done outside of
kernel in sane way it'll be included. But you should at least consider ALL
known userspace solutions and show how they ALL are failing to fill the
bill...
-
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.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:13 EST