user-mode-linux-devel

Re: [uml-devel] Partial boot log of User Mode Linux on Windows *grin*

[Jeff D. <jd...@ka...>]

ka...@ca... said:
> I need to know why we need setitimer, so can find the Win32
> alternative for it. 

That's the clock.  The kernel won't work too well without a clock.  The 
immediate place that you're going to need it is during the delay loop 
calibration.  There needs to be a SIGVTALRM firing HZ times a second at that 
point.

> The problem is that it doesn't compile if I don't defined the
> __setup_start and __setup_end manually (although the are defined in
> the ld script I use), so that checksetup() could successfully enumrate
> them. 

How do you define them?

> When I defined them, checksetup() seems to be enumrating 6
> zeroed kernel_param structs. So root_dev_setup isn't get called, as a
> result. Any idea?

Are there 6 __setups in the kernel?  I would become familiar with objdump and 
use it to figure out what's in that section of the binary and what's not.  
Also locate what's not there, and that might give you some clues as to what's 
going on.

				Jeff

[uml-devel] that last set of checkins

[Jeff D. <jd...@ka...>]

doesn't exist as a patch because SourceForge has seriously hosed their upload 
system.  There are all kinds of things wrong with it.

So, assuming they don't manage to hose CVS while they're at it, you can get 
the latest stuff from there.

				Jeff

Re: [uml-devel] Partial boot log of User Mode Linux on Windows *grin*

[Dan A. <ka...@ca...>]

On Sat, 9 Dec 2000, Jeff Dike wrote:

> ka...@ca... said:
> > tracing thread pid = 320 Linux version 2.4.0-test12-1um (administrator@xena) (gcc version 2.95.2-5  19991024 (cygwin experimental)) #159 Sat Dec 9 21:43:37 2000 
> 
> Heh.  Very cool.
> 
> > fixed printk() to print (well, console_drivers is NULL for some
> > reason)
> 
> That's because the console driver hasn't been initialized.  printk stores up 
> the stuff and dumps it out when console_init gets called.

I have a problem with the __setup mechanism used in the kernel. The
ld script along with the __setup macro supposes to create a section in the
executable with a bunch of kernel_param structs that were defined
throughout the kernel by using __setup, so that various modules could
insert their own kernel params without changing any kernel code. The
problem is that it doesn't compile if I don't defined the __setup_start
and __setup_end manually (although the are defined in the ld script I
use), so that checksetup() could successfully enumrate them. When I
defined them, checksetup() seems to be enumrating 6 zeroed kernel_param
structs. So root_dev_setup isn't get called, as a result. Any idea?

-- 
Dan Aloni 
da...@ka...

[uml-devel] more checkins

[Jeff D. <jd...@ka...>]

hostfs now mostly works.  The main exceptions are running executables and 
mknod.  Also, it gets impossible to unmount after enough things are done 
inside it.

Fixed that linking problem.  It turned out to be triggered by doing a 
profiling build.

I think I fixed the crash reported by James Stevenson (he hasn't told me 
whether this fix changes anything, though).

"fake_arch" is now history.  I ran into one build problem too many caused by 
UML reporting its architecture as "um".  So, it now claims its architecture is 
"i386".

				Jeff

Re: [uml-devel] Partial boot log of User Mode Linux on Windows *grin*

[Jeff D. <jd...@ka...>]

ka...@ca... said:
> tracing thread pid = 320 Linux version 2.4.0-test12-1um (administrator@xena) (gcc version 2.95.2-5  19991024 (cygwin experimental)) #159 Sat Dec 9 21:43:37 2000 

Heh.  Very cool.

> fixed printk() to print (well, console_drivers is NULL for some
> reason)

That's because the console driver hasn't been initialized.  printk stores up 
the stuff and dumps it out when console_init gets called.

				Jeff

[uml-devel] Partial boot log of User Mode Linux on Windows *grin*

[Dan A. <ka...@ca...>]

Heh, after I got setup_memory() to work, and fixed printk() to print
(well, console_drivers is NULL for some reason), I got the first
(very initial/partial) boot log of Linux on win32 ;-)

tracing thread pid = 320
Linux version 2.4.0-test12-1um (administrator@xena) (gcc version 2.95.2-5 
19991024 (cygwin experimental)) #159 Sat Dec 9 21:43:37 2000
On node 0 totalpages: 4096
zone(0): 0 pages.
zone(1): 4096 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/ubd0

Aiks, here it crashes for some reason, I'm working on it.

-- 
Dan Aloni 
da...@ka...

RE: [uml-devel] cygnus-win32 port of User Mode Linux

[Dan A. <ka...@ca...>]

On Fri, 8 Dec 2000, Michael Vines wrote:

> > This is very preliminary, so no public patches at the moment. If anyone
> > can help, jump in.
> 
> I was thinking about this last night, once the kernel is compiling with
> cygwin (ie. once the bulk of the work is done) I could probably help out
> with merging/rewriting the syscall trapping code from LINE
> (http://neomueller.org/~isamu/line/) into UML if nobody else is doing
> it.  The actual relevant code is quite small.
> 
> I'm a little unsure on the details but I wonder if we could create
> something like another binfmt for native x86 Linux executables on the
> cygwin/NT port.  Then you could do uber-cool things like have native
> cygwin (COFF?) Linux applications running in the same UML as regular x86
> Linux apps.  But I guess that also depends on how the native cygwin apps
> invoke a syscall.  If they use a int 0x80 like real Linux apps then there
> would be no need for the distinction (except perhaps in the loader).
> Although I don't think that int 0x80 would be the best method for native
> NT apps given a choice.

Native cygwin apps are linked to the cygwin DLL, and are regular win32
executables. 

I thought how can we have executable on Windows to be runnable with the
int 0x80 calling method - we can run the executable in a debug mode, and
trap 'calls' to int 0x80. This is what LINE does. I think we can also
write a Windows driver to handle those executable ; imagine Windows being
able to load ELF executables, and adnle int 0x80 calls like Linux does? 

-- 
Dan Aloni 
da...@ka...

Re: [uml-devel] cygnus-win32 port of User Mode Linux

[Jeff D. <jd...@ka...>]

epa...@cs... said:
> It can't be much worse than ptracing, rewriting the system call,
> making a new system call, and then returning. 

I'm hoping to get that overhead down to the point where something like 
protecting the kernel becomes a noticable performance problem :-)

				Jeff

Re: [uml-devel] cygnus-win32 port of User Mode Linux

[Jeff D. <jd...@ka...>]

mj...@un... said:
> That sounds like a pretty severe performance hit.   

Maybe.  If it turns out to be a problem, we can just have a slow secure mode 
and a fast insecure mode.

				Jeff

Re: [uml-devel] cygnus-win32 port of User Mode Linux

[Erik P. <epa...@cs...>]

On Fri, Dec 08, 2000 at 05:50:40PM -0500, Michael Vines wrote:
> > > If that is the case, then what is stopping the
> > > application from peaking into UML?   
> > 
> > Nothing now, but I'm going to make it protect (or unmap) the kernel whenever 
> > it's in userspace.  That will make it impossible to fiddle kernel data from 
> > the process, and that will make it a fairly secure jail.
> 
> That sounds like a pretty severe performance hit.  
> 

It can't be much worse than ptracing, rewriting the system call, making a new
system call, and then returning.

-Erik

Re: [uml-devel] cygnus-win32 port of User Mode Linux

[Michael V. <mj...@un...>]

On Fri, 8 Dec 2000, Jeff Dike wrote:
>
> > If that is the case, then what is stopping the
> > application from peaking into UML?   
> 
> Nothing now, but I'm going to make it protect (or unmap) the kernel whenever 
> it's in userspace.  That will make it impossible to fiddle kernel data from 
> the process, and that will make it a fairly secure jail.

That sounds like a pretty severe performance hit.  


> > That way so long as you had a gcc+glibc for your platform you could
> > compile and run a UML.
> 
> And if you already have glibc, you've already got Posix.

Touche.  


Mike

Re: [uml-devel] cygnus-win32 port of User Mode Linux

[Jeff D. <jd...@ka...>]

mj...@un... said:
> Doesn't UML need to be mapped into the address space of the
> application?  

Yup.

> If that is the case, then what is stopping the
> application from peaking into UML?   

Nothing now, but I'm going to make it protect (or unmap) the kernel whenever 
it's in userspace.  That will make it impossible to fiddle kernel data from 
the process, and that will make it a fairly secure jail.

> That way so long as you had a gcc+glibc for your platform you could
> compile and run a UML.

And if you already have glibc, you've already got Posix.

				Jeff

Re: [uml-devel] cygnus-win32 port of User Mode Linux

[Michael V. <mj...@un...>]

On Fri, 8 Dec 2000, Jeff Dike wrote:

> mj...@un... said:
> > Would the resulting executable be simply a "regular" Linux x86
> > executable, as if it was compiled directly on a real Linux system?
> 
> gcc runs exactly as it would on the native kernel, so the answer is yes.  
> Anything different would require fiddling the compiler (or the libraries, more 
> likely).
> 
> > The immediate advantage I can see for doing that would be that
> > trapping int 0x80 instructions are time consuming, much more so than
> > doing a straight 'call' into the syscall handler.
> 
> Calling into the syscall would be faster, but if the platform is to be at all 
> secure, there also needs to be an unevadable mode switch from unprivileged to 
> privileged mode.

Doesn't UML need to be mapped into the address space of the
application?  If that is the case, then what is stopping the application
from peaking into UML?  


> > You could also do this to run Linux apps on platforms that Linux
> > hasn't even been ported to yet (so long as you can compile UML on that
> > platform). 
> 
> If Linux doesn't run on it, you have to write a fair amount of code to port 
> it, because UML steals most of its headers and some C files from the 
> underlying arch.  

ahhh..ok.  

I guess I was sort of talking about creating a generic virtual UML arch
which isn't really tied to a particular physical arch.  That way so long
as you had a gcc+glibc for your platform you could compile and run a UML.
However admittedly, I can't think of a good reason to do this as the
moment apart from it being "interesting".  But this may be partially due
to the fact that it's Friday afternoon :)


Mike

Re: [uml-devel] cygnus-win32 port of User Mode Linux

[Jeff D. <jd...@ka...>]

mj...@un... said:
> Would the resulting executable be simply a "regular" Linux x86
> executable, as if it was compiled directly on a real Linux system?

gcc runs exactly as it would on the native kernel, so the answer is yes.  
Anything different would require fiddling the compiler (or the libraries, more 
likely).

> The immediate advantage I can see for doing that would be that
> trapping int 0x80 instructions are time consuming, much more so than
> doing a straight 'call' into the syscall handler.

Calling into the syscall would be faster, but if the platform is to be at all 
secure, there also needs to be an unevadable mode switch from unprivileged to 
privileged mode.

> Say someone wanted to run UML on Linux/PPC.  They may not be able to
> run native Linux/PPC apps (without implementing that functionality in
> UML) but they could cross-compile apps into the UML archecture and run
> them that way.

You'd still have to port UML to PPC, and then it would run native Linux/PPC 
apps.  So, this wouldn't make anything easier.

> You could also do this to run Linux apps on platforms that Linux
> hasn't even been ported to yet (so long as you can compile UML on that
> platform). 

If Linux doesn't run on it, you have to write a fair amount of code to port 
it, because UML steals most of its headers and some C files from the 
underlying arch.  In this case, what apps are there for UML to run?  If gcc 
supports the machine, it's compiling binaries for whatever OS is there, so 
that platform already runs all those apps.

				Jeff

Re: [uml-devel] cygnus-win32 port of User Mode Linux

[Michael V. <mj...@un...>]

On Fri, 8 Dec 2000, Jeff Dike wrote:

> mj...@un... said:
> > Has there been any thought into how the windows binaries will be
> > invoking the Linux syscalls? 
> 
> There won't be any windows binaries at all, except for the kernel itself.
> 
> > Apart from the mess of freak hybred applications, I don't see why
> > making windows system calls is a big deal.  How would that interfere
> > with the Linux kernel?  Assuming that the actual Linux syscalls are
> > invoked by a 'call' instruction or something similiar (UML needs to be
> > mapped into the app process space right?) then it seems to me that the
> > app could happily execute all the Windows API calls it wanted and the
> > kernel would be completely oblivious to it all. 
> 
> Why would they be running under UML at all?  It may be possible, but I don't 
> see how it's useful.

Say you fire up cywin/UML and start compiling $(insert_program_here).
Would the resulting executable be simply a "regular" Linux x86 executable,
as if it was compiled directly on a real Linux system?

For some reason I got the idea in my head that another possibilty would be
that the resulting executable could optionally be a "Linux cygwin/UML
executable".  Basically treating cygwin/UML as a seperate arch platform.

The immediate advantage I can see for doing that would be that trapping
int 0x80 instructions are time consuming, much more so than doing a
straight 'call' into the syscall handler.  But cygwin/UML should still be
able to execute regular Linux executables as well.

This idea can be extended to the original UML as well.  Currently UML
executes "real" Linux apps.  But what if there was an actual UML
archecture defined with it's own syscall calling convention and such so
that you could compile apps directly (and only) for UML.

This would significantly ease the porting of UML to other Linux platforms
(and other OSes).  Say someone wanted to run UML on Linux/PPC.  They may
not be able to run native Linux/PPC apps (without implementing that
functionality in UML) but they could cross-compile apps into the UML
archecture and run them that way.  You could also do this to run Linux
apps on platforms that Linux hasn't even been ported to yet (so long as
you can compile UML on that platform).  

Note that the compiled apps for UML would still be tied to a particular
architecture as it would still execute normally on the cpu. The difference
is that that instead of invoking the Linux syscalls the normal "int 0x80"
way, the syscalls would be invoked the "UML way".

I guess this basically turns UML into a fancy POSIX subsystem or
something.  Anyways, just a weird idea I had :)

Mike


 

Re: [uml-devel] cygnus-win32 port of User Mode Linux

[Jeff D. <jd...@ka...>]

mj...@un... said:
> Has there been any thought into how the windows binaries will be
> invoking the Linux syscalls? 

There won't be any windows binaries at all, except for the kernel itself.

> Apart from the mess of freak hybred applications, I don't see why
> making windows system calls is a big deal.  How would that interfere
> with the Linux kernel?  Assuming that the actual Linux syscalls are
> invoked by a 'call' instruction or something similiar (UML needs to be
> mapped into the app process space right?) then it seems to me that the
> app could happily execute all the Windows API calls it wanted and the
> kernel would be completely oblivious to it all. 

Why would they be running under UML at all?  It may be possible, but I don't 
see how it's useful.

> It only converts int 0x80's to int 03's on Win9X platforms, because
> Win9X dies a horrible death whenever it executes int 0x80.  The NT
> version keeps all the int 0x80s because it can handle them no problem.
> 

OK, good.

> Alternatively cygwin/UML could just support NT for now. 

That sounds like a good idea.  Ultimately, UML on W9X might be fun, because 
vmware apparently is NT-only.

				Jeff

Re: [uml-devel] cygnus-win32 port of User Mode Linux

[Michael V. <mj...@un...>]

On Fri, 8 Dec 2000, Jeff Dike wrote:

> > Then you could do uber-cool things like have native cygwin (COFF?)
> > Linux applications running in the same UML as regular x86 Linux apps.
> 
> The windows binaries are apparently COFF only, which is causing some pain.
> 
> If there isn't a binfmt for COFF already, one could be added.  The problem is 
> that those binaries make windows system calls, which a Linux kernel is not 
> prepared to deal with.

Has there been any thought into how the windows binaries will be invoking
the Linux syscalls?

Apart from the mess of freak hybred applications, I don't see why making
windows system calls is a big deal.  How would that interfere with the
Linux kernel?  Assuming that the actual Linux syscalls are invoked by a
'call' instruction or something similiar (UML needs to be mapped into the
app process space right?) then it seems to me that the app could happily
execute all the Windows API calls it wanted and the kernel would be
completely oblivious to it all.  


> Don had a look at your code (I haven't :-(), and apparently you're changing 
> all of the 'int 0x80's to 'int 0x3's.  I don't think that will work too well 
> with UML.  It would be a lot nicer to leave the 'int 0x80's in place and 
> intercept them.  Is that doable?

Yes and no.

It only converts int 0x80's to int 03's on Win9X platforms, because Win9X
dies a horrible death whenever it executes int 0x80.  The NT version keeps
all the int 0x80s because it can handle them no problem.

I suspect that what is happening on Win9X is that when it encounters the
int 0x80 it actually tries to jump to the int 0x80 handler instead of
trapping the instruction as a fault.  It may be fixable by writing a
little VxD which installs a "real" int 0x80 handler that redirects
execution to UML.     

Alternatively cygwin/UML could just support NT for now.


Mike

Re: [uml-devel] cygnus-win32 port of User Mode Linux

[Jeff D. <jd...@ka...>]

mj...@un... said:
> I was thinking about this last night, once the kernel is compiling
> with cygwin (ie. once the bulk of the work is done) I could probably
> help out with merging/rewriting the syscall trapping code from LINE
> (http://neomueller.org/~isamu/line/) into UML if nobody else is doing
> it.

Send him mail :-)  He's got a few undefined symbols left, but he's telling it 
to produce a binary anyway, and it's starting to run.

> I'm a little unsure on the details but I wonder if we could create
> something like another binfmt for native x86 Linux executables on the
> cygwin/NT port.

That's the native elf binfmt - that's already there.

> Then you could do uber-cool things like have native cygwin (COFF?)
> Linux applications running in the same UML as regular x86 Linux apps.

The windows binaries are apparently COFF only, which is causing some pain.

If there isn't a binfmt for COFF already, one could be added.  The problem is 
that those binaries make windows system calls, which a Linux kernel is not 
prepared to deal with.

Don had a look at your code (I haven't :-(), and apparently you're changing 
all of the 'int 0x80's to 'int 0x3's.  I don't think that will work too well 
with UML.  It would be a lot nicer to leave the 'int 0x80's in place and 
intercept them.  Is that doable?

				Jeff

RE: [uml-devel] cygnus-win32 port of User Mode Linux

[Michael V. <mj...@un...>]

Argh!  Sorry for two excess messages...I think I've figured it out.  I had
a period (.) all alone by itself on a line, and my PINE wasn't escaping it
properly :)


---------- Forwarded message ----------
Date: Fri, 8 Dec 2000 09:38:21 -0500 (EST)
From: Michael Vines <mj...@un...>
To: use...@li...
Subject: RE: [uml-devel] cygnus-win32 port of User Mode Linux


On 12/07/2000 07:20:13, Dan Aloni wrote:

> Yesterday was a first attempt to port UML to Micro$oft Windows.
 .
<snip snip>
 .
> This is very preliminary, so no public patches at the moment. If anyone
> can help, jump in.

I was thinking about this last night, once the kernel is compiling with
cygwin (ie. once the bulk of the work is done) I could probably help out
with merging/rewriting the syscall trapping code from LINE
(http://neomueller.org/~isamu/line/) into UML if nobody else is doing
it.  The actual relevant code is quite small.

I'm a little unsure on the details but I wonder if we could create
something like another binfmt for native x86 Linux executables on the
cygwin/NT port.  Then you could do uber-cool things like have native
cygwin (COFF?) Linux applications running in the same UML as regular x86
Linux apps.  But I guess that also depends on how the native cygwin apps
invoke a syscall.  If they use a int 0x80 like real Linux apps then there
would be no need for the distinction (except perhaps in the loader).
Although I don't think that int 0x80 would be the best method for native
NT apps given a choice.

Just some random thoughts...

Mike

RE: [uml-devel] cygnus-win32 port of User Mode Linux

[Michael V. <mj...@un...>]

I think sendmail ate half of my message!  resending...

---------- Forwarded message ----------
Date: Fri, 8 Dec 2000 09:38:21 -0500 (EST)
From: Michael Vines <mj...@un...>
To: use...@li...
Subject: RE: [uml-devel] cygnus-win32 port of User Mode Linux


On 12/07/2000 07:20:13, Dan Aloni wrote:

> Yesterday was a first attempt to port UML to Micro$oft Windows.
.
*snip snip*
.
> This is very preliminary, so no public patches at the moment. If anyone
> can help, jump in.

I was thinking about this last night, once the kernel is compiling with
cygwin (ie. once the bulk of the work is done) I could probably help out
with merging/rewriting the syscall trapping code from LINE
(http://neomueller.org/~isamu/line/) into UML if nobody else is doing
it.  The actual relevant code is quite small.

I'm a little unsure on the details but I wonder if we could create
something like another binfmt for native x86 Linux executables on the
cygwin/NT port.  Then you could do uber-cool things like have native
cygwin (COFF?) Linux applications running in the same UML as regular x86
Linux apps.  But I guess that also depends on how the native cygwin apps
invoke a syscall.  If they use a int 0x80 like real Linux apps then there
would be no need for the distinction (except perhaps in the loader).
Although I don't think that int 0x80 would be the best method for native
NT apps given a choice.

Just some random thoughts...

Mike

RE: [uml-devel] cygnus-win32 port of User Mode Linux

[Michael V. <mj...@un...>]

On 12/07/2000 07:20:13, Dan Aloni wrote:

> Yesterday was a first attempt to port UML to Micro$oft Windows.
.
<snip snip>
.
> This is very preliminary, so no public patches at the moment. If anyone
> can help, jump in.

I was thinking about this last night, once the kernel is compiling with
cygwin (ie. once the bulk of the work is done) I could probably help out
with merging/rewriting the syscall trapping code from LINE
(http://neomueller.org/~isamu/line/) into UML if nobody else is doing
it.  The actual relevant code is quite small.

I'm a little unsure on the details but I wonder if we could create
something like another binfmt for native x86 Linux executables on the
cygwin/NT port.  Then you could do uber-cool things like have native
cygwin (COFF?) Linux applications running in the same UML as regular x86
Linux apps.  But I guess that also depends on how the native cygwin apps
invoke a syscall.  If they use a int 0x80 like real Linux apps then there
would be no need for the distinction (except perhaps in the loader).
Although I don't think that int 0x80 would be the best method for native
NT apps given a choice.

Just some random thoughts...

Mike

Re: [uml-devel] cygnus-win32 port of User Mode Linux

[Lars B. <lar...@no...>]

Dan Aloni <ka...@ca...> writes:
>  * Incomplete cygwin - Cygwin is incomplete to provide a fully UNIX
>    compatible layer, that means the important functions, like mmap(),

As far as I could tell when I looked at Cygwin, mmap() was supported
when running in Windows NT (and 2000, I guess), but not in Windows 95
(nor 98, again a guess).

>  * gcc, for some reason, decided to complaine about stray '\'s in
>    some places where multi-lined macros where defined. 

Sometimes I have this problem, and it's usually because the line ends
with (in C syntax) "\\\r\n" instead of just "\\\n".  The pre-processor
apparently doesn't recognize the backslash-carriage_return-linefeed
sequence to be a line continuation.  Solution: convert CRLF line
separators to LF.

I don't know if this is the source of your problem.  Could LFs have
been converted to CRLFs when you edited files with a Windows editor?

-- 
http://lars.nocrew.org/

[uml-devel] cygnus-win32 port of User Mode Linux

[Dan A. <ka...@ca...>]

Yesterday was a first attempt to port UML to Micro$oft Windows.

cygnus-win32 is the UNIX compatible environment that I tried to compile
Linux on. (http://www.cygwin.com)

This is what I came across in this attempt:

 * Incomplete cygwin - Cygwin is incomplete to provide a fully UNIX
   compatible layer, that means the important functions, like mmap(),
   fork(), clone(), signal handling functions, are only partially
   supported, which makes it quite difficult to port.
 * binutils - 'as' creates COFF objects files on cygwin, I don't think
   creating ELF objects is possible there. Why is this a problem? Well, we
   COFF doesn't have all the features like ELF does, so linking will be
   more difficult.
 * a buggy ld - ld turns completely insane when trying to link relocatable
   object files. The solution is to link all regular object files in the
   kernel in one strike to create the Microsoft-intimidating LINUX.EXE 
   file ;)   
 * The Win32 API and design - One of the most nasty APIs out there, with
   a quite limited support for POSIX standards.
 * mkdep.c (what makes 'make dep' possible in the kernel), needed patching 
   because mmap() didn't work there.
 * gcc, for some reason, decided to complaine about stray '\'s in
   some places where multi-lined macros where defined. 


So what did we get from this? I've patched around some Makefiles, removed
some ELF dependancies from asm code, and the kernel marvelously started
compiling on my cygwin system...

All the code besides the arch specific (fs/*, net/*, mm/*, kernel/*,
etc) compiles nicely to object files. The only compiliation problem now is
the arch specific code that resides in arch/um/*. 

This is very preliminary, so no public patches at the moment. If anyone
can help, jump in.

-- 
Dan Aloni 
da...@ka...

[uml-devel] more checkins

[Jeff D. <jd...@ka...>]

This cleans up the build so that you don't see multiply defined symbols from 
the network headers.

I also put in support for a new suid network helper which sets up the file 
descriptor to the network as well as setting up the slip device.  This will 
let users of more modern 2.2 systems run the umn device without needing to be 
root.

				Jeff

RE: [uml-devel] RE: [uml-user] [PATCH net-tools] debug improvements

[Mooneer S. <mo...@ea...>]

This modification consists of patches to both the user mode network
utilities and the kernel itself. The kernel patch assumes you've applied
the UML patch already.

Kernel patch:

diff -ur linux.orig/arch/um/drivers/eth_kern.c
linux/arch/um/drivers/eth_kern.c
--- linux.orig/arch/um/drivers/eth_kern.c       Wed Dec  6 02:34:32 2000
+++ linux/arch/um/drivers/eth_kern.c    Tue Dec  5 19:08:07 2000
@@ -10,6 +10,7 @@
 #include <linux/skbuff.h>
 #include <linux/spinlock.h>
 #include <linux/in.h>
+#include <linux/un.h>

 #include "user_util.h"
 #include "eth_net.h"
@@ -51,8 +52,8 @@
 {
        struct net_device *dev = NULL;
        struct uml_net_private *lp;
-       struct sockaddr_in *sin;
-       char *priv;
+       struct sockaddr_un *sin;
+       char *priv, tmp[55];
        int i;

        for (i = 0; i < 4; i++) {
@@ -85,11 +86,16 @@
                                                 15) & ~15);

                memset(lp, 0, sizeof(struct uml_net_private));
-               sin = (struct sockaddr_in *)&lp->addr;
+               sin = (struct sockaddr_un *)&lp->addr;

-               sin->sin_family = AF_INET;
+/*             sin->sin_family = AF_INET;
                sin->sin_port = htons(UML_NET_PORT);
                sin->sin_addr.s_addr = htonl(INADDR_LOOPBACK);
+*/
+               sin->sun_family = AF_UNIX;
+               strcpy(sin->sun_path, "/tmp/tap");
+               sprintf(tmp, "%d", i);
+               strcat(sin->sun_path, tmp);

                dev->priv = lp;
                dev->open = uml_net_open;
diff -ur linux.orig/arch/um/drivers/eth_user.c
linux/arch/um/drivers/eth_user.c
--- linux.orig/arch/um/drivers/eth_user.c       Wed Dec  6 02:34:32 2000
+++ linux/arch/um/drivers/eth_user.c    Tue Dec  5 19:12:18 2000
@@ -41,7 +41,7 @@
        int new_fd;
        int ret;

-       if ((new_fd = socket(PF_INET, SOCK_STREAM, 0)) < 0)
+       if ((new_fd = socket(PF_UNIX, SOCK_STREAM, 0)) < 0)
                return -ENOMEM;

        if (connect(new_fd,(struct sockaddr*)sin,

User mode network utils:

diff -ur um.orig/um_eth_net_util.c um/um_eth_net_util.c
--- um.orig/um_eth_net_util.c   Mon Jul 24 17:42:47 2000
+++ um/um_eth_net_util.c        Tue Dec  5 18:59:43 2000
@@ -8,6 +8,7 @@
 #include <fcntl.h>

 #include <sys/ioctl.h>
+#include <sys/un.h>
 #include <net/if.h>
 #include <net/if_arp.h>
 #include <linux/if_packet.h>
@@ -35,7 +36,7 @@
         FD_SET(y,&perm);

 struct connection_data* uml_connection[1024];
-int debug = 1;
+int debug = 0;

 void dump_packet(unsigned char *buffer,int size,int term) {
   int i;
@@ -54,7 +55,7 @@
   unsigned char *buffer = hbuf + UM_ETH_NET_HDR_SIZE;
   struct connection_data *conn_in;
   struct sockaddr addr;
-  struct sockaddr_in *sin;
+  struct sockaddr_un *sin;
   fd_set perm,temp;
   int type;
   int high_fd = 0;
@@ -70,12 +71,16 @@
   memset(&addr,0,sizeof(struct sockaddr));
   FD_ZERO(&perm);

-  sin = (struct sockaddr_in*)&addr;
-  sin->sin_family = AF_INET;
+  sin = (struct sockaddr_un*)&addr;
+/*  sin->sin_family = AF_INET;
   sin->sin_port = htons(UM_ETH_NET_PORT);
   sin->sin_addr.s_addr = htonl(INADDR_ANY);
+*/

-  if((new_fd = socket(PF_INET,SOCK_STREAM,0))<= 0) {
+  sin->sun_family = AF_UNIX;
+  sprintf(sin->sun_path, "/tmp/%s", argv[1]);
+
+  if((new_fd = socket(PF_UNIX,SOCK_STREAM,0))<= 0) {
     perror("socket");
     exit(errno);
   }

-----Original Message-----
From: Jeff Dike [mailto:jd...@ka...]
Sent: Tuesday, December 05, 2000 9:27 PM
To: Mooneer Salem
Cc: Rodrigo Barbosa (aka morcego);
use...@li...
Subject: Re: [uml-devel] RE: [uml-user] [PATCH net-tools] debug
improvements


mo...@ea... said:
>      TCP    Unix   Difference
> -----------------------------
> Min| 0.8    0.3    0.5
> Max| 29.1   0.3    28.8
> Avg| 110.0  1.8    108.2
> Pak| 6%     0%     0%
> -----------------------------

Nice.  You sold me.  Is your patch ready for public viewing?  I'd like to
reproduce these results here.

				Jeff