Re: [9fans] Linuxemu

Re: [9fans] Linuxemu

[Russ Cox]

> thanks a lot for linuxemu! However, I was only able to run the stuff
> included with /bin. Other linux progs (sort, bc...) did not work
> (see below). May it be they were dynamically linked with glibc?
> Thus, isn't there a dosemu around there? (Perhaps it would be easier

right, /bin is typically statically linked, while /usr/bin
is dynamically linked.  like i said, it wouldn't be too hard
to make dynamic linking work.  in theory,

	linuxemu ld-linux.so.1 bin/a.dynamic

is supposed to work, but unfortunately ld-linux.so.1
wants to be loaded where the linuxemu text segment is.
you'd need to move the linuxemu text segment somewhere
else and then segdetach it before calling elfload.  it's entirely
doable, especially since x86 code is position independent.

dosemu is much harder because you have to deal with
all the weird 16-bit processor modes.  at that point it's easier
just to simulate the 16-bit processor than to get plan 9 to
set up the processor the way you want it.  the other problem
with dosemu is that the set of system calls doesn't map as
nicely to plan 9 system calls.  i wrote one of those too, but
only enough to execute the vga bios code.  the theory was
that this might be significantly easier than the kernel support
required.  i still think that's true, but it didn't just work.  there
are some things that need certain timing to work out properly,
and the simulator is too slow.  at least, that's my theory.
i think there's still hope for it -- you could hard code certain
sequences that had to run nearer to full speed and run them
as one pseudo-op in the simulator.

[9fans] LinuxEMU

[David Leimbach]

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

The SVN thread got me thinking that I had remembered seeing Ron post
something about what I thought was an in-kernel LinuxEMU that got a little
better performance on plan 9.

Is this true?  I know the currently LinuxEMU is pretty impressive and can
run a large range of programs (Web browsers even!), but that sometimes the
performance is a little bit less than what might be desired.   I believe
this was due to extra system call overheads for each linux kernel call.

Does anyone know what I'm talking about or am I just babbling away here?

Dave

[-- Attachment #2: Type: text/html, Size: 630 bytes --]

Re: [9fans] LinuxEMU

[ron minnich]

I have a syscall emulation implementation in the 9k kernel that is a
starting point but not nearly as complete as linuxemu. People are
welcome to have a go at it.

The big advantage I see is that the emulation overhead for very common
calls (read, write, etc.) is pretty much zero.

ron

Re: [9fans] LinuxEMU

[David Leimbach]

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

That's pretty great!  Is that on contrib?

On Mon, Jan 18, 2010 at 12:01 PM, ron minnich <rminnich@gmail.com> wrote:

> I have a syscall emulation implementation in the 9k kernel that is a
> starting point but not nearly as complete as linuxemu. People are
> welcome to have a go at it.
>
> The big advantage I see is that the emulation overhead for very common
> calls (read, write, etc.) is pretty much zero.
>
> ron
>
>

[-- Attachment #2: Type: text/html, Size: 716 bytes --]

Re: [9fans] LinuxEMU

[ron minnich]

http://bitbucket.org/ericvh/hare/


no support from anyone and it's not really set up to work on a PC.
There is an issue that PPC has only one system call vector. So what
you do write write a value to /dev/cnkemu to switch modes. You can
start up with plan 9 system calls, then switch modes to linux system
calls. I have found this handy.

on x86 you just have to vector int 80 to a linux syscall handler.

RIght now this is really oriented to BG/P but it's so simple you may
find it useful.

ron

Re: [9fans] LinuxEMU

[cinap_lenrek]

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

i think a lot of the slowdown comes from that linux was not
streamlined its userspace, but the userspace just got more and more
complicated and does tons of redundant stuff...  what they did then
was not to fix userspace, but they optimized the kernel to cache
anything...

look at some typical syscall traces...  tons of files are stat()ed...
multiple times...  it opens unix domain sockets to talk to a not
existant ldap name service or something...  tons of shared libraries
are loaded...  and that is all before even your main() entry is gets
called...

linuxemu doesnt shortcut these things...  i cant reuse the shared
library mmaps on exec ect...  i think walks are not cached in plan9,
so you have to talk to your fileserver.

the syscall overhead is just one of the bottlenecks of linux emulation
and you would have to put tons of more crap in the kernel to get
mozilla or opera working...  and even more to get it half as fast as
in linux.

just keep plan9 small and simple.  you dont want to maintain something
as complex and optimized-to-death as the full linux kernel with all
that caching and read aheading and 100 different stat syscalls.

we shouldnt be araid of writing new programs and dont concentrate on
keeping the legacy alive so mutch.  you can even run linux/major os
side by side with plan9 these days on virtual machines.  and this gets
cheaper every day without doing anything.  in fact this seems to be
what most people on iwp9 where doing.  (on ther fucking macbooks)

;-)

--
cinap

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

[-- Attachment #2.1.1: Type: text/plain, Size: 561 bytes --]

The SVN thread got me thinking that I had remembered seeing Ron post
something about what I thought was an in-kernel LinuxEMU that got a little
better performance on plan 9.

Is this true?  I know the currently LinuxEMU is pretty impressive and can
run a large range of programs (Web browsers even!), but that sometimes the
performance is a little bit less than what might be desired.   I believe
this was due to extra system call overheads for each linux kernel call.

Does anyone know what I'm talking about or am I just babbling away here?

Dave

[-- Attachment #2.1.2: Type: text/html, Size: 630 bytes --]

Re: [9fans] LinuxEMU

[David Leimbach]

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

Good post!  Thanks for the information.  I have looked at linux traces
before and couldn't figure out why the hell so much crap was being done.
 It's as if glibc is throwing calls at the system to figure out which kernel
it's on - another good argument for the FreeBSD model of keeping kernel and
userspace in sync with one another.

(typed on my fucking macbook)

Dave

On Mon, Jan 18, 2010 at 2:43 PM, <cinap_lenrek@gmx.de> wrote:

> i think a lot of the slowdown comes from that linux was not
> streamlined its userspace, but the userspace just got more and more
> complicated and does tons of redundant stuff...  what they did then
> was not to fix userspace, but they optimized the kernel to cache
> anything...
>
> look at some typical syscall traces...  tons of files are stat()ed...
> multiple times...  it opens unix domain sockets to talk to a not
> existant ldap name service or something...  tons of shared libraries
> are loaded...  and that is all before even your main() entry is gets
> called...
>
> linuxemu doesnt shortcut these things...  i cant reuse the shared
> library mmaps on exec ect...  i think walks are not cached in plan9,
> so you have to talk to your fileserver.
>
> the syscall overhead is just one of the bottlenecks of linux emulation
> and you would have to put tons of more crap in the kernel to get
> mozilla or opera working...  and even more to get it half as fast as
> in linux.
>
> just keep plan9 small and simple.  you dont want to maintain something
> as complex and optimized-to-death as the full linux kernel with all
> that caching and read aheading and 100 different stat syscalls.
>
> we shouldnt be araid of writing new programs and dont concentrate on
> keeping the legacy alive so mutch.  you can even run linux/major os
> side by side with plan9 these days on virtual machines.  and this gets
> cheaper every day without doing anything.  in fact this seems to be
> what most people on iwp9 where doing.  (on ther fucking macbooks)
>
> ;-)
>
> --
> cinap
>
>
> ---------- Forwarded message ----------
> From: David Leimbach <leimy2k@gmail.com>
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Date: Mon, 18 Jan 2010 11:15:43 -0800
> Subject: [9fans] LinuxEMU
> The SVN thread got me thinking that I had remembered seeing Ron post
> something about what I thought was an in-kernel LinuxEMU that got a little
> better performance on plan 9.
>
> Is this true?  I know the currently LinuxEMU is pretty impressive and can
> run a large range of programs (Web browsers even!), but that sometimes the
> performance is a little bit less than what might be desired.   I believe
> this was due to extra system call overheads for each linux kernel call.
>
> Does anyone know what I'm talking about or am I just babbling away here?
>
> Dave
>
>

[-- Attachment #2: Type: text/html, Size: 3400 bytes --]

Re: [9fans] LinuxEMU

[David Leimbach]

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

Also, the more I think about it, the more interesting I think it is to run
different OSes in different domains on the same machines anyway.  If you
want to make one thing work with another, we've got cool stuff like 9p and
v9fs to bridge gaps.

This is a very good way to force a separation of concerns between layers
anyway.  L4 seems to have a way for linux processes to talk to other L4
processes using L4 IPC when it's used for virtualization, so why not use 9P
to talk across virtualization domains?

Dave

On Mon, Jan 18, 2010 at 3:16 PM, David Leimbach <leimy2k@gmail.com> wrote:

> Good post!  Thanks for the information.  I have looked at linux traces
> before and couldn't figure out why the hell so much crap was being done.
>  It's as if glibc is throwing calls at the system to figure out which kernel
> it's on - another good argument for the FreeBSD model of keeping kernel and
> userspace in sync with one another.
>
> (typed on my fucking macbook)
>
> Dave
>
> On Mon, Jan 18, 2010 at 2:43 PM, <cinap_lenrek@gmx.de> wrote:
>
>> i think a lot of the slowdown comes from that linux was not
>> streamlined its userspace, but the userspace just got more and more
>> complicated and does tons of redundant stuff...  what they did then
>> was not to fix userspace, but they optimized the kernel to cache
>> anything...
>>
>> look at some typical syscall traces...  tons of files are stat()ed...
>> multiple times...  it opens unix domain sockets to talk to a not
>> existant ldap name service or something...  tons of shared libraries
>> are loaded...  and that is all before even your main() entry is gets
>> called...
>>
>> linuxemu doesnt shortcut these things...  i cant reuse the shared
>> library mmaps on exec ect...  i think walks are not cached in plan9,
>> so you have to talk to your fileserver.
>>
>> the syscall overhead is just one of the bottlenecks of linux emulation
>> and you would have to put tons of more crap in the kernel to get
>> mozilla or opera working...  and even more to get it half as fast as
>> in linux.
>>
>> just keep plan9 small and simple.  you dont want to maintain something
>> as complex and optimized-to-death as the full linux kernel with all
>> that caching and read aheading and 100 different stat syscalls.
>>
>> we shouldnt be araid of writing new programs and dont concentrate on
>> keeping the legacy alive so mutch.  you can even run linux/major os
>> side by side with plan9 these days on virtual machines.  and this gets
>> cheaper every day without doing anything.  in fact this seems to be
>> what most people on iwp9 where doing.  (on ther fucking macbooks)
>>
>> ;-)
>>
>> --
>> cinap
>>
>>
>> ---------- Forwarded message ----------
>> From: David Leimbach <leimy2k@gmail.com>
>> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
>> Date: Mon, 18 Jan 2010 11:15:43 -0800
>> Subject: [9fans] LinuxEMU
>> The SVN thread got me thinking that I had remembered seeing Ron post
>> something about what I thought was an in-kernel LinuxEMU that got a little
>> better performance on plan 9.
>>
>> Is this true?  I know the currently LinuxEMU is pretty impressive and can
>> run a large range of programs (Web browsers even!), but that sometimes the
>> performance is a little bit less than what might be desired.   I believe
>> this was due to extra system call overheads for each linux kernel call.
>>
>> Does anyone know what I'm talking about or am I just babbling away here?
>>
>> Dave
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4470 bytes --]

Re: [9fans] LinuxEMU

[Eric Van Hensbergen]

http://www.linux-kvm.org/wiki/images/4/41/KvmForum2008$kdf2008_16.pdf

On Mon, Jan 18, 2010 at 3:20 PM, David Leimbach <leimy2k@gmail.com> wrote:
> Also, the more I think about it, the more interesting I think it is to run
> different OSes in different domains on the same machines anyway.  If you
> want to make one thing work with another, we've got cool stuff like 9p and
> v9fs to bridge gaps.
> This is a very good way to force a separation of concerns between layers
> anyway.  L4 seems to have a way for linux processes to talk to other L4
> processes using L4 IPC when it's used for virtualization, so why not use 9P
> to talk across virtualization domains?
> Dave
>
> On Mon, Jan 18, 2010 at 3:16 PM, David Leimbach <leimy2k@gmail.com> wrote:
>>
>> Good post!  Thanks for the information.  I have looked at linux traces
>> before and couldn't figure out why the hell so much crap was being done.
>>  It's as if glibc is throwing calls at the system to figure out which kernel
>> it's on - another good argument for the FreeBSD model of keeping kernel and
>> userspace in sync with one another.
>> (typed on my fucking macbook)
>> Dave
>>
>> On Mon, Jan 18, 2010 at 2:43 PM, <cinap_lenrek@gmx.de> wrote:
>>>
>>> i think a lot of the slowdown comes from that linux was not
>>> streamlined its userspace, but the userspace just got more and more
>>> complicated and does tons of redundant stuff...  what they did then
>>> was not to fix userspace, but they optimized the kernel to cache
>>> anything...
>>>
>>> look at some typical syscall traces...  tons of files are stat()ed...
>>> multiple times...  it opens unix domain sockets to talk to a not
>>> existant ldap name service or something...  tons of shared libraries
>>> are loaded...  and that is all before even your main() entry is gets
>>> called...
>>>
>>> linuxemu doesnt shortcut these things...  i cant reuse the shared
>>> library mmaps on exec ect...  i think walks are not cached in plan9,
>>> so you have to talk to your fileserver.
>>>
>>> the syscall overhead is just one of the bottlenecks of linux emulation
>>> and you would have to put tons of more crap in the kernel to get
>>> mozilla or opera working...  and even more to get it half as fast as
>>> in linux.
>>>
>>> just keep plan9 small and simple.  you dont want to maintain something
>>> as complex and optimized-to-death as the full linux kernel with all
>>> that caching and read aheading and 100 different stat syscalls.
>>>
>>> we shouldnt be araid of writing new programs and dont concentrate on
>>> keeping the legacy alive so mutch.  you can even run linux/major os
>>> side by side with plan9 these days on virtual machines.  and this gets
>>> cheaper every day without doing anything.  in fact this seems to be
>>> what most people on iwp9 where doing.  (on ther fucking macbooks)
>>>
>>> ;-)
>>>
>>> --
>>> cinap
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: David Leimbach <leimy2k@gmail.com>
>>> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
>>> Date: Mon, 18 Jan 2010 11:15:43 -0800
>>> Subject: [9fans] LinuxEMU
>>> The SVN thread got me thinking that I had remembered seeing Ron post
>>> something about what I thought was an in-kernel LinuxEMU that got a little
>>> better performance on plan 9.
>>> Is this true?  I know the currently LinuxEMU is pretty impressive and can
>>> run a large range of programs (Web browsers even!), but that sometimes the
>>> performance is a little bit less than what might be desired.   I believe
>>> this was due to extra system call overheads for each linux kernel call.
>>> Does anyone know what I'm talking about or am I just babbling away here?
>>> Dave
>>
>
>

Re: [9fans] LinuxEMU

[Ethan Grammatikidis]

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


On 18 Jan 2010, at 10:43 pm, cinap_lenrek@gmx.de wrote:

> i think a lot of the slowdown comes from that linux was not
> streamlined its userspace, but the userspace just got more and more
> complicated and does tons of redundant stuff...  what they did then
> was not to fix userspace, but they optimized the kernel to cache
> anything...
>
> look at some typical syscall traces...  tons of files are stat()ed...
> multiple times...  it opens unix domain sockets to talk to a not
> existant ldap name service or something...  tons of shared libraries
> are loaded...  and that is all before even your main() entry is gets
> called...
>
> linuxemu doesnt shortcut these things...  i cant reuse the shared
> library mmaps on exec ect...  i think walks are not cached in plan9,
> so you have to talk to your fileserver.
>
> the syscall overhead is just one of the bottlenecks of linux emulation
> and you would have to put tons of more crap in the kernel to get
> mozilla or opera working...  and even more to get it half as fast as
> in linux.
>
> just keep plan9 small and simple.

Indeed! I doubt I'd be interested in looking at a plan-9-turned-into-
linux kernel ever! :)

You got me wondering how much could be cached in linuxemu. Would a
cache server filesystem make sense?


--
http://xkcd.com/676/

Ethan Grammatikidis
eekee57@fastmail.fm




[-- Attachment #2: Type: text/html, Size: 4945 bytes --]

Re: [9fans] LinuxEMU

[Enrico Weigelt]

cinap_lenrek@gmx.de wrote:

> look at some typical syscall traces...  tons of files are stat()ed...
> multiple times...  it opens unix domain sockets to talk to a not
> existant ldap name service or something...  tons of shared libraries
> are loaded...  and that is all before even your main() entry is gets
> called...

ACK. Much of this crap is done by glibc.
Perhaps an specialized libc would be a good way to go ?


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] LinuxEMU

[cinap_lenrek]

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

here are efforts to build a staticly linked linux distribution:

http://stali.suckless.org/

have not tried it on linuxemu yet, but from the discription they
will use some alternative tiny libc.

looks like the right direction...

--
cinap

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

From: Enrico Weigelt <weigelt@metux.de>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] LinuxEMU
Date: Sat, 06 Feb 2010 02:08:28 +0100
Message-ID: <4B6CC10C.6040501@metux.de>

cinap_lenrek@gmx.de wrote:

> look at some typical syscall traces...  tons of files are stat()ed...
> multiple times...  it opens unix domain sockets to talk to a not
> existant ldap name service or something...  tons of shared libraries
> are loaded...  and that is all before even your main() entry is gets
> called...

ACK. Much of this crap is done by glibc.
Perhaps an specialized libc would be a good way to go ?


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] LinuxEMU

[David Leimbach]

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

On Sat, Feb 6, 2010 at 9:56 AM, <cinap_lenrek@gmx.de> wrote:

> here are efforts to build a staticly linked linux distribution:
>
> http://stali.suckless.org/
>
> have not tried it on linuxemu yet, but from the discription they
> will use some alternative tiny libc.
>
> looks like the right direction...
>
> --
> cinap
>
>
> ---------- Forwarded message ----------
> From: Enrico Weigelt <weigelt@metux.de>
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Date: Sat, 06 Feb 2010 02:08:28 +0100
> Subject: Re: [9fans] LinuxEMU
> cinap_lenrek@gmx.de wrote:
>
> > look at some typical syscall traces...  tons of files are stat()ed...
> > multiple times...  it opens unix domain sockets to talk to a not
> > existant ldap name service or something...  tons of shared libraries
> > are loaded...  and that is all before even your main() entry is gets
> > called...
>
> ACK. Much of this crap is done by glibc.
> Perhaps an specialized libc would be a good way to go ?
>
>
> cu
> --
> ----------------------------------------------------------------------
>  Enrico Weigelt, metux IT service -- http://www.metux.de/
>
>  cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
> ----------------------------------------------------------------------
>  Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
> ----------------------------------------------------------------------
>
>

[-- Attachment #2: Type: text/html, Size: 2083 bytes --]

[9fans] Linuxemu

[peter a. cejchan]

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

would somebody be interested in doing me a favor with the following [dznamic linking] (it's too much for my limited abilities, sigh.. :-)

tia,++pac.

>>> russ Cox wrote: >>>
I made linuxemu compile again, and it seems that
it doesn't support dynamically linked binaries.  I don't
think it's hard, but apparently never did it.

http://pdos.lcs.mit.edu/~rsc/linuxemu.tar.gz

g% 8.out bin/a.hello
segattach(8000080,10b94)...
hello world
g% 

Russ

> thanks a lot for linuxemu! However, I was only able to run the stuff
> included with /bin. Other linux progs (sort, bc...) did not work
> (see below). May it be they were dynamically linked with glibc?
> Thus, isn't there a dosemu around there? (Perhaps it would be easier

right, /bin is typically statically linked, while /usr/bin
is dynamically linked.  like i said, it wouldn't be too hard
to make dynamic linking work.  in theory,

	linuxemu ld-linux.so.1 bin/a.dynamic

is supposed to work, but unfortunately ld-linux.so.1
wants to be loaded where the linuxemu text segment is.
you'd need to move the linuxemu text segment somewhere
else and then segdetach it before calling elfload.  it's entirely
doable, especially since x86 code is position independent.



[-- Attachment #2: Type: text/html, Size: 2051 bytes --]

[9fans] Linuxemu

[Petr Cejchan]

Hi,
thanks a lot for linuxemu! However, I was only able to run the stuff
included with /bin. Other linux progs (sort, bc...) did not work
(see below). May it be they were dynamically linked with glibc?
Thus, isn't there a dosemu around there? (Perhaps it would be easier

to make tru black dos progs run under plan9...)
[sorry again for this, but some people dislike to share their
sources, sigh]

Best regards,
++pac.

-- 
---
Ušetřete provoz na své internetové lince umístěním serveru do
profesionálních housingových prostor Jet2Web Czech Republic. Váš
server bude pod trvalým bezpečnostním dohledem, v případě poruchy
provedeme na vaši žádost jeho restart. K serveru máte přístup 24
hodin denně. Více informací na:
http://www.jet2web.cz/cs/products?article=jet2web_products_housing_housing