SOFTUPDATES?

1999-06-04 Thread Tomas TPS Ulej
I add "options SOFTUPDATES" and my kernel won't compile

make depend =>

[snip]
ort.c ../../libkern/random.c  ../../libkern/rindex.c ../../libkern/scanc.c
../../libkern/skpc.c  ../../libkern/strcat.c ../../libkern/strcmp.c
../../libkern/strcpy.c  ../../libkern/strlen.c ../../libkern/strncmp.c
../../libkern/strncpy.c  ../../libkern/udivdi3.c ../../libkern/umoddi3.c
../../pci/ide_pci.c ioconf.c param.c vnode_if.c config.c
cc: ../../ufs/ffs/ffs_softdep.c: No such file or directory

cvsup current ran before recompilation :(

--
Tomas TPS Ulej
System Administrator
t...@internet.sk, tu36-ripe
TELENOR Internet, NETLAB Network, Slovakia



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: SOFTUPDATES?

1999-06-04 Thread Pascal Hofstee
On Fri, 4 Jun 1999, Tomas TPS Ulej wrote:

> I add "options SOFTUPDATES" and my kernel won't compile
[snip]
> cc: ../../ufs/ffs/ffs_softdep.c: No such file or directory

cd /usr/src/sys/ufs/ffs
ln -s /usr/src/contrib/sys/softupdates/ffs_softdep.c ffs_softdep.c
ln -s /usr/src/contrib/sys/softupdates/softdep.h softdep.h


then try to recompile your kernel ;-)


  Pascal Hofstee - dae...@shadowmere.student.utwente.nl

-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS d- s+: a-- C++ UB 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--



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: SOFTUPDATES?

1999-06-04 Thread Jordan K. Hubbard
> I add "options SOFTUPDATES" and my kernel won't compile

Please don't simply turn options on without reading about them first -
that is just foolish.  Had you even bothered to look at LINT *before*
you sent this message, you would have clearly seen the comment:

# Soft updates is technique for improving file system speed and
# making abrupt shutdown less risky.  It is not enabled by default due
# to copyright restraints on the code that implement it.
# 
# Read ../../ufs/ffs/README.softupdates to learn what you need to
# do to enable this.  ../../../contrib/sys/softupdates/README gives
# more details on how they actually work.
#
#optionsSOFTUPDATES

By failing to do even this most basic of steps yourself, you only
waste everyone's time with bogus failure reports.  Don't.

- Jordan


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: SOFTUPDATES?

1999-06-04 Thread Sheldon Hearn


On Fri, 04 Jun 1999 09:45:31 +0200, "Tomas TPS Ulej" wrote:

> I add "options SOFTUPDATES" and my kernel won't compile

Read the section in LINT that dscribes the SOFTUPDATES option.

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



RE: SOFTUPDATES?

1999-06-04 Thread Tomas TPS Ulej
I waste 2 nights with this and be sure I reed manual before :( Sorry after
last review I found one missing symlink:

ln -s /usr/src/contrib/sys/softupdates/softdep.h softdep.h

but idea for checking comes from maillist :) So it was good idea send mail
here I thing.

Regardz

--
Tomas TPS Ulej
System Administrator
t...@internet.sk, tu36-ripe
TELENOR Internet, NETLAB Network, Slovakia


> -Original Message-
> From: Jordan K. Hubbard [mailto:j...@zippy.cdrom.com]
> Sent: Friday, June 04, 1999 9:52 AM
> To: Tomas TPS Ulej
> Cc: curr...@freebsd.org
> Subject: Re: SOFTUPDATES?

> By failing to do even this most basic of steps yourself, you only
> waste everyone's time with bogus failure reports.  Don't.



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: SOFTUPDATES?

1999-06-04 Thread Jordan K. Hubbard
> but idea for checking comes from maillist :) So it was good idea send mail
> here I thing.

No, it was not. :(

If you don't know enough to check LINT when enabling new kernel
features, you honestly should not be running -current and probably
shouldn't even be changing your kernel.  Sorry, but I'm getting more
than a little fed up with people not reading the documentation.

- Jordan


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: SOFTUPDATES?

1999-06-04 Thread George Michaelson


In all fairness, since the SOFTUPDATES comments in LINT point you to
read the README, and this ask you to

(paraphrased)

"edit /etc/rc and disable update"

I suggest that following the guidelines closely will prove challenging :-)

Also, some commentary on the advisability of enabling softupdates on /
for large single-partition configs would be useful: since it demands 
unmounted fs to apply tunefs to the device, this is "challenging" at
first glance.

cheers
-George


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



RE: IRQ sharing with newbus

1999-06-04 Thread Ladavac Marino
> -Original Message-
> From: Garrett Wollman [SMTP:woll...@khavrinen.lcs.mit.edu]
> Sent: Wednesday, June 02, 1999 9:13 PM
> To:   Bruce Evans
> Cc:   d...@nlsystems.com; woll...@khavrinen.lcs.mit.edu;
> curr...@freebsd.org; new...@atdot.dotat.org
> Subject:  Re: IRQ sharing with newbus
> 
> <
> said:
> 
> >> But the sio non-multiport stuff should be able to use RF_TIMESHARE.
> --
> >> If I'm not using my serial port, I should be able to use my
> >> infrared
> 
> > Preemptive timesharing would be hard to implement reasonably for
> irqs.
> > A uniform timeslice would have to be 86 usec to work properly for
> > unbuffered sio devices at 115200 bps.
> 
> You're talking intervals about six orders of magnitude smaller than I
> am.
[ML]  If I understand you correctly, you want to resource track
the IRQ's so if one device that uses one particular IRQ is active,
another one cannot be activated?

Example:
I have a modem on sio1 and digicam on sio3 (both on IRQ3).  I
can either use my modem or download the photos, but not both at the same
time.

That would be nice.  I don't known whether this is already
supported as I don't have sio3 :)  (I don't have sio1 either :)

/Marino

> -GAWollman
> 
> --
> Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all
> the same
> woll...@lcs.mit.edu  | O Siem / The fires of freedom 
> Opinions not those of| Dance in the burning flame
> MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad
> Irschick
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: cdevsw_add

1999-06-04 Thread Poul-Henning Kamp
In message <3757c851.4...@cs.strath.ac.uk>, Roger Hardiman writes:
>Hi there,
>
>Just a quick question.
>I'm about to fix the   cdevsw_add(&bktr_cdevsw);
>bug in the brooktree848.c driver.
>
>Bruce wondered if this should go into bktr_attatch rather
>than bktr_probe?
>
>What do you think?
>I think _attach is better. Otherwise we will call cdevsw_add()
>even if you have the bktr driver in the kernel and have no bt848
>card fitted

Today I don't much care where you put it.  In the future we may
want to think more about it though.

The way I see it is that if the driver is there, it should check
in at cdevsw[], which is why I generally put in *probe().

Of course if the hardware comes 'round later, attach will get
called too.

The next moves on my part are roughly:

1. Remove the difference between cdev/bdev dev_t's.   I have a
kernel running with this now, but there are bogons lurking which
I have fumigated yes.

2. Enable doing "per dev_t" registration in the drivers.  This will
look pretty much like the devfs registration in there today, only
more sane.  After this the cdevsw_add() will only be kind of a
"wildcard" registration method, for pseudo devices and such.

After this point, a typical driver will probably do something like this:

struct softc {
int this;
char that;
bla
bla
bla
};

/* some kind of probe/attach routine */
somefunction() 
{
struct softc *sc;
dev_t dt;

dum
di
dah
/* Aha, hardware! */
sc = MALLOC(...);
bzero(sc, sizeof *sc);
dt = mkdev(
CDEV_MAJOR, /* Char major */
BDEV_MAJOR, /* Block major */
foomble_devices * 16,   /* Minor */
&foomble_cdevsw,/* The cdevsw function vector */
"foomble%d", foomble_devices);  /* printf like construction of 
name */
dt->driver1 = sc;
dt->driver2 = foomble_devices;
foomble_devices++;
}

foomble_open(dev_t dev, ...)
{
struct softc *sc = dev->driver1;
int unit = dev->driver2;


}

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: cdevsw_add

1999-06-04 Thread Nick Hibma

This should definitely go into attach IMNSHO.

Probe: Check whether hardware is there (no side effects if possible).
Attach:Get the device up and running and integrated into the kernel.

With the priority probes this is even more distinct as a priority not
equal to 0 means 'no side effects, just checking'.

Nick.


On Fri, 4 Jun 1999, Poul-Henning Kamp wrote:

 > In message <3757c851.4...@cs.strath.ac.uk>, Roger Hardiman writes:
 > >Hi there,
 > >
 > >Just a quick question.
 > >I'm about to fix the   cdevsw_add(&bktr_cdevsw);
 > >bug in the brooktree848.c driver.
 > >
 > >Bruce wondered if this should go into bktr_attatch rather
 > >than bktr_probe?
 > >
 > >What do you think?
 > >I think _attach is better. Otherwise we will call cdevsw_add()
 > >even if you have the bktr driver in the kernel and have no bt848
 > >card fitted
 > 
 > Today I don't much care where you put it.  In the future we may
 > want to think more about it though.
 > 
 > The way I see it is that if the driver is there, it should check
 > in at cdevsw[], which is why I generally put in *probe().
 > 
 > Of course if the hardware comes 'round later, attach will get
 > called too.
 > 
 > The next moves on my part are roughly:
 > 
 > 1. Remove the difference between cdev/bdev dev_t's.   I have a
 > kernel running with this now, but there are bogons lurking which
 > I have fumigated yes.
 > 
 > 2. Enable doing "per dev_t" registration in the drivers.  This will
 > look pretty much like the devfs registration in there today, only
 > more sane.  After this the cdevsw_add() will only be kind of a
 > "wildcard" registration method, for pseudo devices and such.
 > 
 > After this point, a typical driver will probably do something like this:
 > 
 > struct softc {
 >  int this;
 >  char that;
 >  bla
 >  bla
 >  bla
 > };
 > 
 > /* some kind of probe/attach routine */
 > somefunction() 
 > {
 >  struct softc *sc;
 >  dev_t dt;
 > 
 >  dum
 >  di
 >  dah
 >  /* Aha, hardware! */
 >  sc = MALLOC(...);
 >  bzero(sc, sizeof *sc);
 >  dt = mkdev(
 >  CDEV_MAJOR, /* Char major */
 >  BDEV_MAJOR, /* Block major */
 >  foomble_devices * 16,   /* Minor */
 >  &foomble_cdevsw,/* The cdevsw function vector */
 >  "foomble%d", foomble_devices);  /* printf like construction of 
 > name */
 >  dt->driver1 = sc;
 >  dt->driver2 = foomble_devices;
 >  foomble_devices++;
 > }
 > 
 > foomble_open(dev_t dev, ...)
 > {
 >  struct softc *sc = dev->driver1;
 >  int unit = dev->driver2;
 > 
 >  
 > }
 > 
 > --
 > Poul-Henning Kamp FreeBSD coreteam member
 > p...@freebsd.org   "Real hackers run -current on their laptop."
 > FreeBSD -- It will take a long time before progress goes too far!
 > 
 > 
 > To Unsubscribe: send mail to majord...@freebsd.org
 > with "unsubscribe freebsd-current" in the body of the message
 > 
 > 

-- 
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Pierre Beyssac
On Tue, Jun 01, 1999 at 03:02:47PM -0700, Matthew Dillon wrote:
> I think keepalive's could easily be turned on by default.  At BEST, one
> of the first things I did 5 years ago was to turn them on permanently 
> on all of our machines.

I'd like to disagree on the "by default" part, on the following
assumptions:

1.  If you turn on keepalive by default, you will
have to increase the keepalive timeout value
well over the current 2 hours (at least that's what
most people suggest to alleviate the concerns
about having keepalives on)
2.  Changing this default value of 2 hours will affect
ALL applications. Many of them (and their users)
are more or less expecting a 2 hours value. For
example that's the case for Telnet: probably you
don't want to wait for ONE WEEK before a connection
dies if you are currently using keepalives!

I don't see what this fuss is all about. If for _some_ big servers
there are many dead connections around after a while (*), why don't
THEY use a sysctl at boot-time to change the default state, rather
than impose on the rest of us a change that might not be as innocuous
as it looks?

(*) In theory, for a FTP server, most such connections will be
when the user does a PUT, not a GET. In a GET, the server has
data to push and will timeout anyway. In the case of the control
connection, there's a application timeout in most ftpds who
close the connection after some configurable amount of time.

> This used to be a HUGE argument in the days where networks were less 
> reliable and dialup lines were scarse.  It is not an argument now, 
> however.

Go explain that to my cable provider :-). Keeping a long-lived
connection through them is a real challenge; keepalives on would
make my life even more difficult.

> Whatever we do, we should not start messing around with the internals
> of the kernel trying to 'fix' a non-problem.  Keepalives work just dandy
> as they are currently implemented, we do not have to mess with it beyond
> possibly changing the default in rc.conf.

"possibly", but *only* as a last resort if there are good reasons
for it, IMHO. But I haven't seen any such reason yet.

I also think that having at least a kernel-wide (or better, having
it configurable on a per-socket basis), dynamically configurable
keepalive would be a good thing.
-- 
Pierre Beyssac  p...@enst.fr


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Sheldon Hearn

Hi guys,

Since this isn't something everyone agrees on, how about adding a knob
to the boot time config files? This would make the keep-alive issue more
visible, and encourage folks to think about what they want.

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: cdevsw_add

1999-06-04 Thread Roger Hardiman
Nick Hibma wrote:

> > cdevsw_add()

> This should definitely go into attach IMNSHO.
> 
> Probe: Check whether hardware is there (no side effects if possible).
> Attach:Get the device up and running and integrated into the kernel.
> 
> With the priority probes this is even more distinct as a priority not
> equal to 0 means 'no side effects, just checking'.


I've just fixed the bt848 driver (bktr) where the
cdevsw_add() was accidentally added to the BSDI bktr_probe()
and not the FreeBSD bktr_probe.

Although Bruce and Nick said this really belongs, in the _attatch()
function, I've kept it in the _probe() function for consistency
with all the other drivers.

Roger

-- 
Roger Hardiman| Telepresence Research Group
ro...@cs.strath.ac.uk | DMEM, University of Strathclyde
tel: 0141 548 2897| Glasgow, Scotland, G1 1XJ, UK
fax: 0141 552 0557| http://telepresence.dmem.strath.ac.uk


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: cdevsw_add

1999-06-04 Thread Nick Hibma

 > I've just fixed the bt848 driver (bktr) where the
 > cdevsw_add() was accidentally added to the BSDI bktr_probe()
 > and not the FreeBSD bktr_probe.
 > 
 > Although Bruce and Nick said this really belongs, in the _attatch()
 > function, I've kept it in the _probe() function for consistency
 > with all the other drivers.

Hm, I think this a bad choice. Which are 'all the other drivers'? The
probe should really be as thin as possible to avoid unnecessary delays
when probing in a kernel, like GENERIC, with a lot of device drivers
compiled in.

Nick
-- 
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: cdevsw_add

1999-06-04 Thread Roger Hardiman
Nick 

> Hm, I think this a bad choice. Which are 'all the other drivers'? The
> probe should really be as thin as possible to avoid unnecessary delays
> when probing in a kernel, like GENERIC, with a lot of device drivers
> compiled in.

Well, in the PCI drivers, it is just the meteor, the brooktree848
and the Xilinx PGA driver (xrpu)

In the /sys/i386/isa drivers, there were quite a few.

Bye
Roger
-- 
Roger Hardiman| Telepresence Research Group
ro...@cs.strath.ac.uk | DMEM, University of Strathclyde
tel: 0141 548 2897| Glasgow, Scotland, G1 1XJ, UK
fax: 0141 552 0557| http://telepresence.dmem.strath.ac.uk


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: cdevsw_add

1999-06-04 Thread Bruce Evans
>> Hm, I think this a bad choice. Which are 'all the other drivers'? The
>> probe should really be as thin as possible to avoid unnecessary delays
>> when probing in a kernel, like GENERIC, with a lot of device drivers
>> compiled in.
>
>Well, in the PCI drivers, it is just the meteor, the brooktree848
>and the Xilinx PGA driver (xrpu)
>
>In the /sys/i386/isa drivers, there were quite a few.

The isa drivers provide many bad examples.  Most of them attached the
devsw in a disgusting SYSINIT even if the device is disabled.  I moved
the devsw attach to the device attach function in some drivers that
I worked on.  This was necessary to support pcvt and syscons sharing a
devsw entry.

Bruce


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



What is MTRR all about???

1999-06-04 Thread bush doctor
After reading /sys/boot/README, I decided to sync up my -current boxes.
I began playing around with loader, kld's and the splash screens.  Now I
have a few queries ... #;^)


Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread David Malone
On Fri, Jun 04, 1999 at 03:32:02PM +0200, Pierre Beyssac wrote:

> I don't see what this fuss is all about. If for _some_ big servers
> there are many dead connections around after a while (*), why don't
> THEY use a sysctl at boot-time to change the default state, rather
> than impose on the rest of us a change that might not be as innocuous
> as it looks?

It might be nice to have two keepalive timeouts like Nate suggested.
You'd have a short one, which applies if the application turns on
keepalive or you have alwayskeepalive on. Then you'd have a long
one, which applies to all connections regardless. Then:

1) To get the traditional behavior you set the long one
to infinity and turn alwayskeepalive off.
2) To get the sort of behavior that phk is advocating,
without upsetting the rest of us you leave alwayskeepalive
off and then set the long one to 1 week.
3) For those of us with alwayskeepalive on, we'd get the
traditional value of a few hours.

Would this be a useful or a silly addition?

David.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Poul-Henning Kamp
In message <19990604170654.a8...@salmon.maths.tcd.ie>, David Malone writes:

>It might be nice to have two keepalive timeouts like Nate suggested.
>You'd have a short one, which applies if the application turns on
>keepalive or you have alwayskeepalive on. Then you'd have a long
>one, which applies to all connections regardless. Then:

Then you might as well implement per socket adjustable keepalives.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Matthew Dillon

:On Tue, Jun 01, 1999 at 03:02:47PM -0700, Matthew Dillon wrote:
:> I think keepalive's could easily be turned on by default.  At BEST, one
:> of the first things I did 5 years ago was to turn them on permanently 
:> on all of our machines.
:
:I'd like to disagree on the "by default" part, on the following
:..

Pierre, let me make the suggestion to you that you try turning them
on.  I'll bet you dollars to donoughts that you will not notice
the difference.

-Matt
Matthew Dillon 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Garrett Wollman
< said:

> Pierre, let me make the suggestion to you that you try turning them
> on.  I'll bet you dollars to donoughts that you will not notice
> the difference.

Except when you happen to run into one of the inventors of TCP and he
tells you what an dolt you appear to be...

-GAWollman



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: SOFTUPDATES?

1999-06-04 Thread Dag-Erling Smorgrav
George Michaelson  writes:
> Also, some commentary on the advisability of enabling softupdates on /
> for large single-partition configs would be useful: since it demands 
> unmounted fs to apply tunefs to the device, this is "challenging" at
> first glance.

No. Boot in single-user mode, and type 'tunefs -n enable /' *before*
mounting / read-write. Then proceed into multi-user mode.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread David Malone
> In message <19990604170654.a8...@salmon.maths.tcd.ie>, David Malone writes:
> 
> >It might be nice to have two keepalive timeouts like Nate suggested.
> >You'd have a short one, which applies if the application turns on
> >keepalive or you have alwayskeepalive on. Then you'd have a long
> >one, which applies to all connections regardless. Then:
> 
> Then you might as well implement per socket adjustable keepalives.

While this is probably a good idea anyway, you still have the
problem of setting these timeouts within applications for which you
don't have source and for which the current default isn't useful.
I guess this is the reason we have alwayskeepalive - if all
applications set keepalive when they needed it we wouldn't have
it at all.

If you had per socket adjustable keepalives you'd also have to
provide a tool which could set the keepalive timeout on a running
process to get the sort of effect provided by alwayskeepalive.
Having two timeouts would just be a compromise between these?

David.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



RE: What is MTRR all about???

1999-06-04 Thread Daniel J. O'Connor

On 04-Jun-99 bush doctor wrote:
>   Pentium Pro MTRR support enabled, default memory type is uncacheable
>   
>   What is MTRR?  Using the web based cross referencing tool I came up with

MTRR's are a way to tell the processor how to cache regions of memory. Its
commonly used to speed up video card access by disabling caching on the linear
frame buffer, this makes writes to the card faster (around 0-30%). The penalty
is that reading is slower, but since that doesn't happen very often the speed
increase is good.

Try man memcontrol - It doesn't yet work on SMP boxes though.

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Poul-Henning Kamp
In message <199906041621.maa11...@khavrinen.lcs.mit.edu>, Garrett Wollman 
writes:
>< said:
>
>> Pierre, let me make the suggestion to you that you try turning them
>> on.  I'll bet you dollars to donoughts that you will not notice
>> the difference.
>
>Except when you happen to run into one of the inventors of TCP and he
>tells you what an dolt you appear to be...

Just tell him, (and make sure he can hear the quotes):

"32bit is enought for everthing"

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Matthew Dillon
I think people just like to argue sometimes.  The reality is different.

For all you people complaining:  Just turn them on and I guarentee
you will not even notice the difference, except you will stop getting
( even the occassional ) stale internet server process.  That is what
keepalives were designed to deal with.  Keepalives are not supposed to
be a network watchdog, they are simply supposed to be a catch-all. 
So having per-socket adjustment is kind of silly.

-Matt



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread John R. LoVerso
> "32bit is enought for everthing"

Just mention the horrible header offset field.  Lots of good TCP nits.


Anyway, can't this argument be settled by separating the mechanism and policy. 
Adding a simple rc.conf tweak to enable them should be enough.


But, consider going back to the discusssions leading up to the Host Requirements
RFC (1122).  The particular problem was that the original timeout value for
keepalives was tiny (a few minutes).  1122 dictated the corrections for this. 
Here are the important points from section 4.2.3.6:

1. keepalives MUST default to off
2. the minimum timeout MUST be no less than two minutes
3. keep-alives SHOULD only be invoked in server applications

This mostly says that always_keepalive should continue to default to off (but,
perhaps, a easy hook in rc.conf should exist to turn them on).

John


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Poul-Henning Kamp
In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:

>But, consider going back to the discusssions leading up to the Host 
>Requirements
>RFC (1122).  The particular problem was that the original timeout value for
>keepalives was tiny (a few minutes).  1122 dictated the corrections for this. 
>Here are the important points from section 4.2.3.6:

But RFC 1122 pretty much entirely predates the "modern internet user".  While
I fully supported the policy back then, I no longer do.

I still think the right thing is:

default to keepalives.
set the timeout to a week.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Kevin J. Rowett
At 10:03 AM 6/4/99 , Matthew Dillon wrote:
> I think people just like to argue sometimes.  The reality is different.
>
> For all you people complaining:  Just turn them on and I guarentee
> you will not even notice the difference, except you will stop getting
> ( even the occassional ) stale internet server process.  That is what
> keepalives were designed to deal with.  Keepalives are not supposed to
> be a network watchdog, they are simply supposed to be a catch-all. 

This seems to be rather end-user, and short sighted.  TCP and the underlying
Internet has survived, and been able to scale (among other things), because
of the work of many to balance end-user performance and overall network
performance.

All the TCP congestion avoidance algorithms and work done go towards
managing a shared medium without a central point of control.  If this work
had not been done, then the Internet would not have grown as it did today.

The central issue of keepalives is that, for one machine, they don't create
a significant load.  Multiplied by the number of machines on the Internet,
it can become a problem.

If freeBSD makes it a default, then other will adopt as well.  Some less
experienced and clueful implementors won't do as good a job with the
overall TCP implementation, and we might see keepalives being sent
every TCP timeout, for every connection, as a way to deal with a protocol
error. :-)

KR



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Kurt D. Zeilenga
At 07:56 PM 6/4/99 +0200, Poul-Henning Kamp wrote:
>I still think the right thing is:
>
>   default to keepalives.
>   set the timeout to a week.

OpenLDAP slapd, like may other daemons, relies on timeouts being a
reasonably short (a few hours) to deal with dead streams.  Dead
streams occur for a wide variety of reasons and erver applications
need an effective mechanisms to deal with them.  Changing the
timeout to a week would render the SO_KEEPALIVE mechanism
ineffective.

Personally, I advocate using sysctl (in rc files) to set the
default to on and leaving the kernel alone.

Kurt
  


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread David Greenman
>In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:
>
>>But, consider going back to the discusssions leading up to the Host 
>>Requirements
>>RFC (1122).  The particular problem was that the original timeout value for
>>keepalives was tiny (a few minutes).  1122 dictated the corrections for this. 
>>Here are the important points from section 4.2.3.6:
>
>But RFC 1122 pretty much entirely predates the "modern internet user".  While
>I fully supported the policy back then, I no longer do.
>
>I still think the right thing is:
>
>   default to keepalives.
>   set the timeout to a week.

   I don't support increasing the default timeout. That would cause problems
for a lot of server systems that rely on the relatively short two hour default.
The best I think you could do would be to increase it to something like
12-24 hours as a default, but even that might be problematical.
   Actually, I think we should leave it alone. I don't mind if people add an
rc.conf variable, however.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Poul-Henning Kamp
In message <4.2.0.56.19990604111235.00ae3...@rowett.org>, "Kevin J. Rowett" 
writes:

>The central issue of keepalives is that, for one machine, they don't create
>a significant load.  Multiplied by the number of machines on the Internet,
>it can become a problem.

Reality home-work assignment to Kevin:

If we send a total of 8 keep alive packets per week, for TCP
connections that last that long.  How many FreeBSD hackers
with long lived telnet/ssh sessions does it take to generate
as much trafic as one users IRC session ?

>If freeBSD makes it a default, then other will adopt as well.  Some less
>experienced and clueful implementors won't do as good a job with the
>overall TCP implementation, and we might see keepalives being sent
>every TCP timeout, for every connection, as a way to deal with a protocol
>error. :-)

... And the users, realizing this, will flock to FreeBSD and abandon all
other inferior products.



There we have it!

The way to kill windows NT is to make tcp keepalives the default
in FreeBSD, obviously, since NT is so bloddy unstable, Mickysoft
will have to use much shorter timeouts and people will notice that
NT soaks up all their bandwidth whereas FreeBSD doesn't.

Great!

And I guess we can corner Linux the same way, they have to reboot
for every security fix, so they have to have shorter timeouts as
well.



--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Poul-Henning Kamp
In message <199906041824.laa29...@implode.root.com>, David Greenman writes:
>>In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:
>>
>>>But, consider going back to the discusssions leading up to the Host 
>>>Requirements
>>>RFC (1122).  The particular problem was that the original timeout value for
>>>keepalives was tiny (a few minutes).  1122 dictated the corrections for 
>>>this. 
>>>Here are the important points from section 4.2.3.6:
>>
>>But RFC 1122 pretty much entirely predates the "modern internet user".  While
>>I fully supported the policy back then, I no longer do.
>>
>>I still think the right thing is:
>>
>>  default to keepalives.
>>  set the timeout to a week.
>
>   I don't support increasing the default timeout. That would cause problems
>for a lot of server systems that rely on the relatively short two hour default.
>The best I think you could do would be to increase it to something like
>12-24 hours as a default, but even that might be problematical.
>   Actually, I think we should leave it alone. I don't mind if people add an
>rc.conf variable, however.

First of all, our current default is not two hours, but to kill
after 4 hours idle followed by no response for 20min:

net.inet.tcp.keepidle: 14400
net.inet.tcp.keepintvl: 150

So anyone depending on two hours are screwed already.

How about this then:

net.inet.tcp.always_keepidle: 86400 /* new variable */
net.inet.tcp.always_keepintvl: 64800/* new variable */
net.inet.tcp.keepidle: 14400
net.inet.tcp.keepintvl: 150
net.inet.tcp.always_keepalive: 1

This will have all sockets have keepalives, but if the program
specifically sets keepalives, it gets the shorter timeout.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: sysctl

1999-06-04 Thread Poul-Henning Kamp
In message <99jun4.143622est.40...@border.alcanet.com.au>, Peter Jeremy writes:
>I notice that sysctl -d doesn't work, and I suspect it never did.

right.

My proposal:

In the LINT kernel, the descriptions are compiled into a separate
section and a small program converts this section into the sysctl(8)
man page source (or maybe more correctly but less likely to be
found: mib(8) man page source)

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Nate Williams
> How about this then:
> 
>   net.inet.tcp.always_keepidle: 86400 /* new variable */
>   net.inet.tcp.always_keepintvl: 64800/* new variable */
>   net.inet.tcp.keepidle: 14400
>   net.inet.tcp.keepintvl: 150
>   net.inet.tcp.always_keepalive: 1
> 
> This will have all sockets have keepalives, but if the program
> specifically sets keepalives, it gets the shorter timeout.

That's essentially what I proposed a couple days ago.



Nate


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Garance A Drosihn
At 11:24 AM -0700 6/4/99, David Greenman wrote:
> someone else wrote:
>>
>>  I still think the right thing is:
>>  default to keepalives.
>>  set the timeout to a week.
>
>   I don't support increasing the default timeout. That would cause
> problems for a lot of server systems that rely on the relatively
> short two hour default.  The best I think you could do would be to
> increase it to something like 12-24 hours as a default, but even
> that might be problematical.

This may be a stupid question, but I haven't shied away from asking
stupid questions before...

Do we have to consider this as an "on/off" switch?  Could we have
it an "on/off/extended" switch?  (or is the value stored as a bit
somewhere, so that it can only be on or off?).

What I'm thinking is that anything that explicitly asks for "on"
would get the current 2-hour timeout, but that the "extended"
setting would result in a 7-day timeout.  We'd then set the
system default to "extended" instead of either on or off.

Or would this break things in subtle ways?

---
Garance Alistair Drosehn   =   g...@eclipse.acs.rpi.edu
Senior Systems Programmer  or  dro...@rpi.edu
Rensselaer Polytechnic Institute


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: cdevsw_add

1999-06-04 Thread Julian Elischer


On Sat, 5 Jun 1999, Bruce Evans wrote:
> 
> The isa drivers provide many bad examples.  Most of them attached the
> devsw in a disgusting SYSINIT even if the device is disabled.  I moved
> the devsw attach to the device attach function in some drivers that
> I worked on.  This was necessary to support pcvt and syscons sharing a
> devsw entry.

Firstly, the SYSINIT code was a stopgap. It will evolve with time..  The
question is one of scope.  THe devsw[] entry is added at the same time
that the driver is activated in the kernel. This is neither at the first
probe of a particular device, nor at the attach. Both of the latter cases
an occur many times, both before (for probe) and after teh first hardware
is found. This is why the SYSINIT was used.. The idea was that a loadable
module would have an init() routine that is called when the module is
loaded and linked in. This init() should also be called in an identical
way during boot for a pre-loaded module. basically the case of a preloaded
module (driver) is just a special case of the more general case of a
loadable module.

Drivers are just a special case of the more general case of loadable
modules, so a driver should have all the features of a general module. 
e.g. an init() routine of some sort. It therefore makes sense that if a
driver module has an init() routine that is called once before any other
calls to the driver, tehn this is the obvious place to do things such as
installing hooks for shutdown, or timeouts etc. and for installing itself
into structures such as the devsw[] arrays. It is possible to SIMULATE
this by making the first probe or attach calls do the work, but it seems
to me rather artificial to do so because we have the ideal place to do the
work anyhow. 

Remember that one of the long term aims that nearly all the FreeBSD
developers have expressed at one time or another is to make FreeBSD almost
completely dynamic. This means that nearly all components will eventually
be loadable. Including boot drivers, which can be loaded and linked in by
the boot loader. Making all drivers have the 'form' required, with an
separate init() routine to be called at load time is therefore a positive
thing. SYSINIT is just a way of making sure that these are called early,
so that the driver need not know if it was loaded or was 'preloaded'.

I therefore put it to the group that the right place to do devsw[]
manipulation is neither in xxx-probe, or _attach, but in xxx_init(),
which is only called once, and IS called at teh right time.
It should also be noted that teh devsw[] extraction code should be run
from the init() code when it is run with the 'shutdown' argument. (but
only when the driver arees to allow itself to be unlinked).

julian


> 
> Bruce



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: cdevsw_add

1999-06-04 Thread Doug Rabson
On Sat, 5 Jun 1999, Bruce Evans wrote:

> >> Hm, I think this a bad choice. Which are 'all the other drivers'? The
> >> probe should really be as thin as possible to avoid unnecessary delays
> >> when probing in a kernel, like GENERIC, with a lot of device drivers
> >> compiled in.
> >
> >Well, in the PCI drivers, it is just the meteor, the brooktree848
> >and the Xilinx PGA driver (xrpu)
> >
> >In the /sys/i386/isa drivers, there were quite a few.
> 
> The isa drivers provide many bad examples.  Most of them attached the
> devsw in a disgusting SYSINIT even if the device is disabled.  I moved
> the devsw attach to the device attach function in some drivers that
> I worked on.  This was necessary to support pcvt and syscons sharing a
> devsw entry.

If people feel that its wrong to put the cdev registration in a sysinit,
please feel free to rip out the DEV_DRIVER_MODULE stuff and replace it
with whatever the 'right thing' is.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Jim Shankland
"Kevin J. Rowett"  writes:

> The central issue of keepalives is that, for one machine, they don't
> create a significant load.  Multiplied by the number of machines on
> the Internet, it can become a problem.

No offense, but that is the most ludicrous assertion I've heard since
Slobodan Milosevic claimed that all those bedraggled people streaming
across the Albanian border were actually actors being paid $5.50 per
day by NATO.

Hint: If everybody turned on TCP keepalives, what percentage of the
traffic on Internet backbones do you think would be keepalive
packets?

Jim Shankland
NLynx Systems, Inc.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Matthew Dillon
:Hint: If everybody turned on TCP keepalives, what percentage of the
:traffic on Internet backbones do you think would be keepalive
:packets?
:
:Jim Shankland
:NLynx Systems, Inc.

Around 0.02%, using the stats from one of BEST's busier servers.
That's percent.

In otherwords, nobody would notice.  You wouldn't notice, the backbones
wouldn't notice... nobody would notice.

-Matt
Matthew Dillon 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Matthew Dillon
:had not been done, then the Internet would not have grown as it did today.
:
:The central issue of keepalives is that, for one machine, they don't create
:a significant load.  Multiplied by the number of machines on the Internet,
:it can become a problem.

As I said.  People are arguing about keepalives without knowing how they
work.

NO!  I will repeat that:  NO.  There is NO significant bandwidth.   Every
single machine on the entire internet could turn on keepalives and you
would not notice the difference.

Someone give me a sledgehammer!  No, make that two!

-Matt
Matthew Dillon 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread David Greenman
>>   I don't support increasing the default timeout. That would cause problems
>>for a lot of server systems that rely on the relatively short two hour 
>>default.
>>The best I think you could do would be to increase it to something like
>>12-24 hours as a default, but even that might be problematical.
>>   Actually, I think we should leave it alone. I don't mind if people add an
>>rc.conf variable, however.
>
>First of all, our current default is not two hours, but to kill
>after 4 hours idle followed by no response for 20min:
>
>   net.inet.tcp.keepidle: 14400
>   net.inet.tcp.keepintvl: 150
>
>So anyone depending on two hours are screwed already.

   I believe the above numbers are in slowtimo ticks (500ms), so if you do
the math, you come up with 2 hours.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Matthew Dillon

:
:Around 0.02%, using the stats from one of BEST's busier servers.
:That's percent.

Oops, I wrong.  It's actually less then that... the network counters
overflowed.  More around 0.001%.  That's relative to outgoing traffic,
not relative to network capacity.  And, to be nice, I chose an 
administrative server instead of a web server.

Web servers have even *lower* keepalive bandwidth utilization.

-Matt
Matthew Dillon 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Poul-Henning Kamp
In message <199906042013.naa29...@implode.root.com>, David Greenman writes:
>>>   I don't support increasing the default timeout. That would cause problems
>>>for a lot of server systems that rely on the relatively short two hour 
>>>default.
>>>The best I think you could do would be to increase it to something like
>>>12-24 hours as a default, but even that might be problematical.
>>>   Actually, I think we should leave it alone. I don't mind if people add an
>>>rc.conf variable, however.
>>
>>First of all, our current default is not two hours, but to kill
>>after 4 hours idle followed by no response for 20min:
>>
>>  net.inet.tcp.keepidle: 14400
>>  net.inet.tcp.keepintvl: 150
>>
>>So anyone depending on two hours are screwed already.
>
>   I believe the above numbers are in slowtimo ticks (500ms), so if you do
>the math, you come up with 2 hours.

Oops, you're right.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: cdevsw_add

1999-06-04 Thread Bruce Evans
>> The isa drivers provide many bad examples.  Most of them attached the
>> devsw in a disgusting SYSINIT even if the device is disabled.  I moved
>> the devsw attach to the device attach function in some drivers that
>> I worked on.  This was necessary to support pcvt and syscons sharing a
>> devsw entry.
>
>Firstly, the SYSINIT code was a stopgap. It will evolve with time..  The

Like most stogaps, it was there too long (3.5 years).  It is mostly gone
now.

>...
>I therefore put it to the group that the right place to do devsw[]
>manipulation is neither in xxx-probe, or _attach, but in xxx_init(),
>which is only called once, and IS called at teh right time.
>It should also be noted that teh devsw[] extraction code should be run
>from the init() code when it is run with the 'shutdown' argument. (but
>only when the driver arees to allow itself to be unlinked).

You're forgetting that devsw[] is another stopgap.  The kernel should
probably use something like devfs, where dev_t's only exist for devices
that actually exist.  xxx_init() is far too early to decide which hardware
devices exist.

Bruce


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: cdevsw_add

1999-06-04 Thread Poul-Henning Kamp
In message <199906042048.gaa25...@godzilla.zeta.org.au>, Bruce Evans writes:

>You're forgetting that devsw[] is another stopgap.  The kernel should
>probably use something like devfs, where dev_t's only exist for devices
>that actually exist.  xxx_init() is far too early to decide which hardware
>devices exist.

Patience Bruce, I'm getting closer to that all the time...

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Problems getting 3C597 up

1999-06-04 Thread Bret Ford
   I'm running 4.0 - current from the middle of May, approximately.
I recently acquired an EISA 3COM network adapter that I'm now
trying to install.  Here's a snip from my dmesg output:

vx0: <3Com 3C597-TX Network Adapter> at slot 5 on eisa0
vx0: No I/O space?!
device_probe_and_attach: vx0 attach returned -1

So something is not working... :-(  Anyone have any suggestions?
I'm in a bind.  I need a second ethernet card to get our new DSL
line shared with our various household computers.  

Thanks very much for Any input!

Bret Ford


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Review: Having aio.h include sys/time.h

1999-06-04 Thread Nik Clayton
How do,

-hackers was silent about this, so I'm resending it to -current.  Any 
comments before I commit this (trivial) change?

N

==

docs/11589 says that programs that include aio.h also need to include
sys/time.h.

I've had a chat with Terry Lambert, who wrote the aio_read.2 manual page,
who says



> And here is a section from the aio.h manual page (from the
> Single UNIX Specification):
>
>  Inclusion of the  header may make visible symbols
>  defined in the headers , , 
>  and .
>
> Basically, this means that the aio.h header is *defined* as
> including sys/types.h (because of off_t and size_t), and is
> defined as either including the other headers as well (bad)
> or as forward declaring some types as opaque:



> Since the Single UNIX Specification make no note of a header
> other than aio.h, I'm afraid that the answer is that the aio.h
> must include these headers, or directly define the respective
> types itself.
>
> While I dislike promiscuous headers, I believe it is better to
> be able to compile and run standards compliant UNIX code.

So I want to apply the following very trivial patch;

Index: aio.h
===
RCS file: /home/ncvs/src/sys/sys/aio.h,v
retrieving revision 1.9
diff -u -r1.9 aio.h
--- aio.h   1999/01/17 22:33:08 1.9
+++ aio.h   1999/06/01 17:57:36
@@ -19,6 +19,7 @@
 #ifndef _SYS_AIO_H_
 #define_SYS_AIO_H_
 
+#include 
 #include 
 #include 

Any objections?  I know nothing about the aio* stuff at all, which is 
why I'm checking first.

N 
--
 [intentional self-reference] can be easily accommodated using a blessed,
 non-self-referential dummy head-node whose own object destructor severs
 the links.
-- Tom Christiansen in <37514...@cs.colorado.edu>


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: Problems getting 3C597 up

1999-06-04 Thread Matthew N. Dodd
On Fri, 4 Jun 1999, Bret Ford wrote:
> vx0: <3Com 3C597-TX Network Adapter> at slot 5 on eisa0
> vx0: No I/O space?!
> device_probe_and_attach: vx0 attach returned -1

This was fixed in version 1.45 of sys/i386/eisaconf.c

-- 
| Matthew N. Dodd  | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| win...@jurai.net |  This Space For Rent | ix86,sparc,m68k,pmax,vax  |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage?   |



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Rodney W. Grimes
> In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:
> 
> >But, consider going back to the discusssions leading up to the Host 
> >Requirements
> >RFC (1122).  The particular problem was that the original timeout value for
> >keepalives was tiny (a few minutes).  1122 dictated the corrections for 
> >this. 
> >Here are the important points from section 4.2.3.6:
> 
> But RFC 1122 pretty much entirely predates the "modern internet user".  While
> I fully supported the policy back then, I no longer do.
> 
> I still think the right thing is:
> 
>   default to keepalives.
>   set the timeout to a week.

Then lets go off a write RFC and get RFC1123 off the books, it's way
over due for an overhaul anyway.



-- 
Rod Grimes - KD7CAX - (RWG25)rgri...@gndrsh.dnsmgr.net


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Kevin J. Rowett
At 01:08 PM 6/4/99 , Matthew Dillon wrote:
>:had not been done, then the Internet would not have grown as it did today.
>:
>:The central issue of keepalives is that, for one machine, they don't create
>:a significant load.  Multiplied by the number of machines on the Internet,
>:it can become a problem.
>
> As I said.  People are arguing about keepalives without knowing how they
> work.

That's an excellent point!  People with less correct implementations of TCP
keepalives will use freeBSD's justification as their justification for 
turning on TCP keepalives by default.

RFC1122 was written for a reason.  Before we repeal it, we should consider
why it was written in the first place.

BTW, I'm in favor of making keepalives on by default.  It will save me one
line in the boot up sequence.

KR



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Peter Wemm
Nate Williams wrote:
> > How about this then:
> > 
> > net.inet.tcp.always_keepidle: 86400 /* new variable */
> > net.inet.tcp.always_keepintvl: 64800/* new variable */
> > net.inet.tcp.keepidle: 14400
> > net.inet.tcp.keepintvl: 150
> > net.inet.tcp.always_keepalive: 1
> > 
> > This will have all sockets have keepalives, but if the program
> > specifically sets keepalives, it gets the shorter timeout.
> 
> That's essentially what I proposed a couple days ago.

I think the always_keepintvl values above are pretty over the top..  We
send a grand total of 8 keepalive packets every keepintvl slowtimeouts.
In the SO_KEEPALIVE case, after nothing has been received for 2 hours,
we send a keepalive packet every 75 seconds for a total of 8 times.  If
we still get nothing after 8 * 75 = 10 minutes, we drop the connection.

The example above is a bit far out because after 12 hours we'd probe and
retry every 540 minutes (9 hours) if there was no response for a total
of 8 times - 8 * 9 = 72 hours.  ie: it would take 3 days to clean a dead
connection based on a lousy sample of 8 packets over those 3 days.

I'd suggest always_keepidle = 86400 (12 hours) and always_keepinvl = 300
(20 minutes), and perhaps a new variable keepcnt and always_keepcnt
so that we can retry more than 8 times if you have lossy links.

IMHO, even the more aggressive existing keepalive values are so close to
trivially small amounts of traffic, I'd much rather use the 14400/150 values
for everything.  I'd be really *really* suprised if long idle tcp sessions
were statistically significant.  I know I have telnet sessions that can
have idle times of days, but compared to ftp/http/etc traffic it's a mere
drop in the ocean.  I can't think of any other common case of long idle
open tcp sessions other than telnet and co. 

> Nate
> 

Cheers,
-Peter



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



subtle SIOCGIFCONF bug

1999-06-04 Thread Archie Cobbs
I've noticed that several programs have a subtle problem when scanning
the list returned by the SIOCGIFCONF ioctl. The problem is that these
programs do this computation to increment the pointer in the list:

  ifr = (struct ifreq *) ((char *) &ifr->ifr_addr + ifr->ifr_addr.sa_len);

There are cases where some elements in the list (e.g., tunnel interfaces)
have ifr->ifr_addr.sa_len set to a value LESS than sizeof(ifr->ifr_addr).
This causes these programs to fail because the kernel always enforces a
minimum length of (IFNAMSIZ + sizeof(ifr->ifr_addr)) for each entry in
the list, even if ifr->ifr_addr.sa_len < sizeof(ifr->ifr_addr)
(see net/if.c:ifconf()).

First question:

  Should the kernel insure that ifr->ifr_addr.sa_len is always at
  least sizeof(ifr->ifr_addr), or should the user programs adjust
  their pointer increment algorithm? At first I assumed the latter
  answer (patches below) but now am not so sure.

Second question:

  It doesn't appear the net/if.c:ifioctl() function is protected
  at all by splnet(), even though it is accessing all kinds of
  networking information. Is this a race condition?

Thanks,
-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com

Index: usr.sbin/arp/arp.c
===
RCS file: /home/ncvs/src/usr.sbin/arp/arp.c,v
retrieving revision 1.15
diff -u -r1.15 arp.c
--- arp.c   1999/03/10 10:11:43 1.15
+++ arp.c   1999/06/04 23:45:27
@@ -696,8 +696,8 @@
break;
}
 nextif:
-   ifr = (struct ifreq *) 
-   ((char *)&ifr->ifr_addr + ifr->ifr_addr.sa_len);
+   ifr = (struct ifreq *) ((char *)&ifr->ifr_addr
+   + MAX(ifr->ifr_addr.sa_len, sizeof(ifr->ifr_addr)));
}
 
if (ifr >= ifend) {
@@ -725,8 +725,8 @@
printf("\n");
return dla->sdl_alen;
}
-   ifr = (struct ifreq *) 
-   ((char *)&ifr->ifr_addr + ifr->ifr_addr.sa_len);
+   ifr = (struct ifreq *) ((char *)&ifr->ifr_addr
+   + MAX(ifr->ifr_addr.sa_len, sizeof(ifr->ifr_addr)));
}
return 0;
 }
Index: usr.sbin/pppd/sys-bsd.c
===
RCS file: /home/ncvs/src/usr.sbin/pppd/sys-bsd.c,v
retrieving revision 1.15
diff -u -r1.15 sys-bsd.c
--- sys-bsd.c   1998/06/21 04:47:21 1.15
+++ sys-bsd.c   1999/06/04 23:45:32
@@ -1378,8 +1378,9 @@
  * address on the same subnet as `ipaddr'.
  */
 ifend = (struct ifreq *) (ifc.ifc_buf + ifc.ifc_len);
-for (ifr = ifc.ifc_req; ifr < ifend; ifr = (struct ifreq *)
-   ((char *)&ifr->ifr_addr + ifr->ifr_addr.sa_len)) {
+for (ifr = ifc.ifc_req; ifr < ifend;
+   ifr = (struct ifreq *) ((char *)&ifr->ifr_addr
+   + MAX(ifr->ifr_addr.sa_len, sizeof(ifr->ifr_addr {
if (ifr->ifr_addr.sa_family == AF_INET) {
ina = ((struct sockaddr_in *) &ifr->ifr_addr)->sin_addr.s_addr;
strncpy(ifreq.ifr_name, ifr->ifr_name, sizeof(ifreq.ifr_name));
@@ -1425,7 +1426,8 @@
BCOPY(dla, hwaddr, dla->sdl_len);
return 1;
}
-   ifr = (struct ifreq *) ((char *)&ifr->ifr_addr + ifr->ifr_addr.sa_len);
+   ifr = (struct ifreq *) ((char *)&ifr->ifr_addr
+   + MAX(ifr->ifr_addr.sa_len, sizeof(ifr->ifr_addr)));
 }
 
 return 0;
@@ -1468,8 +1470,9 @@
return mask;
 }
 ifend = (struct ifreq *) (ifc.ifc_buf + ifc.ifc_len);
-for (ifr = ifc.ifc_req; ifr < ifend; ifr = (struct ifreq *)
-   ((char *)&ifr->ifr_addr + ifr->ifr_addr.sa_len)) {
+for (ifr = ifc.ifc_req; ifr < ifend;
+   ifr = (struct ifreq *) ((char *)&ifr->ifr_addr
+   + MAX(ifr->ifr_addr.sa_len, sizeof(ifr->ifr_addr {
/*
 * Check the interface's internet address.
 */
Index: sbin/natd/natd.c
===
RCS file: /home/ncvs/src/sbin/natd/natd.c,v
retrieving revision 1.17
diff -u -r1.17 natd.c
--- natd.c  1999/05/13 17:09:44 1.17
+++ natd.c  1999/06/04 23:54:32
@@ -762,6 +762,8 @@
}
 
extra = ifPtr->ifr_addr.sa_len - sizeof (struct sockaddr);
+   if (extra < 0)
+   extra = 0;
 
ifPtr++;
ifPtr = (struct ifreq*) ((char*) ifPtr + extra);
Index: sbin/route/route.c
===
RCS file: /home/ncvs/src/sbin/route/route.c,v
retrieving revision 1.30
diff -u -r1.30 route.c
--- route.c 1999/06/01 13:14:07 1.30
+++ route.c 1999/06/04 23:54:36
@@ -794,7 +794,8 @@
(ifconf.ifc_buf + ifconf.ifc_len);
  

subtle SIOCGIFCONF bug

1999-06-04 Thread Garrett Wollman
< 
said:

>   Should the kernel insure that ifr->ifr_addr.sa_len is always at
>   least sizeof(ifr->ifr_addr), or should the user programs adjust
>   their pointer increment algorithm? At first I assumed the latter
>   answer (patches below) but now am not so sure.

The user programs should not use SIOCGIFCONF.

>   It doesn't appear the net/if.c:ifioctl() function is protected
>   at all by splnet(), even though it is accessing all kinds of
>   networking information. Is this a race condition?

No.  ifioctl() should only be called from the ioctl syscall or other
contexts where preemption is not an issue.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
woll...@lcs.mit.edu  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: subtle SIOCGIFCONF bug

1999-06-04 Thread Archie Cobbs
Garrett Wollman writes:
> >   Should the kernel insure that ifr->ifr_addr.sa_len is always at
> >   least sizeof(ifr->ifr_addr), or should the user programs adjust
> >   their pointer increment algorithm? At first I assumed the latter
> >   answer (patches below) but now am not so sure.
> 
> The user programs should not use SIOCGIFCONF.

I was hoping for a little more information than that.

OK, imagine a world where you had no choice. THEN what would the answer be?

In other words, I'd like to fix the problem but I don't have time to
rewrite arp, natd, route, etc.

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: subtle SIOCGIFCONF bug

1999-06-04 Thread Garrett Wollman
< 
said:

>> [I wrote:]
>> The user programs should not use SIOCGIFCONF.

> I was hoping for a little more information than that.

> OK, imagine a world where you had no choice. THEN what would the answer be?

1) Implement sysctl net-route-iflist.
2) The user programs should not use SIOCGIFCONF.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
woll...@lcs.mit.edu  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Matthew Dillon

:At 01:08 PM 6/4/99 , Matthew Dillon wrote:
:>:had not been done, then the Internet would not have grown as it did today.
:>:
:>:The central issue of keepalives is that, for one machine, they don't create
:>:a significant load.  Multiplied by the number of machines on the Internet,
:>:it can become a problem.
:>
:> As I said.  People are arguing about keepalives without knowing how they
:> work.
:
:That's an excellent point!  People with less correct implementations of TCP
:keepalives will use freeBSD's justification as their justification for 
:turning on TCP keepalives by default.

Umm... that is about as twisted a reasoning as I could imagine.  I don't
consider it a useful argument.  The sky might be falling too, better not
go outside!

-Matt
Matthew Dillon 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



RE: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread David Schwartz

You know, I was going to buy a pickup truck, but I was afraid my 
neighbors
would figure that if I bought a pickup truck, they should buy one too. And
maybe a pickup truck isn't the right vehicle for them -- perhaps they didn't
even know how to drive one safely. So I bought an Explorer instead.

DS

> :That's an excellent point!  People with less correct
> implementations of TCP
> :keepalives will use freeBSD's justification as their justification for
> :turning on TCP keepalives by default.
>
> Umm... that is about as twisted a reasoning as I could
> imagine.  I don't
> consider it a useful argument.  The sky might be falling too,
> better not
> go outside!
>
>   -Matt
>   Matthew Dillon
>   



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: pccard boot.flp for *plain* 3.2-RELEASE

1999-06-04 Thread Naoki Hamada
Jordan Hubbard  writes:
>1. Put pccardd on the mfsroot floppy and add a few things to
>   sysinstall (this may already be done by his patches, I haven't
>   had time to check) which enable its use during installation.
>
>2. Bring in message catalog and BIG5 support so that the standard
>   installer supports English, Japanese, Korean and Chinese by
>   default.

Definitely cool!

>3. Figure out why I couldn't get the isc-dhcp client to work
>   before 3.2's release (causing me to abandon the idea of adding
>   this feature for 3.2) and get DHCP support into 3.3.

FreeBSD's isc-dhcp client was based on v2.0b1pl18 before May 8. It had
some bugs, which were fatal in many environments. Now it is based on
v2.0b1pl27, which works greatly.

- nao


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Poul-Henning Kamp
In message <199906042217.paa22...@gndrsh.aac.dev.com>, "Rodney W. Grimes" 
writes:
>> In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:
>> 
>> >But, consider going back to the discusssions leading up to the Host 
>> >Requirements
>> >RFC (1122).  The particular problem was that the original timeout value for
>> >keepalives was tiny (a few minutes).  1122 dictated the corrections for 
>> >this. 
>> >Here are the important points from section 4.2.3.6:
>> 
>> But RFC 1122 pretty much entirely predates the "modern internet user".  While
>> I fully supported the policy back then, I no longer do.
>> 
>> I still think the right thing is:
>> 
>>  default to keepalives.
>>  set the timeout to a week.
>
>Then lets go off a write RFC and get RFC1123 off the books, it's way
>over due for an overhaul anyway.
>

I think it has been attempted, but gaining rough concensus on a document
which declares N implementations "junk" is hard to get.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Poul-Henning Kamp

Well, we've heard various opinions and I think we can conclude that:

1.  Even with the current timeouts, there is no significant increase
in network trafic, even with the market share FreeBSD has.

2.  That server applications should have keepalives enabled.

3.  That the few people, for whom it could become a problem if it
is enabled by default, are prefectly capable of changing a
variable in /etc/rc.conf.

4.  It would be desirable to have per socket timeouts, but would
require application changes which are unlikely to happen.

5.  Changing the timeouts would potentially mean trouble for certain
applications.

QED:  The following patch.

If you don't like this, remember to change that variable in
/etc/rc.conf in the future.

Poul-Henning

Index: rc.network
===
RCS file: /home/ncvs/src/etc/rc.network,v
retrieving revision 1.44
diff -u -r1.44 rc.network
--- rc.network  1999/04/12 15:26:41 1.44
+++ rc.network  1999/06/05 05:25:51
@@ -180,6 +180,11 @@
sysctl -w net.inet.ip.accept_sourceroute=1 >/dev/null 2>&1
 fi
 
+if [ "X$tcp_keepalive" = X"YES" ]; then
+   echo -n ' TCP keepalive=YES'
+   sysctl -w net.inet.tcp.always_keepalive=1 >/dev/null 2>&1
+fi
+
 if [ "X$ipxgateway_enable" = X"YES" ]; then
echo -n ' IPX gateway=YES'
sysctl -w net.ipx.ipx.ipxforwarding=1 >/dev/null 2>&1
Index: defaults/rc.conf
===
RCS file: /home/ncvs/src/etc/defaults/rc.conf,v
retrieving revision 1.9
diff -u -r1.9 rc.conf
--- rc.conf 1999/05/16 09:19:44 1.9
+++ rc.conf 1999/06/05 05:26:26
@@ -41,6 +41,7 @@
 natd_flags=""   # Additional flags for natd.
 tcp_extensions="NO"# Set to Yes to turn on RFC1323 extensions.
 log_in_vain="NO"   # Disallow bad connection logging (or YES).
+tcp_keepalive="YES"# Kill dead TCP connections (or NO).
 network_interfaces="lo0"   # List of network interfaces (lo0 is loopback).
 ifconfig_lo0="inet 127.0.0.1"  # default loopback device configuration.
 #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0x" # Sample alias 
entry.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



RE: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread David Schwartz

> Well, we've heard various opinions and I think we can conclude that:
>
> 2.  That server applications should have keepalives enabled.

Well, I certainly don't agree with that. Many server applications (web
servers, mail servers, etcetera) already have data timeouts, which makes
keepalives redundant.

In my opinion, in the vast majority of cases, data timeouts are more
logical than keepalives. 'telnetd' being the most obvious exception.

DS



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



�����������¿���

1999-06-04 Thread gglb
¹ã¸æÁª°î¸üпìµÝ http://www.gglb.com


1¡¢È«ÐÂÍƳö¡°Ãâ·Ñ·ÖÀà¹ã¸æ¡°À¸Ä¿ http://ad.gglb.com Äú¿ÉÒÔÔÚ´Ë·¢²¼ÄúµÄÒ»ÇÐ
ºÏ·¨ÐÅ¡£

2¡¢È«¹úΨһµÄ¡°¹ã¸æÈËÁÄÌìÊÒ¡±³ÏÑûÄúÔÚ´ËÇãÌý¹ã¸æÈ˵ÄÐÄÉù£¬½»Á÷¹ã¸æÈ˵ľ­
Ñé¡£

3¡¢ÔÚ¡°¹ã¸æÂÛ̳¡±£¬Äã¿ÉÒÔÕÒµ½Ò»¸ö¹ã¸æÈËÕæÕý½»Á÷µÄ¿Õ¼ä¡£

4¡¢¹ã¸æÁª°îÊÕ¼ÁËÈ«¹úÖøÃûµÄ¹ã¸æ¹«Ë¾£¬¹ã¸æ²ÄÁϹ«Ë¾£¬¹ã¸æÉ豸¹«Ë¾£¬²éѯ¸ü¿ì
½Ý£¬Ôö¼Ó¸ü·½±ã¡£

5¡¢×îйúÄÚ¹ã¸æÐÂÎÅ£¬¹ã¸æ¶¯Ì¬¡£

6¡¢È«ÐÂÍƳöÆ»¹ûÈí¼þ´óÔùËÍ£º¶àÖÖÉè¼Æ¡¢Í¼ÐÎÈí¼þÎÞÏÞÖƸßËÙÏÂÔØ¡£

7¡¢´óÁ¿¹úÄÚÓÅÐã¹ã¸æͼ¿â£¬½ÔΪȫ¹ú¸÷µØµÄ»§Íâ¹ã¸æͼÐΣ¬Ô­°æÔùËÍ£¬Ï£ÍûÄܸøÄú
´øÀ´Áé¸Ð¡£


À´¹ã¸æÁª°î£¬×öÁª°î¹ã¸æ http://www.gglb.com
¹ã¸æÁª°îÏÂÔØÕ¾µã£º http://download.gglb.com

×îÖØÒªµÄÒ»µã£¬ÄúÔÚ¡°¹ã¸æÁª°î¡±Ëù×öµÄÒ»ÇУ¬¶¼ÊÇÃâ·ÑµÄ¡£



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message



Re: net.inet.tcp.always_keepalive on as default ?

1999-06-04 Thread Peter Wemm
"David Schwartz" wrote:
> 
> > Well, we've heard various opinions and I think we can conclude that:
> >
> > 2.  That server applications should have keepalives enabled.
> 
>   Well, I certainly don't agree with that. Many server applications (web
> servers, mail servers, etcetera) already have data timeouts, which makes
> keepalives redundant.

Huh?  The keepalive option *is* a kind of data timeout..  It's a failsafe
so that if nothing has been heard for a while then it explicitly does
a check to see if the network connection is still valid.  Of course a server
app is free to implement it's own data timeouts, but it shouldn't have
to reinvent what the kernel can do very well already and is very difficult
to do in userland.

There are several sorts of timeouts that server apps *may* want:
- Some sort of upper bound on a session time, eg: a fingerd session may not
last more than 1 hour, regardless of whether it's doing something.  Something
like a http server might put an upper limit of something like 24 hours - if it
is too small and it will interfere with large downloads.
- Some sort of idle timeout, eg: a smtp server may want to time out
after 10 minutes of not recieving a command.
- A way of detecting a stalled or rebooted client.  This is what keepalive 
does.  It lets you detect a lost connection before some other longer timeout
(eg: 24 hours) kicks in.

>   In my opinion, in the vast majority of cases, data timeouts are more
> logical than keepalives. 'telnetd' being the most obvious exception.

Telnetd is the worst example. Just because I have not typed something for
two hours is no indication that the session should be closed.  Only the
kernel can test the validity of the network link in this case.  However, of
I drop a link or reboot, then I do want it cleaned up in a timely fashion.

>   DS

Cheers,
-Peter



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message