Re: libdevstat

[Kenneth D. Merry]

On Fri, Mar 16, 2001 at 08:43:51 -0800, Alfred Perlstein wrote:
> * Sergey A. Osokin <[EMAIL PROTECTED]> [010316 08:27] wrote:
> > On Fri, Mar 16, 2001 at 09:27:30AM -0600, Dan Nelson wrote:
> > > In the last episode (Mar 16), Sergey A. Osokin said:
> > > > Hello, -currenters.
> > > >  
> > > > What do you think about add to libdevstat in/out/other statistics? I
> > > > think transfer great too, but sometimes that's not enough.  iostat
> > > > can't show read and write stats separatly, because compute_stats from
> > > > libdevstat simply sum up all results (in/out/other).
> > > 
> > > Struct devstat already has bytes_read and bytes_written per device, and
> > > the values are filled in (gkrellm seems to be able to get read/written
> > > stats just fine).
> > 
> > gkrellm good tool, but i don't want istall X/gtk/bla-bla-bla
> > on remote server. I want to use some CLI tool for it, like iostat
> > or somethink else.
> > 
> > Another idea?
> 
> I think what he's saying is that libdevstat is OK, it's just that
> the tools that use it sum up the stats instead of displaying them
> inidividually.
> 
> I would look at fixing iostat because libdevstat seems to provide
> all the data needed.

Alfred is correct.  All the data is there in the devstat structures,
you just have to subtract the current stats from the previous stats to get
what you want.

I suppose it would be possible to modify compute_stats() to include the
number of bytes read, written and freed, and the number of read, write,
free and other transactions.  I think that might kinda add to the interface
clutter, though.

This might be better implmented as a separate output mode to iostat(8).

If you (Sergey) write the code, send me the diffs, since I'm the maintainer
for both iostat and the devstat code.

Ken
-- 
Kenneth Merry
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: very strange problem with ps

[Brooks Davis]

On Fri, Mar 16, 2001 at 06:17:37PM -0800, Alex Zepeda wrote:
> On Fri, Mar 16, 2001 at 06:12:29PM -0800, Brooks Davis wrote:
> > I'm seeing a very strange problem with ps.  I was calling "ps -U
> 
> >From what I can tell (I've seen this for a while), calling ps -U username 
> where username has no running processes (or none shown), will return such 
> an error.  ps -U where there are processes to be shown will work fine.  
> *shrug*

Ah, you are correct.  I should have tried that.  What a strange bug.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

 PGP signature

Re: very strange problem with ps

[Alex Zepeda]

On Fri, Mar 16, 2001 at 06:12:29PM -0800, Brooks Davis wrote:
> I'm seeing a very strange problem with ps.  I was calling "ps -U

>From what I can tell (I've seen this for a while), calling ps -U username 
where username has no running processes (or none shown), will return such 
an error.  ps -U where there are processes to be shown will work fine.  
*shrug*

- alex

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

very strange problem with ps

[Brooks Davis]

I'm seeing a very strange problem with ps.  I was calling "ps -U
operator" to check the status of some dumps and it was working fine, but
then I ran it again and got a kinfo_proc size mismatch.  Calling it with
no args still works, but calling it with -U doesn't.  This is with a
current as of this morning.  I'll try a rebuild after this dump
finishes.  You can see what I did in a transcript below.

-- Brooks

[6:11pm] brooks@minya (~): ps -U operator
  PID  TT  STAT  TIME COMMAND
  884  ??  DW 0:00.02 /usr/local/libexec/amanda/sendbackup
  885  ??  RW 0:05.98 /usr/bin/gzip --fast
  886  ??  DW 0:00.29 /usr/local/libexec/amanda/sendbackup
  887  ??  DW 0:00.05 dump 1ushf 1048576 0 - /dev/ad0s2a
  888  ??  ZW 0:00.00  (sh)
  891  ??  DW 0:00.09 dump 1ushf 1048576 0 - /dev/ad0s2a
  892  ??  DW 0:00.14 dump 1ushf 1048576 0 - /dev/ad0s2a
  893  ??  DW 0:00.14 dump 1ushf 1048576 0 - /dev/ad0s2a
  894  ??  DW 0:00.15 dump 1ushf 1048576 0 - /dev/ad0s2a
[6:11pm] brooks@minya (~): ps -U operator
ps: kinfo_proc size mismatch (expected 648, got 268107798)
[6:12pm] brooks@minya (~): ps -U operator
ps: kinfo_proc size mismatch (expected 648, got 268107798)
[6:12pm] brooks@minya (~): ps -U operator
ps: kinfo_proc size mismatch (expected 648, got 268107798)
[6:12pm] brooks@minya (~): ps
  PID  TT  STAT  TIME COMMAND
  567  p0  DWs+   0:00.17 -tcsh (tcsh)
  568  p1  DWs0:00.14 -tcsh (tcsh)
  608  p1  DW+0:00.17 ssh gigan
  569  p2  DWs0:00.14 -tcsh (tcsh)
  604  p2  DW+0:00.36 ssh odin.ac.hmc.edu
  570  p3  DWs0:00.29 -tcsh (tcsh)
  915  p3  RW+0:00.00 ps
  514  v0  DWs0:00.17 -tcsh (tcsh)
  526  v0  DW+0:00.01 /bin/sh /usr/X11R6/bin/startx
  538  v0  DW+0:00.02 xinit /usr/home/brooks/.xinitrc -- -auth /usr/home/br
  544  v0  DW 0:00.01 sh /usr/home/brooks/.xinitrc
  561  v0  DW 0:00.52 Eterm --geometry 80x32+64+64
  562  v0  DW 0:00.23 Eterm --geometry 80x32+560+64
  563  v0  DW 0:00.53 Eterm --geometry 80x34+64-74
  564  v0  DW 0:00.15 Eterm --geometry 80x34+560-74
  566  v0  D  0:01.15 wmaker
  596  v0  DW 0:08.29 wmmon
  597  v0  DW 0:00.87 wmCalClock
  598  v0  RW 0:11.60 wmapm
  599  v0  DW 0:01.04 wmmixer -w
  600  v0  DW 0:02.25 wmnet
  787  v0  DW 0:12.13
/usr/local/lib/netscape-linux/communicator-4.7.bin
  788  v0  DW 0:00.07 (dns helper) (communicator-4.7)
[6:13pm] brooks@minya (~):

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

 PGP signature

Re: "make buildkernel" breakage in sys/modules/if_ef/../../net/if_ef.c??

[Dima Dorfman]

David Wolfskill <[EMAIL PROTECTED]> writes:
> So I'd have thought that the "make buildkernel" process should have been
> using the freshly-made "make" over in /usr/obj -- or am I confused
> (again)?

buildkernel tries to use all the newly-built binaries.  I think make
is an exception, though.  The make that you run (i.e., the one in your
path) is still the old one.  Bug?  Feature?  Who knows.

Dima Dorfman
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: "make buildkernel" breakage in sys/modules/if_ef/../../net/if_ef.c??

[David Wolfskill]

>Date: Fri, 16 Mar 2001 16:22:35 -0800
>From: Dima Dorfman <[EMAIL PROTECTED]>

>David Wolfskill <[EMAIL PROTECTED]> writes:
>> ...
>> ===> if_ef
>> @ -> /usr/src/sys
>> machine -> /usr/src/sys/i386/include
>> echo "#define IPX 1" > opt_ipx.h
>> echo "#define INET 1" > opt_inet.h
>> echo "

>Try building make(1) manually, sticking it in /usr/bin, and using the
>new version to build the kernel.

OK, that worked -- thanks!!

More accurately, since I had done a successful "make buildworld", I
copied /usr/obj/usr/src/usr.bin/make over to /usr/bin/make (after
renaming the latter), and a "make buildkernel" for GENERIC worked.

I'm now building the kernel I really want.  :-)

So I'd have thought that the "make buildkernel" process should have been
using the freshly-made "make" over in /usr/obj -- or am I confused
(again)?

Thanks again,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: "make buildkernel" breakage in sys/modules/if_ef/../../net/if_ef.c??

[Dima Dorfman]

David Wolfskill <[EMAIL PROTECTED]> writes:
> machine -> /usr/src/sys/i386/include
> echo "#define INET 1" > opt_inet.h
> touch opt_inet6.h
> rm -f .depend
> mkdep -f .depend -a   -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/dev -I
> @/../include -I/usr/obj/usr/src/i386/usr/include  /usr/src/sys/modules/if_dis
> c/../../net/if_disc.c
> ===> if_ef
> @ -> /usr/src/sys
> machine -> /usr/src/sys/i386/include
> echo "#define IPX 1" > opt_ipx.h
> echo "#define INET 1" > opt_inet.h
> echo "
> 
> echo "
> 
> echo "
> 
> echo "

Try building make(1) manually, sticking it in /usr/bin, and using the
new version to build the kernel.

Dima Dorfman
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

"make buildkernel" breakage in sys/modules/if_ef/../../net/if_ef.c??

[David Wolfskill]

Since I first saw this, I've CVSupped a couple of times; most recent time
ended at 11:32:39 hrs. PST (8 hrs. west of GMT/UTC) today.

And I blew away /usr/obj completely (just in case anything was left
lying about), and tried it with the GENERIC kernel (vs. my customized
one); I'm not able to get beyond:

machine -> /usr/src/sys/i386/include
echo "#define INET 1" > opt_inet.h
touch opt_inet6.h
rm -f .depend
mkdep -f .depend -a   -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/dev 
-I@/../include -I/usr/obj/usr/src/i386/usr/include  
/usr/src/sys/modules/if_disc/../../net/if_disc.c
===> if_ef
@ -> /usr/src/sys
machine -> /usr/src/sys/i386/include
echo "#define IPX 1" > opt_ipx.h
echo "#define INET 1" > opt_inet.h
echo "

echo "

echo "

echo "

rm -f .depend
mkdep -f .depend -a   -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/dev 
-I@/../include -I/usr/obj/usr/src/i386/usr/include  
/usr/src/sys/modules/if_ef/../../net/if_ef.c
/usr/src/sys/modules/if_ef/../../net/if_ef.c:31: opt_ef.h: No such file or directory
mkdep: compile failed
*** Error code 1

Stop in /usr/src/sys/modules/if_ef.
*** Error code 1

Stop in /usr/src/sys/modules.
*** Error code 1

Stop in /common/obj/C/usr/src/sys/GENERIC.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
m758712358[3] ^Dexit

Script done on Fri Mar 16 15:39:27 2001


The "make buildworld" worked OK.  And here are the non-comment lines
from my /etc/make.conf:

CFLAGS= -O -pipe
INSTALL=install -C
PERL_THREADED=  true
COPTFLAGS= -O -pipe
COMPAT22=   yes
COMPAT3X=   yes
PRINTERDEVICE=  ps
HAVE_MOTIF= yes
USA_RESIDENT=   YES
FORCE_PKG_REGISTER=YES
SUP_UPDATE= yes
SUP=/usr/local/bin/cvsup
SUPFLAGS=   -g -L 2
SUPFILE=/usr/local/etc/4.x-stable-supfile


I was able to build -STABLE (4.3-BETA) -- on a different slice (/S2) --
just fine this morning:

Filesystem  1K-blocks UsedAvail Capacity  Mounted on
/dev/ad0s4a 95263583342930867%/
devfs   110   100%/dev
/dev/ad0s1a 95263397704787245%/S1
/dev/ad0s1e915695   692461   14997982%/S1/usr
/dev/ad0s2a 95263397704787245%/S2
/dev/ad0s2e915727   698177   14429283%/S2/usr
/dev/ad0s4e915727   718513   12395685%/usr
/dev/ad0s4g25406374919   15881932%/var
/dev/ad0s4h  14116697  2619712 1036765020%/common
procfs  440   100%/proc
/dev/md10c 520140   12   478520 0%/tmp


I figure there's something likely obviously silly I'm overlooking, but
I've been banging my head against whatever's handy for a little too
long  :-(

Oh -- one other thing:  there is too a file named opt_ef.h; it's in
/usr/obj/usr/src/sys/${KERNCONF}, and it's empty.  (The /usr/obj that's
on ad0s4e is a symlink to /common/obj/C, in case that's confusing
anyone.  I have 2 -STABLE slices & one -CURRENT that are bootable.)

I would welcome clues.

Thanks,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Mylex eXtremeRAID 2000 timeout/hang

[James FitzGibbon]

We are trying to install a Mylex eXtreme 2000 card with a Dell Powervault 12
drive SCA housing.  The drives in the array are numbered 0-5 and 8-13. The
backplane of the array is id 15.

During the kernel probe, we see the message 

mly0: drive at 03:15 not responding 

five times after the "waiting 15 seconds for SCSI devices to spin up"
message, and then nothing else.  The system doesn't hang, but it never goes
anywhere from there. This is with F/W 6.00-00 and BIOS 6.00-01.

Any ideas ?

-- 
j.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cvs commit: src/sys/i386/isa apic_vector.s icu_vector.s

[David Malone]

I'm still getting panics with a messed up stack in -current.  I've
made some progress on getting useful ktr traces though.

> No, the other handler on that swi is the softclock handler.  This just means
> you are getting clock interrutps from the i8254, which is good. :)  We just
> happen to hang one of the swi's for the sio driver off of the clock software
> interrupt thread.

I found out why the ktr stuff is still logging events even after
the pagefault. It checks if panicstr is set, and stops logging if
it is. Unfortunately trap_fatal doesn't set panicstr and so you
keep getting messages, which fills up the ktr buffer pretty quickly.

> > (Otherwise, I can try to figure out what the ktr output it telling
> > me. Any hints on what I'm looking for?)

> Well, what process was running when it panic'd for example?  Did it resume fro
> a tsleep() or was it an ithread started after preemption?

OK - I got a dump with the ktr stuff turned on and then used
got gdb to print a chunk of message buffer with:

set $a = ktr_idx 
while (--$a >= 0)
print ktr_buf[$a]
end

(I've also recently discovered that if you dump a vmcore onto
a swap partition which is the same size as physical memory then
you trask the forist 8K of the next partition. I'm not sure if this
is restricted to ata or not).

David.


panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x127f
fault code  = supervisor read, page not present
instruction pointer = 0x8:0x127f
stack pointer   = 0x10:0xc86dfe18
frame pointer   = 0x10:0xc86dfe8c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2368 (sh)


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x127f
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc028941c
stack pointer   = 0x10:0xc86dfc84
frame pointer   = 0x10:0xc86dfc88
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2368 (sh)

mi_switch: new proc 0xc8656320 (pid 2368, sh), schedlock 0xc8656320
mi_switch: old proc 0xc78ba520 (pid 20, irq14: ata0), schedlock 0xc78ba520
ithread_loop: pid 20 ih=0xc0dadec0: 0xc013a358(0xc0d9e000) flg=6
ithread_loop: pid 20: (irq14: ata0) need=1
ithread_loop: pid 20: resumed
mi_switch: new proc 0xc78ba520 (pid 20, irq14: ata0), schedlock 0xc78ba520
mi_switch: old proc 0xc8656320 (pid 2368, sh), schedlock 0xc8656320
ithread_schedule: setrunqueue 20
ithread_schedule: pid 20: (irq14: ata0) need = 0
mi_switch: new proc 0xc8656320 (pid 2368, sh), schedlock 0xc8656320
mi_switch: old proc 0xc8655cc0 (pid 2354, make), schedlock 0xc8655cc0
msleep caught: proc 0xc8655cc0 (pid 2354, make), schedlock 0xc8655cc0
msleep: proc 0xc8655cc0 (pid 2354, make), schedlock 0xc8655cc0
msleep resume: proc 0xc8655cc0 (pid 2354, make), schedlock 0xc8655cc0
mi_switch: new proc 0xc8655cc0 (pid 2354, make), schedlock 0xc8655cc0
mi_switch: old proc 0xc8656320 (pid 2368, sh), schedlock 0xc8656320
wakeup: proc 0xc8655cc0 (pid 2354, make), schedlock 0xc8656320
mi_switch: old proc 0xc8655cc0 (pid 2354, make), schedlock 0xc8655cc0
msleep: proc 0xc8655cc0 (pid 2354, make), schedlock 0xc8655cc0
msleep resume: proc 0xc8655cc0 (pid 2354, make), schedlock 0xc8655cc0
mi_switch: new proc 0xc8655cc0 (pid 2354, make), schedlock 0xc8655cc0
wakeup: proc 0xc8655cc0 (pid 2354, make), schedlock 0xc8656320
msleep resume: proc 0xc8656320 (pid 2358, sh), schedlock 0xc8656320
mi_switch: new proc 0xc8656320 (pid 2358, sh), schedlock 0xc8656320
wakeup: proc 0xc8656320 (pid 2358, sh), schedlock 0xc8727a60
msleep resume: proc 0xc8727a60 (pid 2360, make), schedlock 0xc8727a60
mi_switch: new proc 0xc8727a60 (pid 2360, make), schedlock 0xc8727a60
wakeup: proc 0xc8727a60 (pid 2360, make), schedlock 0xc8655ee0
mi_switch: new proc 0xc8655ee0 (pid 2367, rm), schedlock 0xc8655ee0
mi_switch: old proc 0xc8727a60 (pid 2360, make), schedlock 0xc8727a60
msleep caught: proc 0xc8727a60 (pid 2360, make), schedlock 0xc8727a60
msleep: proc 0xc8727a60 (pid 2360, make), schedlock 0xc8727a60
msleep resume: proc 0xc8727a60 (pid 2360, make), schedlock 0xc8727a60
mi_switch: new proc 0xc8727a60 (pid 2360, make), schedlock 0xc8727a60
mi_switch: old proc 0xc78ba520 (pid 20, irq14: ata0), schedlock 0xc78ba520
ithread_loop: pid 20: done
mi_switch: new proc 0xc78ba520 (pid 20, irq14: ata0), schedlock 0xc78ba520
mi_switch: old proc 0xc8655ee0 (pid 2367, rm), schedlock 0xc8655ee0
mi_switch: new proc 0xc8655ee0 (pid 2367, rm), schedlock 0xc8655ee0
mi_switch: old proc 0xc78ba520 (pid 20, irq14: ata0), schedlock 0xc78ba520
ithread_loop: pid 20 ih=0xc0dadec0: 0xc013a358(0xc0d9e000) flg=6
i

Re: Latest version of mega header file POSIX update

[Bruce Evans]

On Thu, 15 Mar 2001, Garrett Wollman wrote:

> The patch has now gotten too large for some e-mail systems, so I'm
> making it available via the Web at
> .

Please include it in the mail anyway so that it is easier to see and
reply if the e-mail system actually works.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cvs commit: src/lib/libc/gen glob.c

[Will Andrews]

On Fri, Mar 16, 2001 at 02:58:31PM -0600, Jonathan Lemon wrote:
> Uh, because this is user space, not kernel space?

Oh yeah, never mind.  =)

-- 
wca

 PGP signature

Re: cvs commit: src/lib/libc/gen glob.c

[Jonathan Lemon]

On Fri, Mar 16, 2001 at 03:58:13PM -0500, Will Andrews wrote:
> On Fri, Mar 16, 2001 at 11:05:20AM -0800, Jonathan Lemon wrote:
> >   Log:
> >   Bump MAX_GLOBENTRIES up to 16384, so it is a power of two.  Add
> >   some comments explaining that this is an arbitrary limit.
> 
> Why shouldn't this be tunable via sysctl?

Uh, because this is user space, not kernel space?
--
Jonathan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cvs commit: src/lib/libc/gen glob.c

[Will Andrews]

On Fri, Mar 16, 2001 at 11:05:20AM -0800, Jonathan Lemon wrote:
>   Log:
>   Bump MAX_GLOBENTRIES up to 16384, so it is a power of two.  Add
>   some comments explaining that this is an arbitrary limit.

Why shouldn't this be tunable via sysctl?

-- 
wca

 PGP signature

gcc-2.95.3 is released. (fwd)

[Dennis Glatting]

FYI



-- Forwarded message --
Date: Fri, 16 Mar 2001 15:52:00 + (GMT)
From: Bernd Schmidt <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: gcc-2.95.3 is released.

gcc version 2.95.3 is now available from

  ftp://gcc.gnu.org/pub/gcc/releases/gcc-2.95.3/

A more detailed announcement can be found on

  http://gcc.gnu.org/gcc-2.95/gcc-2.95.3.html

If you already have test release 5, you do not need to upgrade; there have
been no changes to the code since then.

It's taken a lot longer than everyone had hoped, but at least we can be
reasonably certain that this release is a definite improvement over 2.95.2.
Thanks to everyone who tested the prereleases and sent in the results.

I'd like to ask everyone who works on OS distributions to be a bit more
careful with version numbers.  If you apply patches for your release,
_please_ make sure that your patched version clearly identifies itself,
e.g. as "2.95.3 (debian)", "2.95.3 (OpenBSD)", or whatever.  Please do
not increment the version number, but also do not leave the version string
unchanged.  People have done strange things to gcc-2.95.2, and this has
been a source of problems while doing regression tests for gcc-2.95.3.


Bernd



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: Latest version of mega header file POSIX update

[John Baldwin]

On 16-Mar-01 Garrett Wollman wrote:
> <
> said:
> 
>>  Nothing else jumped out at me while I glanced over it however, and
>> it seems fine at first glance.
> 
> But did you *test* it?  I know it compiles.

No, not yet.  I can try it out on my SMP and alpha testboxes here, though my
the witness_exit panic deadlocks my alpha under heavy load.  :-P

> -GAWollman

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

request for ftp and ftpd testcases.

[gary meyer]

I am doing validation testing on ftp and ftpd in freebsd 4.2 for a
project I am working on and I would like any information
you could help me with regarding known issues and any
testing information such as test methodologies or what
test cases have been used to verify it.

Any information you could provide such as names of people
to contact or web resources would be greatly appreciated.

Gary Meyer
EmergeCore Networks
801-272-3066

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

make buildworld chokes on kdump

[Poul-Henning Kamp]

Is this fixed ?

syv# cd /usr/src/*/kdump
syv# make
cc -O -pipe  -I/syv/src/usr.bin/kdump/../ktrace -I/syv/src/usr.bin/kdump/../..   -c 
ioctl.c
In file included from ioctl.c:96:
/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined
/usr/include/pccard/cardinfo.h:81: warning: this is the location of the previous 
definition
ioctl.c: In function `ioctlname':
ioctl.c:528: sizeof applied to an incomplete type
ioctl.c:798: sizeof applied to an incomplete type
ioctl.c:860: sizeof applied to an incomplete type
ioctl.c:904: sizeof applied to an incomplete type
ioctl.c:1034: sizeof applied to an incomplete type
ioctl.c:1248: sizeof applied to an incomplete type
ioctl.c:1882: syntax error before `;'
*** Error code 1

Stop in /syv/src/usr.bin/kdump.
syv# 

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: libdevstat

[Dan Nelson]

In the last episode (Mar 16), Alfred Perlstein said:
> > > In the last episode (Mar 16), Sergey A. Osokin said:
> > > > What do you think about add to libdevstat in/out/other
> > > > statistics? I think transfer great too, but sometimes that's
> > > > not enough.  iostat can't show read and write stats separatly,
> > > > because compute_stats from libdevstat simply sum up all results
> > > > (in/out/other).
> 
> I think what he's saying is that libdevstat is OK, it's just that the
> tools that use it sum up the stats instead of displaying them
> inidividually.
> 
> I would look at fixing iostat because libdevstat seems to provide all
> the data needed.

Yep, that's what I meant.  If anyone is planning on adding features to
iostat, Solaris has some nice features to copy:

 -x  rotates the output so each drive gets its own line, with the
 following info:
  r/s  w/s  kr/s   kw/s wait actv  svc_t  %w  %b

So "iostat -x n 23 2" prints a full-screen display of the first 23
drives in your system, updated every 2 seconds.

http://www.FreeBSD.org/cgi/man.cgi?query=iostat&manpath=SunOS+5.8

-- 
Dan Nelson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: status of KSE?

[Julian Elischer]

Peter Pentchev wrote:
> 
> On Fri, Mar 16, 2001 at 12:59:24PM +0800, David Xu wrote:
> > Hello Julian,
> >
> > Friday, March 16, 2001, 12:18:15 PM, you wrote:
> >
> > JE> David Xu wrote:
> > >>
> > >>I wonder status of KSE, I am dreaming rewrite our application
> > >> server using kqueue+pthread(KSE), current, we use poll()+pthread
> > >> because pthread does not work with kqueue at present.
> > >>
> > >> --
> > >> Best regards,
> > >> David Xu
> >
> > JE> KSE is not into coding yet.
> > JE> we have a basic design and have soem documents but
> > JE> have been waiting for the SMPng stuff to settle a bit before we
> > JE> hit the kernel with a second huge change.
> >
> > JE> It will not be ready for a long time. do not assume that it
> > JE> will be ready for when you need it becasue it will not.
> >
> > I know KSE is not related to SMP and will run on UP. my primary
> > idea is want to run parellel I/O task in same process with pthread,
> > simply because FreeBSD pthread does not allow me to do multipile
> > I/O tasks at same time on disk file, of course, it is also conflicted
> > with SYSV IPC, so I think of KSE. I don't care about SMP, CPU is
> > enough fast now, I have already seen 1.3G hz CPU, how fast! I think
> > Intel and AMD can very easy to double their CPU clock, hope I can see
> > 3Ghz CPU in next year. I really do think KSE should work before SMP,
> > but it is obvious not. think about Apache 2.0, it is already
> > multi-threaded, FreeBSD pthread will be blocked at disk I/O, it is very
> > bad for Apache 2.0 .
> 
> I believe Julian's SMP-related comments were referring to the fact that
> SMP development has rendered the -current kernel somewhat unstable at
> times (to say the least).  KSE-related work would introduce yet another
> probable path for instabilities, and the developers prefer dealing with
> one huge monster at a time.  There is also the fact that KSE work shall
> most probably touch many places in the kernel that SMP development also
> touches - yet another reason to postpone KSE until SMP is kind-of do

That is it. 
Having said that,
Jason and I have patches that start on the first steps towards KSE.
That is, the breaking up of the present monolithic 'process' structure.
given current slight increases in stablility in -current/SMP
I am currently thiunking about whether these changes can start to be added 
soon.

I will also be looking at updating and expanding the KSE documant that Jason put
out.

> 
> G'luck,
> Peter
> 
> --
> You have, of course, just begun reading the sentence that you have just finished 
>reading.
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message

-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000-2001
---> X_.---._/  
v

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: status of KSE?

[Peter Pentchev]

On Fri, Mar 16, 2001 at 12:59:24PM +0800, David Xu wrote:
> Hello Julian,
> 
> Friday, March 16, 2001, 12:18:15 PM, you wrote:
> 
> JE> David Xu wrote:
> >> 
> >>I wonder status of KSE, I am dreaming rewrite our application
> >> server using kqueue+pthread(KSE), current, we use poll()+pthread
> >> because pthread does not work with kqueue at present.
> >> 
> >> --
> >> Best regards,
> >> David Xu
> 
> JE> KSE is not into coding yet.
> JE> we have a basic design and have soem documents but
> JE> have been waiting for the SMPng stuff to settle a bit before we
> JE> hit the kernel with a second huge change.
> 
> JE> It will not be ready for a long time. do not assume that it
> JE> will be ready for when you need it becasue it will not.
> 
> I know KSE is not related to SMP and will run on UP. my primary
> idea is want to run parellel I/O task in same process with pthread,
> simply because FreeBSD pthread does not allow me to do multipile
> I/O tasks at same time on disk file, of course, it is also conflicted
> with SYSV IPC, so I think of KSE. I don't care about SMP, CPU is
> enough fast now, I have already seen 1.3G hz CPU, how fast! I think
> Intel and AMD can very easy to double their CPU clock, hope I can see
> 3Ghz CPU in next year. I really do think KSE should work before SMP,
> but it is obvious not. think about Apache 2.0, it is already
> multi-threaded, FreeBSD pthread will be blocked at disk I/O, it is very
> bad for Apache 2.0 .

I believe Julian's SMP-related comments were referring to the fact that
SMP development has rendered the -current kernel somewhat unstable at
times (to say the least).  KSE-related work would introduce yet another
probable path for instabilities, and the developers prefer dealing with
one huge monster at a time.  There is also the fact that KSE work shall
most probably touch many places in the kernel that SMP development also
touches - yet another reason to postpone KSE until SMP is kind-of done.

G'luck,
Peter

-- 
You have, of course, just begun reading the sentence that you have just finished 
reading.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: libdevstat

[Sergey A. Osokin]

On Fri, Mar 16, 2001 at 08:43:51AM -0800, Alfred Perlstein wrote:
> * Sergey A. Osokin <[EMAIL PROTECTED]> [010316 08:27] wrote:
> > On Fri, Mar 16, 2001 at 09:27:30AM -0600, Dan Nelson wrote:
> > > In the last episode (Mar 16), Sergey A. Osokin said:
> > > > Hello, -currenters.
> > > >  
> > > > What do you think about add to libdevstat in/out/other statistics? I
> > > > think transfer great too, but sometimes that's not enough.  iostat
> > > > can't show read and write stats separatly, because compute_stats from
> > > > libdevstat simply sum up all results (in/out/other).
> > > 
> > > Struct devstat already has bytes_read and bytes_written per device, and
> > > the values are filled in (gkrellm seems to be able to get read/written
> > > stats just fine).
> > 
> > gkrellm good tool, but i don't want istall X/gtk/bla-bla-bla
> > on remote server. I want to use some CLI tool for it, like iostat
> > or somethink else.
> > 
> > Another idea?
> 
> I think what he's saying is that libdevstat is OK, it's just that
> the tools that use it sum up the stats instead of displaying them
> inidividually.

Yes, libdevstat have data, but iostat display transfer = read+write+other.
But i want to see something like following:

totalreads = current->num_reads - ((previous) ?
   previous->num_reads : 0);
totalwrites = current->num_writes - ((previous) ?
   previous->num_writes : 0);
totalother = current->num_other - ((previous) ?
   previous->num_other : 0);

> I would look at fixing iostat because libdevstat seems to provide
> all the data needed.

OK. Thanks.

-- 

Rgdz,/"\ 
Sergey Osokin aka oZZ,   \ /  ASCII RIBBON CAMPAIGN
[EMAIL PROTECTED]X AGAINST HTML MAIL
http://freebsd.org.ru/~osa/  / \

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: libdevstat

[Alfred Perlstein]

* Sergey A. Osokin <[EMAIL PROTECTED]> [010316 08:27] wrote:
> On Fri, Mar 16, 2001 at 09:27:30AM -0600, Dan Nelson wrote:
> > In the last episode (Mar 16), Sergey A. Osokin said:
> > > Hello, -currenters.
> > >  
> > > What do you think about add to libdevstat in/out/other statistics? I
> > > think transfer great too, but sometimes that's not enough.  iostat
> > > can't show read and write stats separatly, because compute_stats from
> > > libdevstat simply sum up all results (in/out/other).
> > 
> > Struct devstat already has bytes_read and bytes_written per device, and
> > the values are filled in (gkrellm seems to be able to get read/written
> > stats just fine).
> 
> gkrellm good tool, but i don't want istall X/gtk/bla-bla-bla
> on remote server. I want to use some CLI tool for it, like iostat
> or somethink else.
> 
> Another idea?

I think what he's saying is that libdevstat is OK, it's just that
the tools that use it sum up the stats instead of displaying them
inidividually.

I would look at fixing iostat because libdevstat seems to provide
all the data needed.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Ethernet entropy harvesting seriously pessimizes performance

[Maxim Sobolev]

Paul Richards wrote:

> "Matthew N. Dodd" wrote:
> >
> > On Mon, 12 Mar 2001, Mark Murray wrote:
> > > Lots of security minded people what _all_ the interrupt entropy
> > > they can get, and this method gives them that while allowing others
> > > to throttle the harvester back.
> >
> > Lots of -CURRENT users want to be able to use their systems to write code
> > without tripping over /dev/random and friends.
> >
> > I hear lots of people objecting to this code and alot of handwaving in
> > response.
> >
> > Choose reasonable defaults already.
> >
> > The -CURRENT cvs tree isn't the proper venue for doing crypto research.
>
> Well, I dunno about that. It dovetails into the thread in developers
> about getting people to use FreeBSD for research and to my mind I think
> -current probably is a legitimate place for research. As long as the
> basic -current doctrine of not commiting totally non-functional code is
> adhered to there's no reason why experimental code can't be tried out in
> -current.

You are missed point here. Doing research using FreeBSD is not the same as
committing poorly designed and untested code into it, completely replacing
previous satisfactory in the most cases subsystem. Developers usually can
tolerate disturbances when some major redesign occurs, that in the long run
would benefit the whole community (e.g. SMPng), but not the constant problems
with not so important and hardly critical for 95% of users component as random
number generator is.

> If you don't like the problems that research cause you then -current
> isn't what you should be running -- it's an old mantra that isn't
> repeated enough these days.

Most developers just have to use 5-current, because it is their development and
reference platform.

> Of course, I'd much prefer it if -current wasn't totally hosed as much
> as it has been recently but random hasn't caused half the turmoil that
> some other changes have so it's unfair to pick on it as a major problem.

Saying "this is bad, but that was much worse" could not be an excuse for not
doing it properly.


-Maxim


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: libdevstat

[Sergey A. Osokin]

On Fri, Mar 16, 2001 at 09:27:30AM -0600, Dan Nelson wrote:
> In the last episode (Mar 16), Sergey A. Osokin said:
> > Hello, -currenters.
> >  
> > What do you think about add to libdevstat in/out/other statistics? I
> > think transfer great too, but sometimes that's not enough.  iostat
> > can't show read and write stats separatly, because compute_stats from
> > libdevstat simply sum up all results (in/out/other).
> 
> Struct devstat already has bytes_read and bytes_written per device, and
> the values are filled in (gkrellm seems to be able to get read/written
> stats just fine).

gkrellm good tool, but i don't want istall X/gtk/bla-bla-bla
on remote server. I want to use some CLI tool for it, like iostat
or somethink else.

Another idea?

-- 

Rgdz,/"\ 
Sergey Osokin aka oZZ,   \ /  ASCII RIBBON CAMPAIGN
[EMAIL PROTECTED]X AGAINST HTML MAIL
http://freebsd.org.ru/~osa/  / \

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: Latest version of mega header file POSIX update

[Garrett Wollman]

< said:

> I don't think the sys/conf/Makefile.i386 change is needed. :)

Oops.  Sorry, that one leaked out

>  Nothing else jumped out at me while I glanced over it however, and
> it seems fine at first glance.

But did you *test* it?  I know it compiles.

-GAWollman


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Ethernet entropy harvesting seriously pessimizes performance

[Paul Richards]

"Matthew N. Dodd" wrote:
> 
> On Mon, 12 Mar 2001, Mark Murray wrote:
> > Lots of security minded people what _all_ the interrupt entropy
> > they can get, and this method gives them that while allowing others
> > to throttle the harvester back.
> 
> Lots of -CURRENT users want to be able to use their systems to write code
> without tripping over /dev/random and friends.
> 
> I hear lots of people objecting to this code and alot of handwaving in
> response.
> 
> Choose reasonable defaults already.
> 
> The -CURRENT cvs tree isn't the proper venue for doing crypto research.

Well, I dunno about that. It dovetails into the thread in developers
about getting people to use FreeBSD for research and to my mind I think
-current probably is a legitimate place for research. As long as the
basic -current doctrine of not commiting totally non-functional code is
adhered to there's no reason why experimental code can't be tried out in
-current.

If you don't like the problems that research cause you then -current
isn't what you should be running -- it's an old mantra that isn't
repeated enough these days.

Of course, I'd much prefer it if -current wasn't totally hosed as much
as it has been recently but random hasn't caused half the turmoil that
some other changes have so it's unfair to pick on it as a major problem.

I think Peter gets the award for causing most downtime in -current
recently, which is quite a feat given the SMP work taking place :-)

Paul.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: libdevstat

[Dan Nelson]

In the last episode (Mar 16), Sergey A. Osokin said:
> Hello, -currenters.
>  
> What do you think about add to libdevstat in/out/other statistics? I
> think transfer great too, but sometimes that's not enough.  iostat
> can't show read and write stats separatly, because compute_stats from
> libdevstat simply sum up all results (in/out/other).

Struct devstat already has bytes_read and bytes_written per device, and
the values are filled in (gkrellm seems to be able to get read/written
stats just fine).

-- 
Dan Nelson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

libdevstat

[Sergey A. Osokin]

Hello, -currenters.
 
What do you think about add to libdevstat in/out/other
statistics? I think transfer great too, but sometimes that's
not enough.  
iostat can't show read and write stats separatly, because
compute_stats from libdevstat simply sum up all results (in/out/other).
 
-- 

Rgdz,/"\ 
Sergey Osokin aka oZZ,   \ /  ASCII RIBBON CAMPAIGN
[EMAIL PROTECTED]X AGAINST HTML MAIL
http://freebsd.org.ru/~osa/  / \

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sys/ata.h still breaks world

[Soren Schmidt]

It seems Harti Brandt wrote:
> 
> ata.h 1.2 (the latest) has an extra semicolon:
> 
> #define ATAACOUSTIC   _IOWR('a',  7, int);
> 
> and struct ata_sleep is not defined in that file:
> 
> #define ATASLEEP  _IOWR('a',  8, struct ata_sleep)
> 
> This breaks compiling kdump.

ARGH!!!
Thats the price of having so many src tree's *sigh* 

I hope its fixed now...

-Søren

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

sys/ata.h still breaks world

[Harti Brandt]

ata.h 1.2 (the latest) has an extra semicolon:

#define ATAACOUSTIC _IOWR('a',  7, int);

and struct ata_sleep is not defined in that file:

#define ATASLEEP_IOWR('a',  8, struct ata_sleep)

This breaks compiling kdump.

harti


PS: and, yes, I have cvsuped more than once to be sure.
-- 
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
  [EMAIL PROTECTED], [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: nos-tun & multihomed machines

[Ruslan Ermilov]

[-current dropped (Bcc'ed)]

On Fri, Mar 16, 2001 at 12:58:06PM +0100, Jeroen Ruigrok/Asmodai wrote:
> -On [20010316 12:45], Ruslan Ermilov ([EMAIL PROTECTED]) wrote:
> >On Fri, Mar 16, 2001 at 10:50:26AM +0100, Jeroen Ruigrok/Asmodai wrote:
> >> -On [20010316 10:43], Eugene Polovnikov ([EMAIL PROTECTED]) wrote:
> 
> [gif versus nos-tun]
> 
> >Yes, gif(4) works the same way, and multihomed enabled (see gifconfig(8)),
> >with the exception that it always uses the IPPROTO_IPV4 (protocol 4) for
> >encapsulating of IPv4 payload.
> 
> [gif preferred over nos-tun]
> 
> >I fully agree.
> 
> Noted.
> 
> >> Translated, does gif do what nos-tun can do and more?  Yes?  Let's rip
> >> out nos-tun and support the other well maintained solution.
> >> 
> >Except that it does not allow to use proto 94 (the default for nos-tun).
> 
> I'm sure we can work something out with the KAME guys over this, if it
> is necessary to keep this in.  *chalks up another task*
> 
It should be pretty easy to add the ``int gif_pproto'' member to the
gif_softc structure, and expand gif_ioctl() interface to handle smth
like SIOC[SG]IFPPROTO (where PPROTO stands for "physical protocol").


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: nos-tun & multihomed machines

[Jeroen Ruigrok/Asmodai]

-On [20010316 12:45], Ruslan Ermilov ([EMAIL PROTECTED]) wrote:
>On Fri, Mar 16, 2001 at 10:50:26AM +0100, Jeroen Ruigrok/Asmodai wrote:
>> -On [20010316 10:43], Eugene Polovnikov ([EMAIL PROTECTED]) wrote:

[gif versus nos-tun]

>Yes, gif(4) works the same way, and multihomed enabled (see gifconfig(8)),
>with the exception that it always uses the IPPROTO_IPV4 (protocol 4) for
>encapsulating of IPv4 payload.

[gif preferred over nos-tun]

>I fully agree.

Noted.

>> Translated, does gif do what nos-tun can do and more?  Yes?  Let's rip
>> out nos-tun and support the other well maintained solution.
>> 
>Except that it does not allow to use proto 94 (the default for nos-tun).

I'm sure we can work something out with the KAME guys over this, if it
is necessary to keep this in.  *chalks up another task*

-- 
Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
In the dark backward and abysm of time...

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: nos-tun & multihomed machines

[Ruslan Ermilov]

On Fri, Mar 16, 2001 at 10:50:26AM +0100, Jeroen Ruigrok/Asmodai wrote:
> -On [20010316 10:43], Eugene Polovnikov ([EMAIL PROTECTED]) wrote:
> 
Hello, Engene!
Hope you are doing well!  :-)

> >Please, review the following PR: 
> >http://www.freebsd.org/cgi/query-pr.cgi?pr=25847
> >
> >Same patch is in the attach.
> 
> Just a question,
> 
> the gif interface now part of the system does tunneling as well in as
> much the same way as nos-tun does.  Does gif work for the multihomed
> case?  [I'll otherwise when not getting any responses dig up the answer
> myself.]
> 
Yes, gif(4) works the same way, and multihomed enabled (see gifconfig(8)),
with the exception that it always uses the IPPROTO_IPV4 (protocol 4) for
encapsulating of IPv4 payload.

> I ask this because it serves no purpose having an IPv4-only [as far as
> my knowledge goes] tunnel application, whilst we have a more flexible
> new solution present.
> 
I fully agree.

> Translated, does gif do what nos-tun can do and more?  Yes?  Let's rip
> out nos-tun and support the other well maintained solution.
> 
Except that it does not allow to use proto 94 (the default for nos-tun).


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: nos-tun & multihomed machines

[Jeroen Ruigrok/Asmodai]

-On [20010316 10:43], Eugene Polovnikov ([EMAIL PROTECTED]) wrote:
>Please, review the following PR: 
>http://www.freebsd.org/cgi/query-pr.cgi?pr=25847
>
>Same patch is in the attach.

Just a question,

the gif interface now part of the system does tunneling as well in as
much the same way as nos-tun does.  Does gif work for the multihomed
case?  [I'll otherwise when not getting any responses dig up the answer
myself.]
I ask this because it serves no purpose having an IPv4-only [as far as
my knowledge goes] tunnel application, whilst we have a more flexible
new solution present.

Translated, does gif do what nos-tun can do and more?  Yes?  Let's rip
out nos-tun and support the other well maintained solution.

-- 
Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
Don't try to find the Answer where there ain't no Question here...

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

nos-tun & multihomed machines

[Eugene Polovnikov]

hi!

Please, review the following PR: 
http://www.freebsd.org/cgi/query-pr.cgi?pr=25847

Same patch is in the attach.

-- 
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS/CC/IT d-@ s: a- C++ UBSC$ P++>+++@ L- E--- W+ N++ o? K? w>-- O- M- V-
PS@ PE@ Y+ PGP>+ t 5 X R tv- b+++() DI-- D+(++) G>++ e- h--- r y+++
--END GEEK CODE BLOCK--


--- nos-tun.c.orig  Fri Mar 16 11:01:38 2001
+++ nos-tun.c   Fri Mar 16 11:17:35 2001
@@ -239,11 +239,13 @@
   char *point_to = NULL;
   char *to_point = NULL;
   char *target;
+  char *source = NULL;
   char *protocol = NULL;
   int protnum;
 
   struct sockaddr t_laddr;  /* Source address of tunnel */
   struct sockaddr whereto;  /* Destination of tunnel */
+  struct sockaddr wherefrom;/* Source of tunnel */
   struct sockaddr_in *to;
 
   char buf[0x2000]; /* Packets buffer */
@@ -272,7 +274,7 @@
   argc -= optind;
   argv += optind;
 
-  if (argc != 1 || (devname == NULL) ||
+  if ((argc != 1 && argc != 2) || (devname == NULL) ||
   (point_to == NULL) || (to_point == NULL)) {
 usage();
   }
@@ -282,7 +284,11 @@
   else
   protnum = atoi(protocol);
 
-  target = *argv;
+  if (argc == 1) {
+  target = *argv;
+  } else {
+  source = *argv++; target = *argv;
+  }
 
   /* Establish logging through 'syslog' */
   openlog("nos-tun", LOG_PID, LOG_DAEMON);
@@ -306,6 +312,15 @@
 Finish(5);
   }
 
+  if (source) { 
+   if (Set_address(source, (struct sockaddr_in *)&wherefrom))
+ Finish(9);
+if (bind(net, &wherefrom, sizeof(wherefrom)) < 0) {
+ syslog(LOG_ERR, "can't bind source address - %m");
+ Finish(10);
+   }
+  }
+
   if (connect(net,&whereto,sizeof(struct sockaddr_in)) < 0 ) {
 syslog(LOG_ERR,"can't connect to target - %m");
 close(net);
@@ -365,7 +380,7 @@
 usage()
 {
fprintf(stderr,
-"usage: nos-tun -t  -s  -d  -p  
\n");
+"usage: nos-tun -t  -s  -d  -p  
+[] \n");
exit(1);
 }