Re: [9fans] OT: linux complexity trends

Re: [9fans] OT: linux complexity trends

[presotto]

[-- Attachment #1: Type: text/plain, Size: 78 bytes --]

That's been recently discussed.  dhog is working on it for the next release.

[-- Attachment #2: Type: message/rfc822, Size: 1931 bytes --]

From: Ronald G Minnich <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] OT: linux complexity trends
Date: Mon, 26 Nov 2001 10:40:44 -0700
Message-ID: <01112610404404.17193@snaresland>

On Monday 26 November 2001 07:54, you wrote:
> But look: the Plan 9 kernel is a big beast, no doubt about it.   All those
> drivers, for one thing.

any opinions in this group about dynamically loading drivers.

Yeah, I know, ack, puke, but in some cases this can be very handy, esp. on
things like flash drivers which you don't normally want loaded.

ron

Re: [9fans] OT: linux complexity trends

[Dan Cross]

In article <20011126175643.1EC1F199D7@mail.cse.psu.edu> you write:
>That's been recently discussed.  dhog is working on it for the next release.

I guess I'm having a hard time understanding the point.  Memory being
as cheap as it is [*], why not just keep the drivers loaded all the time?
Is this to avoid inter-driver conflicts or to better support PCMCIA
devices or something?

I guess the argument for the installation floppy still holds, but it
strikes me that it'd be comparable to just link a new kernel for a given
configuration, as opposed to gathering together the correct collection
of loadable modules for putting on the floppy....

Maybe I'm wrong, but I don't get it.

	- Dan C.

[*] As an example of how cheap RAM is these days, I was at a computer
show in Queens a couple of weeks ago, and realized for the first time
in my life that I could, with the amount of money I could get out of an
ATM machine in one transaction plus the change in my pockets, walk up
to someone and say, ``Hi!  Let me have 4 gigabytes of RAM, please!''
Then I realized the guy who was selling it had no teeth, and thought
better of it.  Computer shows at a race track??  Run away....

Re: [9fans] OT: linux complexity trends

[Thomas Bushnell, BSG]

cross@math.psu.edu (Dan Cross) writes:

> I guess I'm having a hard time understanding the point.  Memory being
> as cheap as it is [*], why not just keep the drivers loaded all the time?
> Is this to avoid inter-driver conflicts or to better support PCMCIA
> devices or something?

The usual reason for dynamically loadable device drivers is for:

Systems with easily pluggable hardware (USB, PCMCIA)
Systems where it's beneficial to run one kernel for a bunch of
  machines with divergent hardware.

Such systems need all the drivers available, in principle, all the
time, but only a minority will be needed at any one point in time.  If
all the supported hardware drivers are loaded at once, you do get
considerable bloat.  There are a *lot* of hardware devices out there;
a kernel with device drivers compiled in for all of them would be
insanely huge.

Re: [9fans] OT: linux complexity trends

[forsyth]

>>Ipaq's, for example, have very limited memory but can have a

one of the nice things about wandering in after microsoft
on any given platform is that `limited memory' means something
quite different from what it might mean elsewhere.
for instance, the newer iPAQs seem to be 64mbyte RAM and
32 mbyte flash (minimum).

Re: [9fans] OT: linux complexity trends

[presotto]

I had been against locadable drivers for a while, mostly on the grounds of added
complexity.  However, I never compiled all devices into my kernels
because probing for some devices often hung my system or interfered
with other devices although that's getting better.

Size still matters since we run on a lot of little devices.  The
Ipaq's, for example, have very limited memory but can have a
panoply of cards that can be plugged in on the fly.  Compileing in
all devices is a bit of a pain since they can easily surpass the
flash.

For release purposes, its less resources to waste on our side just
copying drivers onto a floppy than building a new kernel.  However,
that's not a very strong argument.

Re: [9fans] OT: linux complexity trends

[rob pike]

Actually, I think my remark was that the Plan 9 window system's
source was smaller than the X include files, but I don't think that's
changed significantly and the remark about kernel source is probably
not too far off the mark either.

But look: the Plan 9 kernel is a big beast, no doubt about it.   All those
drivers, for one thing.

-rob

Re: [9fans] OT: linux complexity trends

[Ronald G Minnich]

On Monday 26 November 2001 07:54, you wrote:
> But look: the Plan 9 kernel is a big beast, no doubt about it.   All those
> drivers, for one thing.

any opinions in this group about dynamically loading drivers.

Yeah, I know, ack, puke, but in some cases this can be very handy, esp. on
things like flash drivers which you don't normally want loaded.

ron

Re: [9fans] OT: linux complexity trends

[Alexander Viro]

On Mon, 26 Nov 2001, Ronald G Minnich wrote:

> On Monday 26 November 2001 07:54, you wrote:
> > But look: the Plan 9 kernel is a big beast, no doubt about it.   All those
> > drivers, for one thing.
>
> any opinions in this group about dynamically loading drivers.

Can get extremely messy wrt unload-related races.  If you limit yourself
to uniform kernel<->module API - maybe. struct Dev would be natural candidate,
but #<letter> convention might get uncomfortable very soon and AFAICS you will
need to work on locking and proper refcounting - from the fast look through
code it's not a lot to change, but I didn't dig deep enough to say for sure.
The question being, is it really worth the trouble?

PS: apologies for delay with port of patch to current tree - it had been
quite a week, what with 2.5 fork and beginning of merges...

Re: [9fans] OT: linux complexity trends

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

i meant: the way #ifdefs have been used increases (i think) the complexity of the code.
i would qualify the remark by changing ``the complexity also isn't
a function of size'' to ``the complexity isn't necessarily a function of size'',
because that's what i actually meant.


[-- Attachment #2: Type: message/rfc822, Size: 1679 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] OT: linux complexity trends
Date: Mon, 26 Nov 2001 09:00:46 -0500
Message-ID: <20011126140052.7A7B619A2B@mail.cse.psu.edu>

> of course be relevant.  the complexity also isn't a function of size,
> but of construction (as a small example i think of all those #ifdefs
> in the Linux kernel code i've seen, particularly the powerpc and arm
> support).

What are you saying?  That the #ifdef's increase the complexity of the
code or decrease it?

Re: [9fans] OT: linux complexity trends

[presotto]

> of course be relevant.  the complexity also isn't a function of size,
> but of construction (as a small example i think of all those #ifdefs
> in the Linux kernel code i've seen, particularly the powerpc and arm
> support).

What are you saying?  That the #ifdef's increase the complexity of the
code or decrease it?

Re: [9fans] OT: linux complexity trends

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

to be fair, i think it depends what that graph is measuring.  if it is
mainly more device drivers and protocols, that increases the scale of
linux, but not necessarily the complexity.  whether some of those
protocols and driver functions really need to be in the kernel might
of course be relevant.  the complexity also isn't a function of size,
but of construction (as a small example i think of all those #ifdefs
in the Linux kernel code i've seen, particularly the powerpc and arm
support).

on the other hand, i think rob observed once years ago at a conference that at
the time the entire source code of the Plan 9 kernel was smaller than
just the include files of some Unix systems, and i don't think that has
changed significantly.


[-- Attachment #2: Type: message/rfc822, Size: 2221 bytes --]

To: 9fans@cse.psu.edu
Subject: [9fans] OT: linux complexity trends
Date: Mon, 26 Nov 2001 12:41:53 +0000
Message-ID: <1171249689@snellwilcox.com>


Linux kernel size trend graph

http://durak.org/sean/pubs/kfc/kfc-size.gif

I wonder what the Plan9 one might look like?

-Steve





----------------------------------------------------------------------
The contents of this communication are confidential to the normal user of
the email address to which it was sent.  If you have received this email
in error, any use, dissemination, forwarding, printing or copying of this
email is strictly prohibited.  If this is the case, please notify the
sender and delete this message.
----------------------------------------------------------------------

Re: [9fans] OT: linux complexity trends

[Dan Cross]

In article <20011126130655.879E819A2E@mail.cse.psu.edu> you write:
>on the other hand, i think rob observed once years ago at a conference that at
>the time the entire source code of the Plan 9 kernel was smaller than
>just the include files of some Unix systems, and i don't think that has
>changed significantly.

A little while back, I did an experiment.  I stripped out all comments
and blank lines, and counted the number of lines in the linux kernel which
contain all or part of a C statement or expression, minus device drivers.
The total was something like 1.6M.  Then, I performed the same experiment
on the entire Plan 9 distribution (which includes things like ghostscript),
plus TeX, mosml, and cvs.  If I recall correctly, the result of that was
something like 1.5M lines.  Maybe source lines is not a good indicator of
complexity, but I found something there really amusing.

	- Dan C.

Re: [9fans] OT: linux complexity trends

[Ronald G Minnich]

On Monday 26 November 2001 11:36, you wrote:
> Maybe source lines is not a good indicator of
> complexity, but I found something there really amusing.
>

I'm not given to defending linux, but you have to keep in mind:
- lots more architectures for linux
- lots more file systems (I know, this is an iffy comparison)
- lots more devices
- lots more exec format types, etc. This is either a misfeature or not, I'm
   not sure.


What would be interesting is to compare, for a single architecture, the lines
of code for a comparable set of sources. Take all the file systems, drivers
etc. they both support and see how that compares. I am sure Plan 9 would
still win, but maybe by not as much.

ron

[9fans] OT: linux complexity trends

[steve.simon]

Linux kernel size trend graph

http://durak.org/sean/pubs/kfc/kfc-size.gif

I wonder what the Plan9 one might look like?

-Steve





----------------------------------------------------------------------
The contents of this communication are confidential to the normal user of
the email address to which it was sent.  If you have received this email
in error, any use, dissemination, forwarding, printing or copying of this
email is strictly prohibited.  If this is the case, please notify the
sender and delete this message.
----------------------------------------------------------------------