Re: [9fans] Ugly Q, I admit

Re: [9fans] Ugly Q, I admit

[Russ Cox]

> Does this imply that it would not be difficult to implement dynamic linking natively in Plan 9?

the difficult part of dynamic linking is more in the compiler
and linker than in the kernel proper.  since i'm just running
already-created linux binaries, there's hardly any trouble.

the linuxemu i posted has an "mmap" function that allocates
memory and reads the whole file into it.  not quite the most
efficient way to do it.  i wrote a real mmap for the kernel at the
time, but it didn't seem worth keeping.  the user-side interface
for the kernel mmap is commented out.

Re: [9fans] Ugly Q, I admit

[Bruce Ellis]

it turns out not to be very difficult at all.  i don't think much of it saw light.
you'll find that 5l supports it but the runtime code is not in the distribution.
i did 8l and el too but once again it never got out.  i'd be willing to do some
work on this if come out of retirement (the pasadena doo-dah festival
was more fun than bit-bashing).

----- Original Message -----
From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: <9fans@cse.psu.edu>
Sent: Tuesday, November 26, 2002 4:00 PM
Subject: Re: [9fans] Ugly Q, I admit


> > Does this imply that it would not be difficult to implement dynamic linking natively in Plan 9?
>
> the difficult part of dynamic linking is more in the compiler
> and linker than in the kernel proper.  since i'm just running
> already-created linux binaries, there's hardly any trouble.
>
> the linuxemu i posted has an "mmap" function that allocates
> memory and reads the whole file into it.  not quite the most
> efficient way to do it.  i wrote a real mmap for the kernel at the
> time, but it didn't seem worth keeping.  the user-side interface
> for the kernel mmap is commented out.
>
>

Re: [9fans] Ugly Q, I admit

[Lucio De Re]

On Wed, Nov 27, 2002 at 01:14:15AM -0500, Bruce Ellis wrote:
>
> it turns out not to be very difficult at all.  i don't think much
> of it saw light.  you'll find that 5l supports it but the runtime
> code is not in the distribution.  i did 8l and el too but once
> again it never got out.  i'd be willing to do some work on this if
> come out of retirement (the pasadena doo-dah festival was more fun
> than bit-bashing).
>
What's "el"?

I set up a NetBSD diskless workstation farm once and because /bin
and /sbin were statically linked, I felt I could save disk space
by removing their contents (mostly) and putting dynamically linked
versions in /usr/(bin sbin).

It turned out to be cheaper and simpler to use hard links instead,
only a few files in /etc needed to be kept distinct per workstation,
everything else in the root partition landed up with numerous hard
links.  The saving was considerable, although I think NetBSD seems
to have a problem with exactly 128 hard links on a single i-node
(go figure!).

The new release of NetBSD (I haven't had the nerve to lift the
bonnet lid yet) has dynamically linked everything, except the
runtime loader and, seemingly, init.

There was a long discussion about making init dynamic too, so it
could have "locale" stuff in it.  In my uneducated state, I decided
that the kernel should not support internationalisation at all,
seeing the type of confusion and cost it gives rise to.  Leave it
to applications to battle with the details.  But of course I'm just
being reactionary.

Just a few tidbits triggered by brucee's comments, I don't believe
my opinions in this matter should be given much weight, whereas
NetBSD's experiences might be worth learning from.

++L

Re: [9fans] dynamic loading, was "Ugly Q, I admit"

[Bruce Ellis]

dynamic loading and shared libraries are distinct (put related) beasts.
the work i did was for dynamically loadable device drivers for inferno.
it's kinda cool.  the initial kernel is tiny, even by inferno standards,
and then other drivers are loaded to customize the experience
(typically i load cap ssl kfs and sd).  i also use it to load drivers
that are used on occasion, like kprof or a generic systest.
the interface is via devdynload.

i've never had much time for shared libraries.  given that plan9 does
not have grossly obese libraries the "shared/saved disk/memory"
justification seems marginal.  you also avoid a major "single point
of disaster".  i believe presotto reported being frightened by
shared libraries (and clowns) as a child.

btw e[acl] is the compiler port for the playstation 2 ee5900.

brucee

Re: [9fans] dynamic loading, was "Ugly Q, I admit"

[Lucio De Re]

On Wed, Nov 27, 2002 at 01:41:07PM -0500, Bruce Ellis wrote:
>
> dynamic loading and shared libraries are distinct (put related) beasts.
> the work i did was for dynamically loadable device drivers for inferno.
> it's kinda cool.  the initial kernel is tiny, even by inferno standards,
> and then other drivers are loaded to customize the experience
> (typically i load cap ssl kfs and sd).  i also use it to load drivers
> that are used on occasion, like kprof or a generic systest.
> the interface is via devdynload.
>
I remember loadable device drivers being mooted a while back.  I like
the idea a lot, although it seems backwards to me: repeating the
bootstrap stuff in the kernel always struck me as evil, if
unavoidable.  Ideally you'd want to "load" at least some kernel
drivers by inheriting them from the bootstrap loader.  I'm not sure
that the difference can't be minimised almost to nothingness.

> i've never had much time for shared libraries.  given that plan9 does
> not have grossly obese libraries the "shared/saved disk/memory"
> justification seems marginal.  you also avoid a major "single point
> of disaster".  i believe presotto reported being frightened by
> shared libraries (and clowns) as a child.
>
Shared library are a curse, but until everyone sees them in that
light, they'll be with us for a long time to come.  It's a fashion
thing.

> btw e[acl] is the compiler port for the playstation 2 ee5900.
>
I never even remotely dared hope there'd be Plan 9 for the PS2.  Can I
start dreaming?  Shall I spend some money and offer to help?

++L

Re: [9fans] dynamic loading, was "Ugly Q, I admit"

[Bruce Ellis]

----- Original Message -----
From: "Lucio De Re" <lucio@proxima.alt.za>
...
> I remember loadable device drivers being mooted a while back.

It was on the list for 4th edition (rob was a fan) but too much was
going on in many ways for it to have a chance.  I might bring my
Inferno model into a private plan9 kernel and see if I like it.

> Shared library are a curse, but until everyone sees them in that
> light, they'll be with us for a long time to come.  It's a fashion
> thing.

A fashion?  I wish it would die.  But then again my wardrobe says
something about doing something for the helluva it.

> I never even remotely dared hope there'd be Plan 9 for the PS2.  Can I
> start dreaming?  Shall I spend some money and offer to help?

No need to dream.  The jump from the Inferno port to a plan9 port
is largely known territory.  It's just a whacky mips and so if you are
willing to get the mmu/tlb stuff right then you are almost there.  The
most interesting part is deciding what to do about graphics.  /dev/draw
would be an easy way out (the linux guys just went for a slow X) but
the chip is more fun than that.

brucee

Re: [9fans] dynamic loading, was "Ugly Q, I admit"

[Lucio De Re]

On Thu, Nov 28, 2002 at 12:58:09AM -0500, Bruce Ellis wrote:
>
> A fashion?  I wish it would die.  But then again my wardrobe says
> something about doing something for the helluva it.
>
Some fashions never do, look at automobiles.  They still have a wheel
at each of four corners of a rectangle, with panels that bend when
bumped.

> No need to dream.  The jump from the Inferno port to a plan9 port
> is largely known territory.  It's just a whacky mips and so if you are
> willing to get the mmu/tlb stuff right then you are almost there.  The
> most interesting part is deciding what to do about graphics.  /dev/draw
> would be an easy way out (the linux guys just went for a slow X) but
> the chip is more fun than that.
>
A fast VNC would justify me buying it already.  Games would be a
terribly exciting option.  What are we wasting our time on 386s
for? And, last important question, how well does the chip deal with
virtualisation?

Oh, clustering would be neat too, but maybe I should keep that for
Slashdot :-)

++L

Re: [9fans] dynamic loading, was "Ugly Q, I admit"

[Bruce Ellis]

> And, last important question, how well does the chip deal with
> virtualisation?

In the "I'm a CPU" sense it is not too unlike any other mips.
Not different enough from the 4700 or the 7000 to get me upset.

brucee

Re: [9fans] dynamic loading, was "Ugly Q, I admit"

[Lucio De Re]

On Thu, Nov 28, 2002 at 01:54:12AM -0500, Bruce Ellis wrote:
>
> In the "I'm a CPU" sense it is not too unlike any other mips.
> Not different enough from the 4700 or the 7000 to get me upset.
>
I entered the commercial computer marketplace just as sanctions
against South Africa started biting.  Only lucky (?!) developers
in the Defence and Police forces got to see all the exciting
architectures.

What I'm asking is how hard it would be for a VMware-like utility
to allow Plan 9 and the "native" operating system to co-exist.
Then one can play games _and_ have a Plan 9 system.

There are lots of PS2s out there!  Few of them, at least relatively,
are likely to be running Linux, fewer still are likely to be bought
to run Plan 9.

In passing, the NetBSD folk are getting close to providing PowerPC
and i386 emulation for OS-X on the Apple platforms.  That is equally
exciting.  Is this how the Wintel egemony (sp?) is going to be
broken?

++L

Re: [9fans] dynamic loading, was "Ugly Q, I admit"

[Jack Johnson]

On Thu, 2002-11-28 at 01:49, okamoto@granite.cias.osakafu-u.ac.jp wrote:
> are not using, and expect fast booting when we need it.   I choose Plan 9 definitly
> than Windows or Unices from this point (other reasons are also there though).

Is anyone booting Plan 9 terminals over 802.11b?  (Is that even possible
yet?)

If so, are there any caveats or gotchas someone attempting this should
watch out for?

-Jack

Re: [9fans] dynamic loading, was "Ugly Q, I admit"

[Ronald G. Minnich]

On Thu, 28 Nov 2002 okamoto@granite.cias.osakafu-u.ac.jp wrote:

> > hmm. I've seen 12 second-to-multiuser boots or less with linuxbios
> > machines from power-on. I have a busybox linux+linuxbios box that boots in
> > 5 seconds -- no /etc/rc nonsense in there though. This is the first box
> > I've had that boots faster than an LCD can go from sleep mode to
> > displaying.
>
> What is linuxbios machine?  It's BIOS is what written in ROM?

see www.linuxbios.org, and I am sorry to have taken this so far
off-topic.

Except, we really hope to finish up the fast plan9 boot from linuxbios
next summer ...

> This is much expanded when we use gnome...  I believe this is not rare
> for many of Linux users.

I always remove gnome.

ron

Re: [9fans] dynamic loading, was "Ugly Q, I admit"

[okamoto]

> hmm. I've seen 12 second-to-multiuser boots or less with linuxbios
> machines from power-on. I have a busybox linux+linuxbios box that boots in
> 5 seconds -- no /etc/rc nonsense in there though. This is the first box
> I've had that boots faster than an LCD can go from sleep mode to
> displaying.

What is linuxbios machine?  It's BIOS is what written in ROM?

> The problem now is idiot /etc/rc scripts. I have a k6 with normal bios
> that boots redhat 6 faster than a k7+linuxbios box -- the difference is
> the stupid scripts. Lots of 'sleep x' in those things. yuck.

Yes, many server programs are starting during booting of individual desktop
Linux box.   Kanji treating servers are also neccessary to us.  I must wait more
than 1 minutes untill I can login to the machine!!   This is much expanded when
we use gnome...   I believe this is not rare for many of Linux users.

> I like Plan 9 but fast boots is not something I've seen in use.

Probably, your setting would be something special than us, I believe.
When we wnat to use a machine as our desktop, we want to save power when we
are not using, and expect fast booting when we need it.   I choose Plan 9 definitly
than Windows or Unices from this point (other reasons are also there though).
Plan 9 separated terminals from servers, and it contributed for this purpose.
Am I wrong?

Kenji

Re: [9fans] dynamic loading, was "Ugly Q, I admit"

[andrey mirtchovski]

On Wed, 27 Nov 2002, Ronald G. Minnich wrote:

> Actually there is some step in plan 9 that makes my PCs take forever to
> boot. Don't know what it is. But they don't typically boot faster than
> Linux for me.
>

i can't speak for anything that i don't have, but my p9 installation boots
on par with freebsd (~34 seconds, freebsd does not have the 10 second
delay before bootstrapping the kernel) to fully functional network-enabled
node (including X). if i had a file server p9 would boot even faster.

the only difference is that i log into p9, while freebds just prompts me
for one...

i strongly believe that boot time is only essential with terminals (which
do get to be rebooted more often) and that with LinuxBIOS-enabled kernel
it won't be hard at all to get the boot time down to linux levels on
a reasonable hardware.

i plan to prove myself wrong someday :)

andrey

ps: your p9 machine isn't trying to dhcp itself in the presence of no dhcp
servers?

Re: [9fans] dynamic loading, was "Ugly Q, I admit"

[Ronald G. Minnich]

On Thu, 28 Nov 2002 okamoto@granite.cias.osakafu-u.ac.jp wrote:

> In addition, I have to wait loooooong time to bootup linux.

hmm. I've seen 12 second-to-multiuser boots or less with linuxbios
machines from power-on. I have a busybox linux+linuxbios box that boots in
5 seconds -- no /etc/rc nonsense in there though. This is the first box
I've had that boots faster than an LCD can go from sleep mode to
displaying.

The problem now is idiot /etc/rc scripts. I have a k6 with normal bios
that boots redhat 6 faster than a k7+linuxbios box -- the difference is
the stupid scripts. Lots of 'sleep x' in those things. yuck.

Actually there is some step in plan 9 that makes my PCs take forever to
boot. Don't know what it is. But they don't typically boot faster than
Linux for me.

I like Plan 9 but fast boots is not something I've seen in use.

ron

Re: [9fans] dynamic loading, was "Ugly Q, I admit"

[okamoto]

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

In addition, I have to wait loooooong time to bootup linux.
This is similar or longer to bootup time of Windows 98 of my another machine.
Plan 9 teminal, if compared witho those, boots up in an instant.  ☺

Kenji   --Am I insulting Linux?   I don't think so though...

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

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] dynamic loading, was "Ugly Q, I admit"
Date: Thu, 28 Nov 2002 15:32:23 +0900
Message-ID: <1b417c520209d996d43ec013e64507e1@granite.cias.osakafu-u.ac.jp>

> I set up Plan 9 system at home on a slow (K6/2-233, relatively, 
> of course ☺) 

Oops!

It is Cyrix PR-200 (counted as 167 MHz by Plan 9).   I forgot I had
converted the K6-2 machine to Plan 9 Auth/kfs server.   The graphics
chips was also converted to the Cyrix machine.

Kenji

Re: [9fans] dynamic loading, was "Ugly Q, I admit"

[okamoto]

> I set up Plan 9 system at home on a slow (K6/2-233, relatively,
> of course ☺)

Oops!

It is Cyrix PR-200 (counted as 167 MHz by Plan 9).   I forgot I had
converted the K6-2 machine to Plan 9 Auth/kfs server.   The graphics
chips was also converted to the Cyrix machine.

Kenji

Re: [9fans] dynamic loading, was "Ugly Q, I admit"

[okamoto]

>  (the linux guys just went for a slow X)

Yeah!
I set up Plan 9 system at home on a slow (K6/2-233, relatively,
of course ☺) machine with a S3 Virge/GX (4MB) graphic chip for
1024x768x16, and RedHat Linux 7.2 is also running on the same
machine.   I found X is very very slow when compared with rio. ^_^

Anyway, PS2 Plan 9 is running in anywhere?

Kenji

[9fans] dynamic loading, was "Ugly Q, I admit"

[Joel Salomon]

> btw e[acl] is the compiler port for the playstation 2 ee5900

Is this for writing PS2 games or for running plan9 on the PS2+hard drive
combo they sell for running Linux?

--Joel
______________________________________________________
Due to economic circumstances, the light at the end of
the tunnel has been turned off.