lkml.org 
[lkml]   [1999]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: proper place to discuss kernel 'bloatedness'?
Date
From
(I'm agreeing with Victor.  *shock horror* :-)

In message <ABrPQlsCa7@khim.sch57.msk.ru>, "Khimenko Victor" writes:
+-----
| "Easily" ? Are you joking ? With moves like planned move of rename() from
| filesystem-level to VFS-level are forced to redesign all modules (AFS peoples
| are heppy to hear about this move, I know :-))) ! So if module will be
+--->8

As I've said previously, *real* bugs should be fixed... and the rename()
issue comes up often enough that I'm willing to count it as a real bug.
Not only have problems with Linux's rename() tripped both the Arla folks
and the Linux-AFS porters (Derek at MIT, a small team here at CMU), but
rename problems have been ongoing throughout the 2.1 and to some extent 2.0.
All in all it's better to get the problem *fixed* instead of remaining a
sore that gets its scab ripped off every few minor revs.

It's the gratuitous "let's rearrange structures for no good reason" changes
(or "because it's neato but nobody really needs it, notwithstanding that it
changes half the interfaces in the kernel so perhaps shouldn't be added to
the stable kernel series") that make our lives difficult.

(And if it needs to happen --- IMHO it does --- now is the time, before 2.2
gets "established".)

| Some peoples just hate modules and it's just easily to mantain consistency
| with current big tarball then with proposed scheme...
+--->8

More arguments:

* small pseudo-"embedded" systems --- I've some dedicated firewalling routers
in service, 486SX 8MB RAM; what's the point in having a bunch of modules
that will never be loaded, and the modules that *will* be loaded are needed
for the entire lifetime of the machine.

* installing a self-built kernel with modules can be a massive pain in the *ss
(you have to do various things to a Red Hat setup before it will recognize
your modules as legitimate, for example)

Basically, modules are nice for volatile hardware configurations or "one size
fits all" kernel packages; for set-and-forget production setups where you have
to build a custom kernel anyway, they're an unnecessary hassle.

# # #

As for splitting the kernel source, the real problem is that one person's
"unnecessary waste of disk space" is guaranteed to be someone else's "mission
critical"; there will never be agreement on what to split out of the sources.
Not to mention that you don't want to have to go back to ftp.*.kernel.org to
get the SCSI package during everyone's pr0n-point-wait-n-drool time :-) (or
hitting-cnn.com-every-5-seconds-for-news-updates, etc.) to get the new SCSI
adapter running on your server....

# # #

What *might* be worth doing: allow the kernel make procedure to adapt to
missing directories. If someone wants to unpack the sources omitting e.g.
drivers/sound, net/appletalk, etc., those should be automatically configured
out of the kernel and the build process shouldn't try to descend into those
directories.

--
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
We are Linux. Resistance is an indication that you missed the point.

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

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.056 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site