User-mode Linux kernel port

wstearns@... said:
> Can we relax the "dev_ip_addr - device not assigned an IP address"
> check to allow an interface to be brought up without an IP address?
> This  is technically quite legal.  When a legal address shows up,
> perhaps the  host scripts could be recalled to actually do the routing
> and proxyarp,  etc.  In fact, perhaps we could hold off trying to call
> out to the host  scripts until a legal address shows up at all.

Yes, that's mostly what is happening anyway.

BTW, this:

	dev_ip_addr - device not assigned an IP address

is just a warning.  The real problem was this:

	Invalid UML IP address - '^B'

and that was just sanity checking and can be moved or deleted.

The real difficulty is that first item, which was setting the MAC using the
internal eth0 IP address.  If there's no IP address when the device is 
configured, it's hard for it to set a decent MAC.  We could require that
if you're going to play arp games before you set an IP, that you specify
the MAC on the command line.  

If RH72 does that by default, then making everyone put a MAC on the command 
line isn't so great, but arping isn't going to do anything anyway.

So, maybe I can just use fd:fe:0:0:0:0 until the interface sees an IP address
and then switch MACs at that point.

				Jeff

Good day, Jeff, all,
	In rh 7.2 they're using ip to initialize devices instead of 
ifconfig.  The old:

ifconfig eth0 192.168.0.144 netmask 255.255.255.0 broadcast 192.168.0.255 up

	run by hand brings the interface up just fine, but the following 
line in the new /etc/sysconfig/network-scripts/ifup (run as "ifup eth0 
boot") gives the following error:

bash-2.05# ip link set eth0 up
+ ip link set eth0 up
SIOCSIFFLAGS: Invalid argument

	and the following kernel log message:

dev_ip_addr - device not assigned an IP address
Invalid UML IP address - '^B'

	Just for reference, the boot scripts in rh72 bring the interface 
up before assigning an address so they can use arping to see if another 
host already has that address.
	Reversing the order (assigning ip first, then bringing up the 
interface) works fine, as follows.

ip addr add 192.168.0.144/32 brd 192.168.0.255 dev eth0
ip link set eth0 up				#host tap comes up here
ip route replace 192.168.0.0/24 dev eth0
ip route add default via 192.168.0.254

	With the exception of the order of the first two lines, the above 
is what ifup is trying to do.
	Can we relax the "dev_ip_addr - device not assigned an IP address" 
check to allow an interface to be brought up without an IP address?  This 
is technically quite legal.  When a legal address shows up, perhaps the 
host scripts could be recalled to actually do the routing and proxyarp, 
etc.  In fact, perhaps we could hold off trying to call out to the host 
scripts until a legal address shows up at all.
	Cheers,
	- Bill

---------------------------------------------------------------------------
        "Klein bottle for rent -- inquire within."
(Courtesy of Brad Johnson <drj@...>)
--------------------------------------------------------------------------
William Stearns (wstearns@...).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:                http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------

sapan@... said:
> Ok. I'll have another go at this one (if you don't mind :) 

Heh, feel free.

> If I'm not wrong,the mail suggested that there should be a buffer that
> every write in the stdio console driver should be directed into, and
> write_room should return the appropriate number of bytes left in the
> buffer. 

From my reading of serial.c, that's right.  The buffer is attached to the
tty as driver_data.

> Also, it suggested a write interrupt to push data out once it
> was passed further. Instead of an interrupt here, IMHO a simple
> wake_up of the process that would've fallen asleep when there was no
> room left to write (in the  ldisc writer) would do... since I guess
> that's what an interrupt handler would get about to doing anyway. 

How are you going to know when to wake the process up?  That's what the 
interrupt handler is for.  Write stuff out until you get -EAGAIN.  When that
happens, you register for a write interrupt on that file descriptor and stuff
the unwritten data in the buffer.

Until the buffer is drained, writing is interrupt-driven.  Stuff data down
the descriptor until it chokes, wait for another interrupt, and repeat.

When the buffer has drained, you can disable that interrupt and resume normal
synchronous writes.

IIRC, this will require a little work in the interrupt handling code to allow
registration for a write interrupt.  You can probably do this by looking at
the existing read interrupt code.  If you want help with that part, let me
know.

				Jeff

// How are you going to know when to wake the process up?  That's what the 
// interrupt handler is for.  Write stuff out until you get -EAGAIN.  When tha
// happens, you register for a write interrupt on that file descriptor and stu
// the unwritten data in the buffer.
// Until the buffer is drained, writing is interrupt-driven.  Stuff data down
// the descriptor until it chokes, wait for another interrupt, and repeat.
// When the buffer has drained, you can disable that interrupt and resume norm
// synchronous writes.
// IIRC, this will require a little work in the interrupt handling code to all
// registration for a write interrupt.  You can probably do this by looking at
// the existing read interrupt code.  If you want help with that part, let me
// know.

Thanks for this! I'll start on the write interrupt method just after this
next clarification-

From my reading of it, the way you've set up the stdio_console driver is 
quite similar to the default
console driver in console.c (i.e, non-bufferred, write room returns a constt
value). The NON-BLOCKING I/O for the whole tty-io write mechanism 
here is implemented in the line discipline
(n_tty.c for example) - which sends a block of data to the console_driver's
writer and simply returns -EAGAIN irrespective of whether it's completed
or not. 

However, the actual writer in the default console driver (console_driver->
do_con_write) in the host kernel BLOCKS write calls...  (i.e., the 
do_con_write function
only returns when the data received has been displayed on the screen). This
block is not too long, since incoming data is already being broken up into
small blocks by do_tty_write in tty_io.c (which I was wrongly duplicating
in my previous patch).

Since this
latency is ultimately encountered anyway in the host kernel, wouldn't it be
superfluous to even try to circumvent it by using the write interrupt 
mechanism?? Which is to say, shouldn't stdio_console->con_write block in
the same way as console_driver->con_write does in the host kernel instead
of providing another "loose layer" with a write interrupt+buffer?

Again, I've tried this patch on my machine (blocking ultimate channel write).
And it works perfectly fine as well...

But then, waiting for your comments :)

-Sapan