Re: Version 2.99.7 is out

[Matti Aarnio <mea@utu.fi>]

Tom Samplonius wrote:
> At 09:14 AM 1/2/95 +0200, Matti Aarnio wrote:
> >	Yes, I did get a report that patching from 2.99.3 to ..6 was not
> >	completely successfull, so I was not sure if it would succeed.
> >	(Basically the code that was moved to  fdstatfs.c  was not removed
> >	 from  smtpserver.c itself for some reason...)
> 
>   Hmm, I better check smtpserver.c, but I didn't have any problems
> compiling except for that seq_remap thing.... is the mmap stuff
> recommended?  I seem to recall a define that resulted in the seq_remap
> function being ifdef'ed out...

	IMO yes.   It is a performance issue, and can be of benefit
	when the routers have to do lots of address lookups from
	ordered files (sort(1) ordered, that is..)

	The  seq_remap() proved to create more syscalls (fstat()s)
	than I had wished for, thus I do recommend of using "-m"
	on the relation definition, and no seq_remap().
	Having the fstat() there triggering the remap got me three
	fstat() calls for one lookup of routes file.  Without the
	seq_remap(), but with "-m" it gets one.
	(Well, fstat() is a lot more light-weight than read() which
	 are plentyfull without the mmap()..)

> >	Are you sure your patch won't break BSDI ?
> >	I was not quite sure, so I didn't introduce it.
> 
>   Pretty sure, BSD4_4 is defined on bsdi (according to what someone on this
> list said) in param.h, so changing the ifdef's around the includes in
> smptserver.c, to BSD4_4 shouldn't be a problem.  And my 4.4BSD Programmer
> Reference says that fstatfs returns a struct with f_bsize and f_bavail
> fields, so the #if define(__linux__) || (defined(BSD4_4) && !defined(bsdi))
> should take care of linux and 4.4bsd systems except for bsdi which gets
> handled later.   (I've attached a patch from 2.99.6)

	Ok, I will include it.

> >	On overall I think the service could use the code used on
> >	GNU fileutils "df", but it calls for complete rewrite of
> >	the configuring mechanism...
> 
>   It seems that every vendor has made their "df" produce a different output
> format.  However, you could borrow the strategy from innwatch (from INN) of
> using a user definable shell script to parse the output of df.

	Naeh, unnecessary context-switches for it.
	Sharing code with GNU-fileutils is better approach :-)

> >	/Matti Aarnio	<mea@utu.fi>
...
> ---
> UNIServe Online
> tom@haven.uniserve.com
> http://www.uniserve.com

	/Matti Aarnio