Re: Future of RAIDFrame

[Tony Finch]

Pawel Jakub Dawidek <[EMAIL PROTECTED]> wrote:
>
>I'm working on one geom class (called for now geom_raid) which will support
>transformations like: concatenation, stripe (raid0), mirror (raid1), raid4
>and raid5.

Isn't is more GEOMish to have a separate GEOM class for each transformation?

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
SHANNON: NORTHWEST BACKING SOUTHWEST 6 TO GALE 8. SHOWERS. MODERATE OR GOOD.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kqueue alternative?

[Tony Finch]

Joshua Oreman <[EMAIL PROTECTED]> wrote:
>On Sun, 15 Jun 2003, Matthew Hagerty wrote:
>>
>> I'm writing a little application that needs to watch a file that another
>> process is writing to, think 'tail -F'.
>
>I would say, use select(2).
>Is there a reason this wouldn't work?

Select doesn't work with files.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
ST DAVIDS HEAD TO COLWYN BAY, INCLUDING ST GEORGES CHANNEL: VARIABLE 2 OR 3
BECOMING MAINLY SOUTHWEST TO WEST 2 OR 3, LOCALLY 3 OR 4. FAIR WITH ISOLATED
SHOWERS AND SOME COASTAL MIST PATCHES. GOOD LOCALLY MODERATE OR POOR. SLIGHT.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD-specific CVS: tagexpand question

[Tony Finch]

Dmitry Morozovsky <[EMAIL PROTECTED]> wrote:
>
>Is there any way to tune FreeBSD-specific CVS (with CVSROOT/options support) to
>provide the following functionality:
>- ident keyword should be standard ($ Id $)
>- it should be expanded as ($ CVSHeader $) to repo-relative path

Why do you want to do that? It seems like a bad idea to me -- you should
keep the semantics of CVS keywords constant, and you should keep per-
project keywords as distinctive as possible to avoid clashes as source
moves around.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
THE WASH TO NORTH FORELAND: NORTHEAST 3 OR 4 OCCASIONALLY 5 VEERING EAST 3 OR
4 LATER. FAIR. GOOD. MODERATE, LOCALLY ROUGH AT FIRST IN NORTH, GRADUALLY
BECOMING SLIGHT TO MODERATE.

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

New version of unifdef(1)

[Tony Finch]

Following a bug spotted by Ian Dowse, I have hacked a bit more on unifdef().
This version has a much more ANSI-like lexical parser which should fix the
zero byte in input problem as well as the handling of files that don't end
with a newline. The bogus string parsing has been killed.

The other main change is that the broken hand-coded #if processing state
machine has been replaced with a table-driven one. I think I have all the
state transitions right, but if people could bang on it a bit that would
be good.

The new code can be obtained from http://dotat.at/prog/misc/unifdef.c

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
MULL OF KINTYRE TO ARDNAMURCHAN POINT: EAST TO SOUTHEAST 5 LOCALLY 6. FAIR.
GOOD. SLIGHT TO MODERATE.

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

Re: jail: multiple ip's

[Tony Finch]

[EMAIL PROTECTED] (Mike Ghunt) wrote:
>  Has anyone hacked the jail code to support more than one ip?
>Would it be wise to hack at the code to add such a feature?

Probably the best way to address this issue is to incorporate the
network stack virtualization patch, then change the jail ID from
an IPv4 address into a network stack ID.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
FISHER GERMAN BIGHT: SOUTHEAST BACKING EAST 5 TO 7, PERHAPS GALE 8 LATER IN
FISHER. RAIN. MODERATE.

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

Re: cvs commit: src/bin/sleep sleep.c

[Tony Finch]

On Wed, Nov 20, 2002 at 06:02:30PM -0800, David Schultz wrote:
> Thus spake Tony Finch <[EMAIL PROTECTED]>:
> > 
> > Most of the BSS is mmapped zero pages that are copy-on-write, so in simple
> > programs they should be mostly shared. See rtld-elf/map_object.c
> 
> Once those pages are written to, the kernel must fault in a fresh
> zero-filled page.  Since the BSS typically holds uninitialized
> data, we can probably assume that the program is going to
> initialize most of it at some point, so there will be very few
> shared BSS pages.

I said "simple" to mean programs that don't use very much of libc
and therefore shouldn't touch very much of libc's bss.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
SELSEY BILL TO LYME REGIS:SOUTH TO SOUTHEAST 6 OR 7 EASING SOUTH TO SOUTHWEST
4 OR 5 FOR A TIME THEN INCREASING SOUTH TO SOUTHWEST 5 OR 6, PERHAPS
OCCASIONALLY 7. RAIN OR SHOWERS, OCCASIONALLY HEAVY. GOOD TO MODERATE. ROUGH.

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

Re: cvs commit: src/bin/sleep sleep.c

[Tony Finch]

David Schultz <[EMAIL PROTECTED]> wrote:
>
>BSS and modified data are not shared, and Matt is only counting
>zero fill and COW faults.

Most of the BSS is mmapped zero pages that are copy-on-write, so in simple
programs they should be mostly shared. See rtld-elf/map_object.c

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
LYME REGIS TO LANDS END INCLUDING THE ISLES OF SCILLY: SOUTHEAST 6 TO GALE 8
LOCALLY SEVERE GALE 9 EASING SOUTH TO SOUTHWEST 4 TO 5 LATER. OCCASIONAL RAIN.
MODERATE TO GOOD. MODERATE TO ROUGH OR VERY ROUGH.

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

Re: malloc

[Tony Finch]

Terry Lambert <[EMAIL PROTECTED]> wrote:
>
>The security comment had to do with the fact that zeroing occurs in
>the kernel in the idle loop, and can account for a large latency in
>the case of a big demand in user space.  It's a philosophy issue that
>led to the implementation, and it has a performance impact that's
>higher in FreeBSD than in Linux, under some usage patterns.

You said that Linux doesn't guarantee to zero pages handed from the
system to userland, which is wrong. You've also mentioned the in-
kernel page-zeroing strategy which is irrelevant when comparing
different userland malloc implementations on the same OS.

Hand-waving about the peanut gallery when I am trying to get you to be 
more specific about your vague assertions is not helpful.

>The context of the current discussion is a FreeBSD admin with Linux
>users bitching at him about core dumps in an overcommit case, where
>he's hitting an administrative limit, and then trying to dereference
>a pointer to a page that has an established mapping, but for which
>there is no page available to act as backing store.

I'm slightly perplexed about this: his program shouldn't have dumped
core when hitting an administrative limit because it was correctly
checking the return value from malloc(), and he's unlikely to be in
an overcommit situation on a machine with 4GB of RAM when allocating
only 800MB especially when it works with the administrative limit
removed. Perhaps the core came from a different version of the program
what didn't check for errors properly.

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
IRISH SEA: NORTHWEST BACKING WEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9.
SQUALLY SHOWERS. GOOD.

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

Re: malloc

[Tony Finch]

On Tue, Oct 22, 2002 at 12:48:03PM -0700, Terry Lambert wrote:
> Tony Finch wrote:
> > 
> > Linux [clears memory in the kernel before handing it over to
> > userland], and you appeared to be saying that it doesn't which
> > is clearly wrong for the security reasons that you stated. It
> > therefore won't affect the relative performance.
> 
> Yes, it will.  It has to do with the use of anonymous memory
> being different between the systems.

The only significant difference I can see is that large callocs
are mmapped by gnu malloc which doesn't then re-clear them, whereas
phk malloc only mmaps its page table (not memory returned to the
user) so calloc always clears memory, which happens to be redundant
if the pages have just come from brk (which isn't always the case).

However calloc isn't relevant to this benchmark.

[If you are talking about a different difference, perhaps you
should say what it is so that this thread doesn't get even more
unnecessarily long.]

> You are arguing that there is nothing that can account for the
> performance difference, when in fact there is a measured
> performance difference.

No, I'm saying that some of what you said is either wrong or
misleading, and the comment about security was especially stupid.

> > PHK malloc uses MAP_ANON on FreeBSD, not /dev/zero -- it uses the
> > latter only if compiled for Solaris.
> 
> And tell me, what does the Linux malloc use?

Exactly the same, and it uses MAP_ANONYMOUS on Linux. It uses mmap for
large allocations whereas phk malloc does not. Since both mmap and
sbrk get zero-filled pages from the kernel this shoudld make little
difference, except in the calloc case explained above.

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
FORTIES CROMARTY: EAST BECOMING CYCLONIC 7 TO SEVERE GALE 9, OCCASIONALLY
STORM 10 LATER. RAIN. MODERATE OR POOR.

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

Re: malloc

[Tony Finch]

On Tue, Oct 22, 2002 at 12:01:19PM -0700, Terry Lambert wrote:
> Tony Finch wrote:
> > Terry Lambert <[EMAIL PROTECTED]> wrote:
> > >The FreeBSD malloc guarantees that the pages are zeroed before being
> > >obtained from the system; this is probably the majority of the cost.
> > >It is a security measure, so that you do not leak data from one process
> > >to another through anonymous pages.
> > >
> > >The Linux malloc does not.
> > 
> > Utter bollocks. FreeBSD malloc can be configured to re-initialize memory
> > on every allocation, but this is designed to assist with buggy programs,
> > it is *not* a security measure. Memory obtained from the kernel on *all*
> > unices (including Linux) is zeroed; that is when security matters, not
> > in malloc. This will not affect the relative performance of phk and gnu
> > malloc.
> 
> *before being obtained from the system*.

Linux does that too, and you appeared to be saying that it doesn't which
is clearly wrong for the security reasons that you stated. It therefore
won't affect the relative performance.

> And I didn't say that.  I only said that the pages were zeroed *before
> being obtained from the system*.  This is what you would expect, with
> anonymous memory accessed off /dev/zero.

PHK malloc uses MAP_ANON on FreeBSD, not /dev/zero -- it uses the
latter only if compiled for Solaris.

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
FAIR ISLE: NORTHEAST BACKING NORTH 5 TO 7 INCREASING 7 TO SEVERE GALE 9,
OCCASIONALLY STORM 10 IN EAST. RAIN. MODERATE OR POOR.

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

Re: malloc

[Tony Finch]

Terry Lambert <[EMAIL PROTECTED]> wrote:
>
>The FreeBSD malloc guarantees that the pages are zeroed before being
>obtained from the system; this is probably the majority of the cost.
>It is a security measure, so that you do not leak data from one process
>to another through anonymous pages.
>
>The Linux malloc does not.

Utter bollocks. FreeBSD malloc can be configured to re-initialize memory
on every allocation, but this is designed to assist with buggy programs,
it is *not* a security measure. Memory obtained from the kernel on *all*
unices (including Linux) is zeroed; that is when security matters, not
in malloc. This will not affect the relative performance of phk and gnu
malloc.

>The FreeBSD malloc references an environment variable and a readlink()
>of a potentially non-existant symbolic link containing configuration
>data for the malloc.

Once at program startup. This is not a significant cost.

>The FreeBSD allocation is an overcommit allocation

True for Linux too, by default.

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
NORTH UTSIRE: EAST 4 OR 5 INCREASING 6 TO GALE 8. RAIN. MODERATE.

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

A problem with restoring from Solaris ufsdumps (fwd)

[Tony Finch]

Can anyone here answer the implied question about recent BSD dump and
restore at the end of Chris's post below?

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
FASTNET: NORTHERLY 4 OR 5 BECOMING VARIABLE 3 THEN SOUTHEASTERLY 4 OR 5.
SHOWERS. GOOD.


--- start of forwarded message ---
From: [EMAIL PROTECTED] (Chris Thompson)
Newsgroups: ucam.comp.unix
Subject: A problem with restoring from Solaris ufsdumps
Date: 18 Oct 2002 13:13:25 GMT
Organization: University of Cambridge, England
Message-ID: 

We came across the following problem with Solaris ufsdump & ufsrestore
a little while ago, and it has been suggested that I post about it here
in case anyone else might be affected.

If an incremental dump includes no files or directories at all, then an
incremental dump taken relative to it will not restore properly with
"ufsrestore r". For example

   A = level 0 dump of /usr on Sunday
   B = level 1 dump of /usr on Monday  (empty, as no files changed)
   C = level 2 dump of /usr on Tuesday (not empty, e.g. patches applied)

Then A restores correctly, and B on top of it, but then an attempt to
restore C on top of that fails with "Incremental volume too low" (code
for "you are attempting to restore dumps in the wrong order"). The
restore of B has failed to update the restoresymtable file correctly.

You are likely to get bitten only for filing systems which are almost
static. A possible circumvention is to use only one level of increment
above 0 for such partitions.

The bug has been reported to Sun, who confirm that they can reproduce
it. No timescale for a fix as yet.

The bug seems to have been in the Solaris programs for a long time. It
is entirely possible that other offspring of the original BSD dump &
restore programs have it as well.

Chris Thompson
Email: [EMAIL PROTECTED]
--- end of forwarded message ---

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

Re: Problem detecting POSIX symbolic constants

[Tony Finch]

On Sat, Oct 12, 2002 at 01:20:03PM -0700, Terry Lambert wrote:
> Tony Finch wrote:
> > 
> > No -- the short-circuiting behaviour of && and || only matters if
> > you can have side-effects, which you can't in the preprocessor,
> > so there is no need to implement it (unifdef doesn't).
> 
> Consider:
> 
> #if _DEFINED_SUPPORTED  && defined(SOMETHING)

That's a syntax error in pre-ANSI preprocessors (unless defined() is
#defined), which won't be bypassed by evaluation shortcutting since
evaluation happens after parsing.

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
SOUTH BISCAY: SOUTHWEST 6 TO GALE 8 VEERING NORTHWEST 5 OR 6. RAIN OR THUNDERY
SHOWERS. MODERATE OR GOOD.

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

Re: Problem detecting POSIX symbolic constants

[Tony Finch]

On Sat, Oct 12, 2002 at 01:44:36AM -0700, Terry Lambert wrote:
> 
> I think the lack of "||" and "&&" mostly had to do with the fact
> that there was conditional evaluation of the RHS of the operator,
> based on the result of the LHS.
> 
> With just an "&" or an "|", you actually need a much less complicated
> state machine to evaluate a constant expression.  With the "||"/"&&",
> you almost have to do an edge associative operation, which implies a
> much more complex state machine for the preprocessor, I think.

No -- the short-circuiting behaviour of && and || only matters if
you can have side-effects, which you can't in the preprocessor,
so there is no need to implement it (unifdef doesn't).

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
THAMES DOVER: SOUTHEASTERLY VEERING NORTHWESTERLY 4 OR 5, OCCASIONALLY 6,
BECOMING VARIABLE 3. RAIN OR SHOWERS. MODERATE OR GOOD.

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

using mtree as tripwire

[Tony Finch]

I've been playing around with using mtree as a lightweight replacement
for tripwire, and it seems to work quite nicely. There are a few bits and
pieces: (1) a patch to make the -X exclude-file facility slightly more
flexible and easy-to-manage; (2) a script for creating the mtree spec
file containing all of the checksums; and (3) an /etc/periodic/security
script to do the mtree checksum comparison with reality.

I've parametrized (3) with a command for obtaining the spec file, for
people who keep it on a remote machine etc. so obviously (2) should have
a corresponding option. I suppose it could get it from periodic.conf
but that's a bit ugly since it isn't a periodic script. Does anyone have
any better ideas?

I'd also like to optionally run (2) as part of the installworld process,
and maybe include it as part of the standard distribution. I'm currently
keeping the file in /var/db/; I'm not sure whether or not that's better
than /etc/mtree/ -- it's over 7MB on my machine which is probably an
important consideration.

The patch to mtree and some of the scripts can be found at
http://people.FreeBSD.org/~fanf/FreeBSD/

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
SOUTH FITZROY: WESTERLY VEERING NORTHWESTERLY 4 OR 5, OCCASIONALLY 6 AT FIRST.
RAIN OR DRIZZLE AT TIMES. GOOD OCCASIONALLY MODERATE.

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

Re: sed -i has difficulty with read-only files

[Tony Finch]

Updated patches. I still prefer the one that's 40 lines shorter :-)

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
SOUTHEAST ICELAND: SOUTHWEST BECOMING VARIABLE 4. FAIR. GOOD.


--- main.c  Mon Jul 29 13:16:44 2002
+++ main.c.two  Mon Jul 29 13:08:49 2002
@@ -413,9 +413,7 @@
char **filename;
 {
struct stat orig;
-   int input, output;
char backup[MAXPATHLEN];
-   char *buffer;
 
if (lstat(*filename, &orig) == -1)
err(1, "lstat");
@@ -425,36 +423,36 @@
}
 
if (*inplace == '\0') {
-   char template[] = "/tmp/sed.XX";
-
-   output = mkstemp(template);
-   if (output == -1)
-   err(1, "mkstemp");
-   strlcpy(backup, template, MAXPATHLEN);
+   /*
+* This is a bit of a hack: we use mkstemp() to avoid the
+* mktemp() link-time warning, although mktemp() would fit in
+* this context much better. We're only interested in getting
+* a name for use in the rename(); there aren't any security
+* issues here that don't already exist in relation to the
+* original file and its directory.
+*/
+   int fd;
+   strlcpy(backup, *filename, sizeof(backup));
+   strlcat(backup, ".XX", sizeof(backup));
+   fd = mkstemp(backup);
+   if (fd == -1)
+   errx(1, "could not create backup of %s", *filename);
+   else
+   close(fd);
} else {
-   strlcpy(backup, *filename, MAXPATHLEN);
-   strlcat(backup, inplace, MAXPATHLEN);
-   output = open(backup, O_WRONLY | O_CREAT | O_TRUNC);
-   if (output == -1)
-   err(1, "open(%s)", backup);
+   strlcpy(backup, *filename, sizeof(backup));
+   strlcat(backup, inplace, sizeof(backup));
}
 
-   input = open(*filename, O_RDONLY);
-   if (input == -1)
-   err(1, "open(%s)", *filename);
-   if (fchmod(output, orig.st_mode & ~S_IFMT) == -1)
-   err(1, "chmod");
-   buffer = (char *)mmap(0, orig.st_size, PROT_READ, MAP_SHARED, input, 0);
-   if (buffer == MAP_FAILED)
-   err(1, "mmap(%s)", *filename);
-   if (write(output, buffer, orig.st_size) == -1)
-   err(1, "write(%s)", backup);
-   if (munmap(buffer, orig.st_size) == -1)
-   err(1, "munmap(%s)", *filename);
-   close(input);
-   close(output);
-   freopen(*filename, "w", stdout);
+   if (rename(*filename, backup) == -1)
+   err(1, "rename(\"%s\", \"%s\")", *filename, backup);
+   if (freopen(*filename, "w", stdout) == NULL)
+   err(1, "open(\"%s\")", *filename);
+   if (fchmod(fileno(stdout), orig.st_mode) == -1)
+   err(1, "chmod(\"%s\")", *filename);
*filename = strdup(backup);
+   if (*filename == NULL)
+   err(1, "malloc");
return 0;
 }
 


--- main.c  Mon Jul 29 13:16:44 2002
+++ main.c.one  Mon Jul 29 13:15:03 2002
@@ -68,6 +68,11 @@
 #include "extern.h"
 
 /*
+ * Maximum amount of data to mmap at a time when copying a file.
+ */
+#define MMAP_MAX (16*1024*1024)
+
+/*
  * Linked list of units (strings and files) to be compiled
  */
 struct s_compunit {
@@ -407,6 +412,8 @@
 
 /*
  * Modify a pointer to a filename for inplace editing and reopen stdout
+ *
+ * We remove the files before opening them in case of permissions problems
  */
 static int
 inplace_edit(filename)
@@ -416,6 +423,7 @@
int input, output;
char backup[MAXPATHLEN];
char *buffer;
+   off_t off, size;
 
if (lstat(*filename, &orig) == -1)
err(1, "lstat");
@@ -424,37 +432,57 @@
return -1;
}
 
+   /* create and open the backup file */
if (*inplace == '\0') {
-   char template[] = "/tmp/sed.XX";
+   const char *tmp;
 
-   output = mkstemp(template);
+   tmp = getenv("TMPDIR");
+   if (tmp == NULL)
+   tmp = "/tmp";
+   strlcpy(backup, tmp, sizeof(backup));
+   strlcat(backup, "/sed.XX", sizeof(backup));
+   output = mkstemp(backup);
if (output == -1)
err(1, "mkstemp");
-   strlcpy(backup, template, MAXPATHLEN);
+   if (fchmod(output, orig.st_mode & ~S_IFMT) == -1)
+   err(1, "chmod(\"%s\")", backup);
} else {
-   strlcpy(backup, *filename, MAXPATHLEN);
-   strlcat(backup, inplace, MAXPATHLEN);
-   output = open(backup, O_WRONLY | O_CREAT | O_TRUNC);
+   strlcpy(backup, *filename, sizeof(backup));
+   strlcat(backup, inplace, s

Re: sed -i has difficulty with read-only files

[Tony Finch]

On Sat, Jul 27, 2002 at 07:12:24AM +0200, Cyrille Lefevre wrote:
> 
> IMHO, both the old and the newer code are wrong. they should use
> getenv("TMPDIR") if any and certainly not the current directory.
> there is probably more room in ${TMPDIR:-/var/tmp} then in the
> current directory. imagine that the current fs is nearly full...

I'm disinclined to use a file in $TMPDIR or in /tmp because of the
bad effect it has on the complexity of the code, and I think that
if you are running out of disk space then you deserve to lose.
Though I'm open to other opinions.

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
FAIR ISLE: EAST 4, BACKING NORTHEAST 5 OR 6 OCCASIONALLY 7. RAIN. GOOD
BECOMING MODERATE OCCASIONALLY POOR.

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

Re: improved unifdef(1)

[Tony Finch]

On Fri, Apr 26, 2002 at 03:22:50PM +0100, Tony Finch wrote:
> 
> It's available from <http://dotat.at/prog/misc/unifdef.c>.

There's now a manual page too, <http://dotat.at/prog/misc/unifdef.1>.

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
BISCAY: NORTHWESTERLY BACKING SOUTHWESTERLY 5 TO 7, BECOMING VARIABLE 3 OR 4
IN SOUTH. SHOWERS. GOOD.

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

improved unifdef(1)

[Tony Finch]

The unifdef in the system is not suited to heavyweight tasks like
(say) xterm's main.c or wu-ftpd for a number of reasons:

 * it has a very low limit on the number of command-line arguments
   that it can cope with (100) -- I've sumbitted PR#37454 about this.

 * it doesn't have the slightest clue about #elif

 * it doesn't attempt to handle #if

Because I needed an unifdef with a bit more oomph and couldn't
find a better one, I have done my own tune-up job on the BSD
one, starting from the NetBSD sources (which seemed to have
a mostly-superset of the changes made by the other BSDs).
It's available from .
The detailed change list is below. Note that only a very
limited subset of #if expressions are understood, involving
just defined(), !, &&, ||, and brackets.

If anyone is interested I'd appreciate some testing, and it
would be nice to get it committed eventually.

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
NORTH UTSIRE SOUTH UTSIRE: SOUTHEASTERLY VEERING WESTERLY 6 OR 7, OCCASIONALLY
GALE 8 IN NORTH UTSIRE. RAIN THEN SHOWERS. MODERATE BECOMING GOOD.


2002/04/25 14:50:23 fanf
import from NetBSD

2002/04/25 14:52:54 fanf
revert to the CSRG copyright/sccs rubric and add $dotat$

2002/04/25 14:55:27 fanf
remove __P

2002/04/25 14:57:56 fanf
remove BSS cruft

2002/04/25 14:59:59 fanf
allow a reasonable number of symbols

2002/04/25 15:02:48 fanf
move #endif comments to a better place

2002/04/25 15:31:28 fanf
deal with -Dsym=value

2002/04/25 15:37:25 fanf
sensible else if formatting

2002/04/25 15:51:42 fanf
another formatting improvement

2002/04/25 16:03:16 fanf
use err()

2002/04/25 16:04:55 fanf
style: #include ordering; variable alignment

2002/04/25 16:05:30 fanf
remove spurious fflush()

2002/04/25 16:11:54 fanf
add a function that will evaluate if expressions

2002/04/25 16:12:23 fanf
fix location of a {

2002/04/25 16:16:26 fanf
allow whitespace before #

2002/04/25 18:10:00 fanf
Initial version of #if handling.
Symbol 0 is used for tracking the state of #if/#else activity.
TODO: #elif, nested #if

2002/04/25 18:15:23 fanf
use __RCSID for the sccs id and remove redundant #ifndef lint lines

2002/04/25 18:17:09 fanf
Restore the requirement that at least one -D or -U must be present on the
command line, which was broken when #if handling was added.

2002/04/25 18:45:54 fanf
purge LT_OTHER since it's a synonym for LT_IF

2002/04/25 19:59:46 fanf
Simplify doif()'s inif argument to just a boolean, since the IN_ELSE
value isn't very different from IN_IF, and the idea doesn't work well
with #elif.

2002/04/25 20:20:05 fanf
Move the gall to getlin() up to doif() so that it will be able to
examine the same line more than once.

2002/04/25 20:24:16 fanf
Remove the inif argument to doif() entirely, since inif == (depth != 0).

2002/04/25 21:19:55 fanf
remove an unnecessary variable inside doif()

2002/04/25 21:43:07 fanf
Change the "unknown symbol" return value from findsym() from -1 to 0.

2002/04/25 21:44:51 fanf
fix a comment to reflect the previous change

2002/04/25 23:02:51 fanf
simplify error handling

2002/04/25 23:25:31 fanf
simplify error line number handling

2002/04/25 23:27:40 fanf
remove redundant stline variable

2002/04/25 23:46:55 fanf
partial implementation of #elif and properly nesting #ifs.

2002/04/26 13:51:41 fanf
Finish implementation of #elif and nesting.
This version passes some initial tests.

2002/04/26 13:54:16 fanf
put the newline on the #endif that replaces #elif lines

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

Re: RFC: style(9) isn't explicit about booleans for testing.

[Tony Finch]

Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
>
>Right, and since the integer is well defined,
>   if (!strcmp(a, b))
>is perfectly understandable so what is the problem ?

If that is ok, then why is

p = malloc(sizeof(*p));
if (!p)
return ENOMEM;

not ok, given that is even more well-defined?

I am of the opinion that expressions in a conditional context (i.e.
argument of ! && || ?: if while) should be boolean-valued (i.e. either 0
or 1 corresponding to false or true). If they aren't then an appropriate
comparison should be done.

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]>
FAEROES SOUTHEAST ICELAND: EASTERLY, BECOMING CYCLONIC THEN WESTERLY, 4 OR 5.
SNOW OR SNOW SHOWERS. GOOD OCCASIONALLY POOR.

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

Re: RFC: style(9) isn't explicit about booleans for testing.

[Tony Finch]

Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
>
>I had a discussion with Eric Allman about this very thing recently
>where he advocated "everything inside if, while, for and so on should
>be true booleans".
>
>Now, IFF the C language had a type called "boolean" that would make
>a lot of sense.
>
>Unfortunately, it does not (at present ?) have a boolean type, and
>while one could simulate it with typedefs, there is no way to get
>the compiler to enforce the rule.

C99 has a boolean type, but neither the comparison operators nor the
logical operators nor the ! operator return a bool, and conditional
contexts (like if, while, ?:) don't expect a bool.

Pretty useless, really.

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]>
ROCKALL: WEST BACKING SOUTHWEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 AT
FIRST, DECREASING 5 FOR A TIME. OCCASIONAL RAIN. MODERATE.

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

Re: A few questions about a few includes

[Tony Finch]

Lowell Gilbert <[EMAIL PROTECTED]> wrote:
>
>C-99 requires a fully specified type before the unspecified array (and
>requires said array to be the last element in the structure).  So this
>example is *not* valid in C99, but the following would be:
>
>struct foo {
>int bar;
>char array[];
>};
>
>[Which makes sense; it forces a structure to have a non-zero size.]

Although there has been some discussion in the committee about allowing
zero-sized objects in C, the standard doesn't allow them. This is perhaps
why it doesn't follow gcc's [0] syntax for variable length arrays at the
end of structures.

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]>
THAMES DOVER WIGHT PORTLAND PLYMOUTH: WEST OR SOUTHWEST 5 TO 7 DECREASING 4.
DRIZZLE DYING OUT. MODERATE, OCCASIONALLY POOR, BECOMING GOOD.

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

Re: FreeBSD-1.X public cvs?

[Tony Finch]

On Wed, Jan 30, 2002 at 09:41:15AM -0700, Nate Williams wrote:
> 
> A FreeBSD 1.X CVS tree has been found, which has it's first import as
> 386BSD 0.1 + PK 024.  There are a couple minor points that need to be
> clarified from Caldera before it can be made public.

Has there been any more progress with this?

Tony.

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

Re: In-Kernel HTTP Server (name preference)

[Tony Finch]

Terry Lambert <[EMAIL PROTECTED]> wrote:
>
> On SVR4, an attempt to access a non-resident page via a
> non-blocking fd will result in a fault for that page
> being scheduled, while the call returns to the user
> process with an "EWOULDBLOCK".
>
> A subsequent attempt to read it gets the paged in data,
> and then works as expected.
>
> The poll() call takes note of these outstanding page-in
> requests, and uses them to satisfy poll on a readable
> condition, so you can e.g. attempt the read, get that it
> would block, and then poll on readable on the fd, to
> avoid buzz-looping the process.

How does it deal with the situation that the machine's
working set has exceeded memory? If the web server is dealing
with lots of concurrent connections it may have to block in
poll() waiting for (say) a thousand pages to be brought in,
then in the process of dealing with them after the poll()
returns some of the pages may get re-used for something else
making read() on a "readable" fd return EWOULDBLOCK again.

But on the other hand the OS can't lock the pages in memory
until they are read, since passing the fd to poll() isn't
a promise to read since this may lead to DOS attacks, or
alternatively processes being unexpectedly killed for hitting
RLIMIT_MEMLOCK.

I can't see a good way of avoiding these semantic problems
without changing to a completely different kernel API like KSE.

Tony.

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

Re: In-Kernel HTTP Server (name preference)

[Tony Finch]

Dominic Marks <[EMAIL PROTECTED]>
>
> http://www.acme.com/software/thttpd/notes.html on the section
> regarding non-blocking I/O:
>
> "The fourth generation. One process only. No non-portable threads/LWPs.
> Sends multiple files concurrently using non-blocking I/O, calling
> select()/poll()/kqueue() to tell which ones are ready for more data.
> Speed is excellent. Memory use is excellent. Portability is excellent.
> Examples of this generation: Spinner, Open Market, and thttpd. Perhaps
> Apache will switch to this method at some point. I really can't
> understand why they went with that complicated pre-forking stuff.
> Using non-blockijng I/O is just not that hard."

Apache-2.0 will use a combination of in-process threading and pre-forking
by default, but the IO architecture has some scope for adding non-blocking
IO in the future.

The reasons for preforking are that it makes programming server extensions
much easier, especially when you consider things like database libraries
that don't provide a non-blocking API, etc. (Other bits of Apache are
designed to be simple, like the memory management.) Another thing in
preforking's favour is that it makes the server as a whole MUCH more
robust -- a child process can blow up without taking down the server --
and again this has advantages with unreliable server extensions.

Tony.

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

Re: In-Kernel HTTP Server (name preference)

[Tony Finch]

Julian Elischer <[EMAIL PROTECTED]> wrote:
>
> I can suggest using a netgraph module for the work as it can be connected
> to a netgraph ksocket node to receive the requests (jdp made all the
> changes needed to allow this to be done).

Another way would be to implement it as an accept filter which knows how
to handle simple requests but drops anything more complicated down to
a userland web server -- an unmodified Apache would be able to do the
latter, since it already supports accept filters. Some way of configuring
it is still needed, though...

Tony.

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

Re: FreeBSD-1.X public cvs?

[Tony Finch]

On Wed, Jan 30, 2002 at 10:05:20AM +1030, Greg Lehey wrote:
> Nate Williams <[EMAIL PROTECTED]> wrote:
> >
> > Thanks.  I'm going to wait and see what happens w/regards to the
> > talking heads on this, and if the consensus is that it's legal to
> > post, I'll upload the bits to freefall.
> 
> It's legal.  Here's the original message.  I'm also copying Dion
> Johnson.  Dion, as I'm sure you're aware, we took the FreeBSD 1.x
> sources offline because they were "tainted" with AT&T code.  Now that
> 32V is free, there should be no further problem releasing them, right?

What about 
which concerns the Berkeley patches to the AT&T code?

Tony.

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

Re: FreeBSD-1.X public cvs?

[Tony Finch]

On Tue, Jan 29, 2002 at 03:55:04PM -0700, Nate Williams wrote:
> 
> Thanks.  I'm going to wait and see what happens w/regards to the talking
> heads on this, and if the consensus is that it's legal to post, I'll
> upload the bits to freefall.

I'll note that this happened because of the efforts of the Unix
Heritage Society, and their archive (which until recently was
password-protected and required a free licence from SCO, like
the CSRG CDs) is now public. See  and
.

Tony.

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

Re: FreeBSD-1.X public cvs?

[Tony Finch]

On Tue, Jan 29, 2002 at 03:50:22PM -0700, Nate Williams wrote:
> 
> Thanks.  However, this isn't as specific as I'd like it to be.  It
> implies that Net1/Net2 are now 'legal', but it doesn't give explicit
> release of said source code.

Doesn't the text at the start of the letter explicitly say that?

Tony.

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

Re: FreeBSD-1.X public cvs?

[Tony Finch]

On Tue, Jan 29, 2002 at 10:47:04PM +, Dominic Marks wrote:
> On Tue, Jan 29, 2002 at 03:37:13PM -0700, Nate Williams wrote:
> > > Now that ancient unix has been relicensed with an old-style BSD licence,
> > > is the FreeBSD-1.X cvs repository going to be made public?
> > 
> > Out of curiousity, why?
> 
> "Out of curiousity" :)

Kirk was surprised by how popular the CSRG archives CDs are.

> > And, where have you heard that it's been relicensed?
> 
> http://minnie.tuhs.org/PUPS/

There's also a link from Caldera's own site
http://www.caldera.com/company/news/

Tony.

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

FreeBSD-1.X public cvs?

[Tony Finch]

Now that ancient unix has been relicensed with an old-style BSD licence,
is the FreeBSD-1.X cvs repository going to be made public?

Tony.

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

pedantic kobj problem

[Tony Finch]

I note that kobj uses a pointer to int kobj_error_method(void) when
it can't find an implementation of an interface in a class's method
list and the interface has no default implementation. However, the
C standard says in section 6.3.2.3:

   [#8] A pointer to a function of one type may be converted to
   a pointer to a function of another type and back again;  the
   result  shall  compare  equal to the original pointer.  If a
   converted pointer is used to call a function whose  type  is
   not  compatible  with  the  pointed-to type, the behavior is
   undefined.

and kobj_error_method is (necssarily) of a different type from all
actual interfaces.

Obviously this doesn't matter except in perverted C implementations
that (say) use pascal calling conventions, but I note it in case of
anyone trying to use kobj on such a system :-)

Tony.

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

Re: thttpd hack for sendfile and accept filters.

[Tony Finch]

Alfred Perlstein <[EMAIL PROTECTED]> wrote:
>
>The easiest way would be to have thttpd fork after listening a
>pre-determined amount of servers, then they'll all compete calling
>accept() to grab connections.

This is exactly what we did at Demon, which was for a long time
the largest thttpd installation, with about 70,000 vhosts on
one machine with a few reverse-proxies in front. I think I sent
that patch to Jef, but it is hardly rocket science :-)

Tony.
-- 
f.a.n.finch <[EMAIL PROTECTED]>
FISHER: NORTHEAST 4 OR 5. RAIN LATER. GOOD.

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

Re: httpfs

[Tony Finch]

Peter Pentchev <[EMAIL PROTECTED]> wrote:
>
>What I did was implement an 'exec' portal method, which executes a program
>with given arguments, obtained from the path components and portal.conf
>rules, and returns a - basically read-only - descriptor connected to its
>stdout and stderr.  Kind of simple, pipe(), fork(), dup2(), exec()..

Nice. Is there any reason not to add some bidirectional support by
connecting the descriptor to stdin as well?

Tony.
-- 
f.a.n.finch  [EMAIL PROTECTED]  [EMAIL PROTECTED]


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

Re: [hackers] Re: Setting memory allocators for library functions.

[Tony Finch]

Maxime Henrion <[EMAIL PROTECTED]> wrote:
>Tony Finch wrote:
>> 
>> If it's available at all, mprotect() is often limited to memory
>> obtained with mmap(), i.e. not malloc(). Not great for portability.
>
>FreeBSD malloc() calls mmap() as AFAIK many (if not all) malloc()
>implementations.

FreeBSD malloc() uses sbrk() for memory that it returns to the
application and mmap() for book-keeping memory (the page index).

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
GERMAN BIGHT: SOUTHEAST 4 OR 5 BACKING NORTHEAST 5 OR 6. SLEET. MODERATE OR
POOR.

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

Re: [hackers] Re: Setting memory allocators for library functions.

[Tony Finch]

Drew Eckhardt <[EMAIL PROTECTED]> wrote:
>In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>>In most cases it is impossible to declare the data read-only because
>>it originally had to be read-write and you can't change its attributes
>>later. 
>
>mprotect(2).

If it's available at all, mprotect() is often limited to memory
obtained with mmap(), i.e. not malloc(). Not great for portability.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
FORTH: NORTHEAST 6 TO GALE 8 DECREASING 5 OR 6. SLEET. MAINLY MODERATE.

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

Re: [hackers] Re: Setting memory allocators for library functions.

[Tony Finch]

Lyndon Nerenberg <[EMAIL PROTECTED]> wrote:
>
>If the information in the data segment is going to be updated then
>you have to have writable backing store. If, however, that data
>is never going to be changed, it should be declared in the program
>as read-only data. The kernel VM system should not be working around
>applications that don't declare their data arena correctly.

In most cases it is impossible to declare the data read-only because
it originally had to be read-write and you can't change its attributes
later. This is always the case for malloc(). Many applications do a
load of initialization that requires read-write memory then never
write to that memory again; when they fork the OS still has to account
for that memory twice even if it is going to be immediately discarded
by an exec(). An even more exaggerated example is Apache which forks a
load of times then hangs around for ages.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
MALIN: NORTHEAST 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10 IN SOUTHEAST AT
FIRST, DECREASING 5. SNOW SHOWERS. GOOD.

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

Re: Setting memory allocators for library functions.

[Tony Finch]

"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
>Matt Dillon wrote:
>>
>> What is the point of running a scientific calculation if the
>> machine turns into a sludge pile and would otherwise cause the
>> calculation to take years to complete instead of days?
>
>It doesn't trash. The memory is filled with backtracking information.
>Memory in active use at any time is rather small.

I've read articles about programs which use GC which have a small
working set, although it is constantly changing (I've heard of
programs allocating megabytes a second). The OS would have to swap out
the stale pages if the program's total memory use exceeds RAM, and
when the GC finally runs it will take forever and thrash swap like
there's no tomorrow.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
THAMES: EAST OR SOUTHEAST 3 OR 4. RAIN. MODERATE OR GOOD.

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

Re: [hackers] Re: Setting memory allocators for library functions.

[Tony Finch]

Peter Seebach <[EMAIL PROTECTED]> wrote:
>David Gilbert writes:
>>
>>Due to the bloat of the OS and Motif and other such things, they
>>required simply amazing amounts of swap just to run.
>
>Well, to some extent, I have to wonder why all these pages are being
>requested if they aren't being used...

fork() with big data segments that cause swap to be reserved in case
of a copy-on-write. The 2GB of swap is never actually used, but you
still have to have it.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]


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

Re: Setting memory allocators for library functions.

[Tony Finch]

Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
>
>This is all academic since FreeBSD does memory overcommit, so unless
>you run out of address space for your process before you run out of
>actual memory and/or swap (not likely, but quite possible) malloc()
>will never return NULL and you won't know a thing until you dirty one
>page too many and segfault.

What about setrlimit(RLIMIMT_DATA)?

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]


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

Re: /etc/security: add md5 to suid change notification?

[Tony Finch]

Robert Watson <[EMAIL PROTECTED]> wrote:
>
>If X has open file descriptors for privileged devices for the purposes of
>direct memory access, the debugging interfaces (and possibly exploits in
>shared libraries) can be used to control the X server in such a way that
>securelevels can be disabled or circumvented.

Does the OpenBSD aperture device solve that problem?

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
FINISTERRE SOLE: SOUTHEASTERLY VEERING SOUTHWESTERLY 5 TO 7, OCCASIONALLY GALE
8. OCCASIONAL RAIN. MODERATE OR POOR.


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

Re: soft updates and qmail (RE: qmail IO problems)

[Tony Finch]

Greg Black <[EMAIL PROTECTED]> wrote:
>Tony Finch wrote:
>
>> Why not just use rename(2)? To protect against the new filename
>> already existing?
>
>Why not just read the man page for rename(2) before making
>suggestions?

I did. I'm glad I was right that it's deleting the destination that is
the problem. I would have thought it would be easy to be sure that
spool filenames are unique, but OTOH I guess that's not completely
robust.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
GERMAN BIGHT: SOUTHERLY BECOMING CYCLONIC THEN MAINLY NORTHERLY 5 TO 7,
PERHAPS GALE 8 LATER. RAIN. MAINLY MODERATE.


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

Re: soft updates and qmail (RE: qmail IO problems)

[Tony Finch]

Andre Oppermann <[EMAIL PROTECTED]> wrote:
>
>Qmail has a couple of directories for the different states a queued
>message goes through. The whole queue structure is required to be on
>the same partition/disk. After the completing of each step in the queue
>it is moved through the use of link() and then unlink() to the next
>directory.

Why not just use rename(2)? To protect against the new filename
already existing?

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
GERMAN BIGHT HUMBER THAMES DOVER WIGHT PORTLAND PLYMOUTH: SOUTHWEST 5 TO 7
DECREASING 4, BECOMING CYCLONIC LATER. RAIN LATER. GOOD, BECOMING MODERATE
OCCASIONALLY POOR LATER.


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

Re: CVSup7.FreeBSD.org is back in service

[Tony Finch]

John Polstra <[EMAIL PROTECTED]> wrote:
>
>The folks who run the mirrors in Japan have a very nice setup which
>uses SNMP to query the number of active CVSup clients on each mirror.
>They don't do automatic load balancing with it currently, but they
>make some nice graphs available on the web for people to use. (Sorry,
>I don't remember the URL.)

Looks like 

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
"Dead! And yet there he stands!"


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

Re: removing setgid kmem from top, collecting per-device swap stats

[Tony Finch]

Thomas Moestl <[EMAIL PROTECTED]> wrote:
>
>Most kmem_read calls are easy to replace (the variables are already 
>exported as sysctls), the only exception is nextproc (for which I might
>add a sysctl, or just leave it out [anyone out there who needs the 
>lastpid display?]).

It's useful for seeing how fast the machine is forking.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
"There are flying saucers. There's no doubt they are
in our skies. They've been there for some time."


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

Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)

[Tony Finch]

Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
>Gordon Tetlow <[EMAIL PROTECTED]> writes:
>> If you are using apache (who isn't?), I highly suggest you look into using
>> suexec. That way bad CGI programming is offloaded to the customer and not
>> to your system.
>
>suexec has many weaknesses - amongst other problems, it does not set
>resource limits; nor does it chroot as far as I recall.

Apache itself has support for setting resource limits, although I
agree that in many cases you may want them to be different between the
httpd and the CGIs.

I expect chrooting was left out because people who have the wit to set
up a chroot are capable of adding a couple of lines to a C program.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
"Because all you of Earth are idiots!"


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

Re: kernel type

[Tony Finch]

Andrew Reilly <[EMAIL PROTECTED]> wrote:
>
>Yeah, but in what sense is that use of Mach a serious
>microkernel, if it's only got one server: BSD?

IIRC the Mac parts of Mac OS X run as another server beside BSD on top
of Mach.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
"You realize there's a government directive stating
that there is no such thing as a flying saucer?"


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

Re: kernel type

[Tony Finch]

Patryk Zadarnowski <[EMAIL PROTECTED]> wrote:
>
>Now that I think of it, there aren't many commercial microkernel
>systems out there with the possible exception of QNX and lots of
>little embedded toys.

Mac OS X is based on Mach.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
"And remember my friend, future events such
as these will affect you in the future."


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

Re: very big mail spool directory

[Tony Finch]

Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
>Tony Finch <[EMAIL PROTECTED]> writes:
>> Why a prime number? All you need is an even spread, and given that
>> user IDs are usually allocated sequentially any modulus will do.
>
>Because a prime number is less likely to cause an imbalance in where
>files are actually stored on disk - just like you want an odd (and
>preferably prime) stripe size on RAIDs to (amongst other reasons)
>avoid having all the superblock backups end up on the same disk.

That's another situation in which the collision rate is very low.
I still think any number of about the right size will do.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
" ``Well, let's go down and find out who's grave it is.''
``How?''  ``By going down and finding out!'' "


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

Re: very big mail spool directory

[Tony Finch]

Warner Losh <[EMAIL PROTECTED]> wrote:
>In message <[EMAIL PROTECTED]> Tony Finch writes:
>: Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
>: >
>: >If you only have half a million users, pick a prime number K close to
>: >the square root of the expected number of users (724 in your case -
>: >closest primes are 719 and 727), create that many bucket directories,
>: >and place each user in bucket ID mod K.
>: 
>: Why a prime number? All you need is an even spread, and given that
>: user IDs are usually allocated sequentially any modulus will do.
>
>Because Knuth has shown that prime numbers give the best spread in
>hash lookup tables.

Yes, I know that, but we aren't talking about normal hash tables. The
aim of the prime number is to avoid hash collisions, but in this
application you are deliberately aiming for about 700 items in each
bucket instead of about one. Whether the modulus is prime or not will
make no detectable difference with this degree of hash collision.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
"If I didn't see it with my own eyes I would never have believed it!"


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

Re: very big mail spool directory

[Tony Finch]

Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
>
>If you only have half a million users, pick a prime number K close to
>the square root of the expected number of users (724 in your case -
>closest primes are 719 and 727), create that many bucket directories,
>and place each user in bucket ID mod K.

Why a prime number? All you need is an even spread, and given that
user IDs are usually allocated sequentially any modulus will do.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
"Plan 9 deals with the resurrection of the dead."


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

Re: psm and PNPBIOS

[Tony Finch]

Tony Finch <[EMAIL PROTECTED]> wrote:
>
>There seems to be some "notyet" code in psm.c which looks relevant,
>but enabling it with the patch below doesn't do the trick. I guess
>this is because at the time the probe runs the atkbdc hasn't probed
>yet so isn't there to attach to.

Um.

Index: psm.c
===
RCS file: /home/ncvs/src/sys/isa/psm.c,v
retrieving revision 1.23.2.4
diff -u -r1.23.2.4 psm.c
--- psm.c   2000/08/24 08:50:38 1.23.2.4
+++ psm.c   2000/11/27 22:38:02
@@ -313,13 +313,11 @@
 sizeof(struct psm_softc),
 };
 
-#if notyet
 static struct isa_pnp_id psm_ids[] = {
 { 0x130fd041, "PS/2 mouse port" }, /* PNP0F13 */
 { 0x1303d041, "PS/2 port" },   /* PNP0313, XXX */
 { 0 }
 };
-#endif
 
 #define CDEV_MAJOR21
 
@@ -805,11 +803,9 @@
 kbdc_debug(TRUE);
 #endif
 
-#if notyet
 /* check PnP IDs */
-if (XXX_PNP_PROBE(device_get_parent(dev), dev, psm_ids) == ENXIO)
+if (ISA_PNP_PROBE(device_get_parent(dev), dev, psm_ids) == ENXIO)
return ENXIO;
-#endif
 
 BUS_READ_IVAR(device_get_parent(dev), dev, KBDC_IVAR_IRQ, &irq);
 BUS_READ_IVAR(device_get_parent(dev), dev, KBDC_IVAR_FLAGS, &flags);


Tony.
-- 
f.a.n.finch [EMAIL PROTECTED] [EMAIL PROTECTED] Chad for President!


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

psm and PNPBIOS

[Tony Finch]

I recently got a new machine (DELL Optiplex GX110) which seems to work
fine with FreeBSD, except for a small niggle: If I include "options
PNPBIOS" in the kernel config the mouse doesn't probe properly,
however it works fine on my DELL Latitude CPx laptop.

The problem seems to be because of the order in which the devices are
listed by the PnP BIOS: on the Latitude, the keyboard controller
PNP0303 comes before the PS/2 mouse PNP0f13, so things get probed in
an order which works. On the Optiplex, the mouse is listed before the
keyboard in the BIOS, so the "unknown PNP device" grabs irq 12 leaving
psm unable to allocate its resources.

There seems to be some "notyet" code in psm.c which looks relevant,
but enabling it with the patch below doesn't do the trick. I guess
this is because at the time the probe runs the atkbdc hasn't probed
yet so isn't there to attach to.

Is there an easy way to fix this?

Tony.
-- 
f.a.n.finch [EMAIL PROTECTED] [EMAIL PROTECTED] Chad for President!


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

Re: sfork() ??

[Tony Finch]

"Pedro F. Giffuni" <[EMAIL PROTECTED]> wrote:
>
>Can someone knowledgeable comment on what it does, and maybe if it could 
>(or should) be brought into FreeBSD ?

Perhaps you are looking for rfork()? AFAIK Irix calls rfork() sfork().

Tony.
-- 
f.a.n.finch [EMAIL PROTECTED] [EMAIL PROTECTED] Chad for President!


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

Re: pointer for thread safe resolver stuff?

[Tony Finch]

Alfred Perlstein <[EMAIL PROTECTED]> wrote:
>
>I'm going to keep reading the library source (and cursing the ISC)
>but I was wondering if anyone knew of any docs for the bind9 stuff
>or any other thread safe (non-GPL'd) resolver library.

AFAIK the bind-9 resolver is a full resolver not a stub resolver,
which probably isn't what you want. I haven't checked this hearsay
for myself though.

Tony.
-- 
en oeccget g mtcaaf.a.n.finch
v spdlkishrhtewe y[EMAIL PROTECTED]
eatp o v eiti i d.[EMAIL PROTECTED]


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

Re: Who broke "ls" in FreeBSD? and why?

[Tony Finch]

Warner Losh <[EMAIL PROTECTED]> wrote:
>
>For normal users, ls -a lists all files, not counting . and .., but
>for root it does list all files.

No, it always lists all files.

>ls -A lists all files for normal users, but omits . and .. for root.

No, it always lists all files except for "." and "..".

-A is on by default for root with most versions of ls, notably not
including GNU ls.

Tony.
-- 
en oeccget g mtcaaf.a.n.finch
v spdlkishrhtewe y[EMAIL PROTECTED]
eatp o v eiti i d.[EMAIL PROTECTED]


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

Re: FreeBSD vs. Linux

[Tony Finch]

Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote:
>James Housley <[EMAIL PROTECTED]> writes:
>> I believe a correct and true statement is "FreeBSD is a direct decendant
>> of Unix(TM).  Based on the BSD sources"
>
>I don't think there's all that much left of the original BSD
>sources... at least not in the kernel.

Large bits of errno.h haven't changed since 1982 :-)

Tony.
-- 
en oeccget g mtcaaf.a.n.finch
v spdlkishrhtewe y[EMAIL PROTECTED]
eatp o v eiti i d.[EMAIL PROTECTED]


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

Re: IDE drives doing BBR?

[Tony Finch]

Jaye Mathisen <[EMAIL PROTECTED]> wrote:
>
>Remember reading on hackers somewhere that newer drives like IBM supported
>this feature.  I'm getting a few bad blocks on a 75GB IBM drive (at least
>according to the ata driver), and rather than replacing it and moves on,
>the disk basically dies.

I would expect the disk to permanently die soon.

Tony.
-- 
en oeccget g mtcaaf.a.n.finch
v spdlkishrhtewe y[EMAIL PROTECTED]
eatp o v eiti i d.[EMAIL PROTECTED]


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

Re: Critical (or equivalent) section in Userland?

[Tony Finch]

Karl Pielorz <[EMAIL PROTECTED]> wrote:
>
>I don't think advisory locks will work - the other process is sendmail... I
>have to keep it from opening any of it's config files, whilst I 'rename' out
>of place the old ones (keeping any fd's to them intact) and rename in the new
>ones...

Why not append a serial number to the end of the filenames of the
subsidiary configuration files, and modify sendmail.cf accordingly?
Then the update procedure could be:
(1) write all the new files as $filename.`date +%Y%d%m%H%M%S`
(2) mv sendmail.cf.date sendmail.cf (or use `ln -sf` if you want to
keep old files)
(3) every day or so delete configuration files that are older than
your maximum queue run time.

This gives you atomic configuration updates.

You don't need to rename the old sendmail.cf to another because
existing fds will remain attached to the old file which isn't being
altered, just unlinked.

Tony.
-- 
en oeccget g mtcaaf.a.n.finch
v spdlkishrhtewe y[EMAIL PROTECTED]
eatp o v eiti i d.[EMAIL PROTECTED]


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

Re: audiofs mixing audio and data tracks

[Tony Finch]

Soren Schmidt <[EMAIL PROTECTED]> wrote:
>It seems Koster, K.J. wrote:
>> 
>> Am I right in thinking that a cdrom can have at most one data track? In that
>> case, I'd suggest assighing that track a standard device node. That way I
>> could just mount the data track of a cdrom, without worrying if that's track
>> 4 or track 1.
>
>Mostly yes, but there is nothing hindering multiple data tracks on
>the same CD. At any rate we only have access to one now anyways so
>that wouldn't hurt anything :)

How does this relate to multi-session CDs? Does that happen at a lower layer?

Tony.
-- 
en oeccget g mtcaaf.a.n.finch
v spdlkishrhtewe y[EMAIL PROTECTED]
eatp o v eiti i d.[EMAIL PROTECTED]


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

Re: FreeBSD belly up with big config

[Tony Finch]

Robert Watson <[EMAIL PROTECTED]> wrote:
>
>I'd made some similar observations about the current lack of scalability
>both in management of (struct ifnet) chains, and mountpoints in the file
>system.

When I had a brief look at the way mount points are handled I
concluded that most of the time they were found via the vnode tree
which is independent of the number of mounted filesystems. The list of
mountpoints is only scanned rarely, when you are doing heavy stuff
like mounting or unmounting a filesystem.

Tony.
-- 
en oeccget g mtcaaf.a.n.finch
v spdlkishrhtewe y[EMAIL PROTECTED]
eatp o v eiti i d.[EMAIL PROTECTED]


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

Re: LD_PRELOAD odities / Documentation?

[Tony Finch]

Karl Pielorz <[EMAIL PROTECTED]> wrote:
>
>One of the ways I've tried implementing syscalls is to dlopen() the correct
>library, and fetch the routines address from there (using dlsym) - and calling
>the routine that way...
>
>This doesn't seem to help though :(

I've made this work across Solaris, Linux, and FreeBSD. Can you post
your code? Its hard to debug a vague description.

Tony.
-- 
en oeccget g mtcaaf.a.n.finch
v spdlkishrhtewe y[EMAIL PROTECTED]
eatp o v eiti i d.[EMAIL PROTECTED]


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

Re: ATA100-7200rpm vs 10k-rpm SCSI for build box

[Tony Finch]

Thomas Stromberg <[EMAIL PROTECTED]> wrote:
>
>$132 4.5G 1RPM Seagate Cheetah
>or
>$97  IBM Deskstar 75GXP ATA-100 7200RPM 15G (DTLA)
>
>The question is, whats the real speed difference between a IBM 75GX
>(http://www.tweakmax.com/html/ibm75gxp/ibm-1.cfm) and ye old 1RPM
>Cheetahs in FreeBSD?

Check the numbers for the seek times as well.

Tony.
-- 
en oeccget g mtcaaf.a.n.finch
v spdlkishrhtewe y[EMAIL PROTECTED]
eatp o v eiti i d.[EMAIL PROTECTED]


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

Re: ANSI C Standard and wchar*

[Tony Finch]

"Michael C. Wu" <[EMAIL PROTECTED]> wrote:
>
>I am working on completing a BSDL'ed implementation of wchar* that is
>*not* broken. However, I could not find a free copy of ANSI C library
>standard.

There's some good stuff on the Lysator site, in particular the final
draft of the C99 standard and a PD implementation of bits of the C99
library ("Q8").

http://www.lysator.liu.se/c/

Tony.
-- 
en oeccget g mtcaaf.a.n.finch
v spdlkishrhtewe y[EMAIL PROTECTED]
eatp o v eiti i d.[EMAIL PROTECTED]


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

Re: patch for openssh to work with pty-redir

[Tony Finch]

Jim Mercer <[EMAIL PROTECTED]> wrote:
>
>i was using pty-redir (from netbsd) and ssh to do VPN (ppp over ssh).
>under 3.x release, with the ports/ssh, this worked fine.
>however, starting with when openssh became part of the system, it stopped
>working.
>when i did a "pty-redir ssh remhost /usr/sbin/pppd"
>the openssh would complain:
>"Pseudo-terminal will not be allocated because stdin is not a terminal."
>
>i managed to get it working with the stock openssh using the following patch.
>(yes, it is a quick and ugly hack)

Hmm, I was confused for a while there by your reversed patch, but I know
where we are now :-)

I had a similar problem with user-ppp over ssh talking to an sshd on
OpenBSD.  The problem turned out to be that if sshd gives you a pty then
stdin and stdout are the same bidirectional descriptor (so ppp works)
but if that isn't the case then sshd uses two pipes in a unidirectional
fashion. FreeBSD's sshd (since March in -CURRENT and April in 4.x) has
a tweaked includes.h that doesn't #define USE_PIPES, so stdin is always
bidirectional and ppp over ssh works. If your sshd is compiled in this
way then you shouldn't need pty-redir either (although I can't find
the source to check that it does what I think it does).

Thanks to Brian "ppp over ssh over httptunnel" Somers for the explanation!

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
404 the crinkley caress of crenulated crevice clips


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

Re: buildworld summary

[Tony Finch]

>>> A few months ago someone posted a script that summarizes make
>>> buildworld as it progresses. I've searched the ports and the mailing
>>> lists but I can't find it any more :-( so I'd be grateful if someone
>>> would tell me. Thanks.
>>
>> It was phk (cc'd), and yes, it seems to have evaporated.
>
> Hmm, are you sure you're not thinking of 'whereintheworld' by
> fenner, or isn't that what you were thinking of?  Take a look at
>  and see if
> it's what you're after.

Ah, that's the one! Thanks, and thanks to the others who mailed me off
the list.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
292 hatchet-job afterglow


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

buildworld summary

[Tony Finch]

A few months ago someone posted a script that summarizes make
buildworld as it progresses. I've searched the ports and the mailing
lists but I can't find it any more :-( so I'd be grateful if someone
would tell me. Thanks.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
356 pungent unguent for stump-itch



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

Re: NFS server problems on 3.4-S, any interest?

[Tony Finch]

Doug Barton <[EMAIL PROTECTED]> wrote:
>
>Hrrrmm... I just took a look at the settings for each card. I did not
>specify full duplex in the fxp0 ifconfig line, since autoselect has
>always worked before.

Autonegotiation is prone to problems. It only really works if both
ends have the same setting (i.e. both locked down or neither locked
down); if the settings are mismatched then the speed will be selected
correctly but the autonegotiating card will choose half-duplex which
is almost always what you don't want. It'll partially work but you'll
see exactly the sort of problems you reported.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
431 open wider for the magic cider


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

Re: Multithread safe gethostbyname() ?

[Tony Finch]

Arun Sharma <[EMAIL PROTECTED]> wrote:
>
>I think it'd be very useful to have a non-blocking DNS lookup API (one
>which exposes the underlying file descriptor) . Winsock has this. UNIX
>netscape 4.x would freeze half as often if this was done right.

http://www.chiark.greenend.org.uk/~ian/adns/ is nice if you don't mind
the GPL.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
441 the tone-arm of turbidity


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

Re: FBSD-3.4, full bgp routing, maxusers, NMBCLUSTERS

[Tony Finch]

Jim Mercer <[EMAIL PROTECTED]> wrote:
>
>how do i increase the amount of RAM for the kernel?

http://www.freebsd.org/FAQ/hackers.html#AEN4204

>i thought NMBCLUSTERS was the one, but i guess not.

That's just for network buffers.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
342 comedy as old and flaccid...


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

Re: No route for 127/8 to lo0 (?)

[Tony Finch]

Nik Clayton <[EMAIL PROTECTED]> wrote:
>
>I thought that 127/8 was the "local net", and that packets sent to any of
>those addresses would go via the loopback interface.  That seems to be 
>how Linux and Windows 98 do things (the only systems I can check this on
>at the moment).  Assuming that's the case, why does FreeBSD only add a
>a host route to 127.0.0.1, and not a network route for 127/8?

I did some further investigation to see how old this oddity is and it
seems to be the way BSD has always handled the loopback interface.
There's an explicit exclusion in the interface initialization code in
in.c that gives loopback interfaces a host route instead of the
network route that a normal interface gets and it's been that way for
15 years.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
408 overlarge underplug afterburn


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

Re: Tuning TCP/IP Performance

[Tony Finch]

Joe Abley <[EMAIL PROTECTED]> wrote:
>
> If 4.0 (or later 3.x's) support SACK, turn that on here too.

Neither of them does.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
441 the tone-arm of turbidity


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

Re: downed IP addresses/redundancy

[Tony Finch]

Alfred Perlstein <[EMAIL PROTECTED]> wrote:
>
>Once you tell an application to bind to a particular IP address
>I'm pretty sure most don't have an option to bind another listen
>socket.
>
>The customer can't fail over properly because even when the alias
>for the box that dies comes up, thier daemon won't get requests on
>the added IP.

What would be cool is if FreeBSD could do VRRP. This is usually used
for providing a default route handled by two physical boxen, but if
you turn it around and provide a route to a service IP address that
may be handled by two boxen that deal with fail-over using VRRP then
this solves the problem discussed in this thread.

I'd be interested to know of a free implementation of VRRP for the BSD
network stack.

Tony.
-- 
dot it thus


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

Re: LD_PRELOAD

[Tony Finch]

John Polstra <[EMAIL PROTECTED]> wrote:
>Tony Finch  <[EMAIL PROTECTED]> wrote:
>>John Polstra <[EMAIL PROTECTED]> wrote:
>>>
>>> The names "_init" and "_fini" are "reserved for the implementation"
>>> in ANSI/ISO-speak.  You shouldn't use them.
>> 
>> I don't have any choice on Solaris, unfortunately (and my code has to
>> be portable between FreeBSD and Solaris). I suppose in that case
>> Solaris is the implementation and they have reserved it for my use. I
>> gather from the linker errors that FreeBSD has reserved the names for
>> a different use?
>
>The machinery that supports C++ constructors uses them.
>
>> >Or, write it in C++ and use a global constructor.
>> 
>> No. Never. No way. NO. :-)
>
>The advantage of using C++ for this is that you're using a portable
>mechanism instead of a gcc extension.

I'm not really worried about portability to different compilers. OS
portability is important, though.

I settled on using the following declaration. This works on Solaris,
FreeBSD, and Linux. (This implies that the Solaris rtld documentation
isn't quite complete regarding its support for C++ mechanisms.)

static void startup(void) __attribute__ ((constructor));

>>> You're probably the first person on earth to
>>> have more than one library in LD_PRELOAD. :-)

I'm using an LD_PRELOAD hack to add functionality to a commercial
application, and it has to co-exist with another vendor's commercial
LD_PRELOAD hack for the same application. I've managed to get my test
to work to my satisfaction on FreeBSD and Linux but it makes the
Solaris 2.6 ld.so.1 crash which is a shame since Solaris is my
principal OS for this project...

The stuff I have done so far is available from
http://www.inch.demon.co.uk/filemodshim.tar.gz
Run `make test` for a bit of fun. Some Makefile frobbing may be required.

Tony.
-- 
I'm the dot in dot at


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

Re: LD_PRELOAD

[Tony Finch]

John Polstra <[EMAIL PROTECTED]> wrote:
>Tony Finch  <[EMAIL PROTECTED]> wrote:
>>
>> I'm experimenting with using LD_PRELOAD to implement "shim"
>> wrappers around functions in libc. The first problem I had was
>> compiling my shim library so that the rtld would accept it.
>
>The right way to do it on FreeBSD is like this:
>gcc -fpic -c *.c
>gcc -shared -o libshim.so *.o

That works fine, thanks! Any idea why my clumsy success worked and why
my clumsy failures didn't?

>> This brings me on to the second problem. I want to do some
>> initialization of my library before the real action starts. On Solaris
>> the linker calls a function in the object called _init() when it is
>> loaded; it's easy to make this work. I can see similar functionality
>> in FreeBSD's rtld but it looks like I have to jump through obscure
>> hoops to make it work (an ELF DT_INIT section if I understand it
>> correctly).
>
>The names "_init" and "_fini" are "reserved for the implementation"
>in ANSI/ISO-speak.  You shouldn't use them.

I don't have any choice on Solaris, unfortunately (and my code has to
be portable between FreeBSD and Solaris). I suppose in that case
Solaris is the implementation and they have reserved it for my use. I
gather from the linker errors that FreeBSD has reserved the names for
a different use?

>You can get what you want like this with gcc:
>
>void myInitFunction(void) __attribute__ ((constructor));

Is that attribute equivalent to ((section (".init")))?

>Or, write it in C++ and use a global constructor.

No. Never. No way. NO. :-)

>> I also note a user-interface incompatibility between FreeBSD's
>> implementation of LD_PRELOAD and Solaris's: on Solaris the filenames
>> listed in LD_PRELOAD are space-separated, but on FreeBSD they are
>> colon or semicolon separated.
>
>That could be a bug.  You're probably the first person on earth to
>have more than one library in LD_PRELOAD. :-)  What does Linux do?

According to the documentation I looked at it uses arbitrary
whitespace as the separator. I haven't looked at the code to check.

Thanks for your help.

Tony.
-- 
dot it thus


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

Re: LD_PRELOAD

[Tony Finch]

Tony Finch <[EMAIL PROTECTED]> wrote:
> 
> This brings me on to the second problem. I want to do some
> initialization of my library before the real action starts. On Solaris
> the linker calls a function in the object called _init() when it is
> loaded; it's easy to make this work. I can see similar functionality
> in FreeBSD's rtld but it looks like I have to jump through obscure
> hoops to make it work (an ELF DT_INIT section if I understand it
> correctly).

After some more playing I found that adding the following declarations
shut up the linker and caused the _init and _fini functions to be
called as I desired. My only remaining questions are whether the gcc
command line I used is correct and if it is what does it all mean?

#ifdef __FreeBSD__
static void _init(void) __attribute__ ((section (".init")));
static void _fini(void) __attribute__ ((section (".fini")));
#endif

Tony.
-- 
the dot at person


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

LD_PRELOAD

[Tony Finch]

I'm experimenting with using LD_PRELOAD to implement "shim" wrappers
around functions in libc. It's really easy to do on Solaris but I'm
having some difficulty on FreeBSD.

The first problem I had was compiling my shim library so that the rtld
would accept it. On Solaris I can just use `gcc -c libshim.c` then
setting LD_PRELOAD to ./libshim.o does the expected thing. If I try
this on FreeBSD then the rtld says:
/usr/libexec/ld-elf.so.1: ./libshim.o: unsupported file type
I managed to get it to work with this command line:
gcc -Xlinker -E -Xlinker -noinhibit-exec -shared -o libshim.so libshim.c
which gives me a bunch of errors as follows (related to my next problem):
/var/tmp/ccP231581.o: In function `_init':
/var/tmp/ccP231581.o(.text+0x34): multiple definition of `_init'
/usr/lib/crti.o(.init+0x0): first defined here
/var/tmp/ccP231581.o: In function `_fini':
/var/tmp/ccP231581.o(.text+0xdc): multiple definition of `_fini'
/usr/lib/crti.o(.fini+0x0): first defined here
How do I get it to link cleanly? Do I really have to link it at all?

This brings me on to the second problem. I want to do some
initialization of my library before the real action starts. On Solaris
the linker calls a function in the object called _init() when it is
loaded; it's easy to make this work. I can see similar functionality
in FreeBSD's rtld but it looks like I have to jump through obscure
hoops to make it work (an ELF DT_INIT section if I understand it
correctly). I also note that a lot of the library code in FreeBSD has
code like
if (!initialized)
init_me_baby();
at the start of entry-point functions. This seems grotty and
inefficient to me and I'd like to avoid it if possible.

I also note a user-interface incompatibility between FreeBSD's
implementation of LD_PRELOAD and Solaris's: on Solaris the filenames
listed in LD_PRELOAD are space-separated, but on FreeBSD they are
colon or semicolon separated.

Any pearls of wisdom would be gratefully received.

Tony.
-- 
the man who puts the dot at


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

Re: mbuf wait code (revisited) -- review?

[Tony Finch]

Matthew Dillon <[EMAIL PROTECTED]> wrote:
>
>The solution Apache takes is to surround the accept() with a file lock
>so only one process blocks in accept() at any given point (the file lock
>uses wakeup_one and is safe).

Apache doesn't lock accept() if there's only one listening socket.
(Look for the #define SINGLE_LISTEN_UNSERIALIZED_ACCEPT in
apache-1.3/src/include/ap_config.h)

>The solution that I took with BestWWWD was to have just one process 
>accept all the connections and then have it dole the descriptor out to the
>appropriate sub-processes over a unix-domain socket.

Demon has a large server based on thttpd running on IRIX. One of the
changes that was made to thttpd was to fork the server several times
to get some parallelism for disk operations. When I came to port the
code to FreeBSD I found that it worked fine as it was on a UP machine,
but on an SMP machine when a connection came in two processes would
symultaneously wake up from select() then try to accept() the
connection; one would succeed and one would block and snarl up a load
of other connections. My solution was the same as Matt's :-)
(I'm not happy about the extra context switching that it requires but
I was more interested in working code than performance; I haven't
benchmarked it.)

Tony.
-- 
i am the dot at dotat dot at


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

Re: Class C hack instead of ifconfig aliases

[Tony Finch]

Matthew Reimer <[EMAIL PROTECTED]> wrote:
>Here's a way to do it without patches:
>
>1. in your webserver:
>   a. ipfw add fwd localhost from any to 1.2.3/24 http
>   b. add  sections, like this:

If you're using enough IP addresses to make this trick worthwhile then
you're probably interested in mod_vhost_alias which is new in Apache 1.3.9.

>Pros:
>
>- no need to 'ifconfig xyz alias...'.

Big deal -- you still have to use an ipfw command instead.

>- address matching is fast, since only a few ipfw rules are checked,
>  rather than lists of hundreds or thousands of IP addresses

The NETALIAS patch (PR#12071) is smaller and faster than turning on
IPFIREWALL and IPFIREWALL_FORWARD.

Tony.
-- 
the .@ person


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

Re: Class C hack instead of ifconfig aliases

[Tony Finch]

Geoff Buckingham <[EMAIL PROTECTED]> wrote:
>
>In an effort to avoid what may follow, I fully appreciate HTTP 1.1 vhosting
>is much more appropriate in many situations, this does not however 
>remove the need for large scale conventional virtual hosting alltogether.

I'll also mention SSL, since it requires an IP address per virtual host.

Tony.
-- 
dot it at


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

Re: mounting a partition more than once

[Tony Finch]

Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Tony Finch <[EMAIL PROTECTED]> wrote:
> :Matthew Dillon <[EMAIL PROTECTED]> wrote:
> :>
> :> Also, this may not be the best place to put the code.  It make sense
> :> to be able to mount a block device multiple times in a read-only
> :> fashion, but the code should be in the open for the block device
> :> rather then in UFS/FFS, so it can be used with other filesystems
> :> and for other purposes.
> :
> :Yes, it's evident that this is true because I had to hack around
> :essentially the same test in both spec_open and ffs_mountfs; removing
> :the checks down from ffs_mountfs so it relies on spec_mount to DTRT
> :would be neater, I think.
> 
> Yes.  I think this is the right track to take.  The result will be
> more useful to the system and probably a cleaner patch as well.

I found some problems with the patch last night (after some
suggestions from a colleague). There needs to be some additional
checking at the level of the syscall code, I think, to prevent
mounting the same partition at the same point more than once -- this
causes a "lockmgr: locking against myself" panic when unmounting. I
also missed out some checks from the remount code...

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix


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

Re: mounting a partition more than once

[Tony Finch]

Matthew Dillon  wrote:
> Tony Finch  wrote:
> :Matthew Dillon  wrote:
> :>
> :> Also, this may not be the best place to put the code.  It make sense
> :> to be able to mount a block device multiple times in a read-only
> :> fashion, but the code should be in the open for the block device
> :> rather then in UFS/FFS, so it can be used with other filesystems
> :> and for other purposes.
> :
> :Yes, it's evident that this is true because I had to hack around
> :essentially the same test in both spec_open and ffs_mountfs; removing
> :the checks down from ffs_mountfs so it relies on spec_mount to DTRT
> :would be neater, I think.
> 
> Yes.  I think this is the right track to take.  The result will be
> more useful to the system and probably a cleaner patch as well.

I found some problems with the patch last night (after some
suggestions from a colleague). There needs to be some additional
checking at the level of the syscall code, I think, to prevent
mounting the same partition at the same point more than once -- this
causes a "lockmgr: locking against myself" panic when unmounting. I
also missed out some checks from the remount code...

Tony.
-- 
f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix


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

Re: mounting a partition more than once

[Tony Finch]

Matthew Dillon <[EMAIL PROTECTED]> wrote:
> :Tony Finch <[EMAIL PROTECTED]> wrote:
> :
> :Well, in the absence of any comments I hacked around a bit and ended
> :up with the following patch (against 3.3-RC), which permits the same
> :block device to be mounted read-only more than once. The motivation
> :for this is to permit multiple chrooted environments to share the same
> :/usr partition.
> 
> Hmm... well, there is a problem here.  I believe this will allow
> you to open the underlying block device read-only as well as mount
> the filesystem read-only.  This will confuse the buffer cache badly.

I don't think so -- spec_open checks whether the block device has been
mounted in order to prevent this, and I made sure that that check
remains in force except when spec_open is called by ffs_mountfs (by
adding the FMOUNTING flag). I assumed that the buffer cache will
handle multiple read-only mounts because it handles multiple userland
reading file descriptors.

> Also, this may not be the best place to put the code.  It make sense
> to be able to mount a block device multiple times in a read-only
> fashion, but the code should be in the open for the block device
> rather then in UFS/FFS, so it can be used with other filesystems
> and for other purposes.

Yes, it's evident that this is true because I had to hack around
essentially the same test in both spec_open and ffs_mountfs; removing
the checks down from ffs_mountfs so it relies on spec_mount to DTRT
would be neater, I think.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix


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

Re: mounting a partition more than once

[Tony Finch]

Matthew Dillon  wrote:
> :Tony Finch  wrote:
> :
> :Well, in the absence of any comments I hacked around a bit and ended
> :up with the following patch (against 3.3-RC), which permits the same
> :block device to be mounted read-only more than once. The motivation
> :for this is to permit multiple chrooted environments to share the same
> :/usr partition.
> 
> Hmm... well, there is a problem here.  I believe this will allow
> you to open the underlying block device read-only as well as mount
> the filesystem read-only.  This will confuse the buffer cache badly.

I don't think so -- spec_open checks whether the block device has been
mounted in order to prevent this, and I made sure that that check
remains in force except when spec_open is called by ffs_mountfs (by
adding the FMOUNTING flag). I assumed that the buffer cache will
handle multiple read-only mounts because it handles multiple userland
reading file descriptors.

> Also, this may not be the best place to put the code.  It make sense
> to be able to mount a block device multiple times in a read-only
> fashion, but the code should be in the open for the block device
> rather then in UFS/FFS, so it can be used with other filesystems
> and for other purposes.

Yes, it's evident that this is true because I had to hack around
essentially the same test in both spec_open and ffs_mountfs; removing
the checks down from ffs_mountfs so it relies on spec_mount to DTRT
would be neater, I think.

Tony.
-- 
f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix


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

Re: mounting a partition more than once

[Tony Finch]

Tony Finch <[EMAIL PROTECTED]> wrote:
>
>Is there a reason for disallowing concurrent read-only mounts of the
>same disk device? i.e. would things go pear-shaped if I added this
>capability? 

Well, in the absence of any comments I hacked around a bit and ended
up with the following patch (against 3.3-RC), which permits the same
block device to be mounted read-only more than once. The motivation
for this is to permit multiple chrooted environments to share the same
/usr partition.

Some things I wonder about this change is whether the mounts will share
the same pages in the buffer cache, and whether the resource
accounting is still right. I've subtly funted the meaning of
v_specmountpoint when multiple mounts happen; does this matter?

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix


--- /usr/src/sys/sys/fcntl.h.orig   Mon Sep 13 15:21:29 1999
+++ /usr/src/sys/sys/fcntl.hMon Sep 13 17:04:46 1999
@@ -93,6 +93,7 @@
 #defineFMARK   0x1000  /* mark during gc() */
 #defineFDEFER  0x2000  /* defer for next gc pass */
 #defineFHASLOCK0x4000  /* descriptor holds advisory lock */
+#defineFMOUNTING   0x8000  /* a block device is being mounted */
 #endif
 
 /* Defined by POSIX 1003.1; BSD default, but must be distinct from O_RDONLY. */
--- /usr/src/sys/miscfs/specfs/spec_vnops.c.origMon Sep 13 17:11:17 1999
+++ /usr/src/sys/miscfs/specfs/spec_vnops.c Mon Sep 13 15:37:22 1999
@@ -229,7 +229,7 @@
 * Do not allow opens of block devices that are
 * currently mounted.
 */
-   error = vfs_mountedon(vp);
+   error = (ap->a_mode & FMOUNTING) ? 0 : vfs_mountedon(vp);
if (error)
return (error);
return ((*bdevsw[maj]->d_open)(dev, ap->a_mode, S_IFBLK, p));
--- /usr/src/sys/kern/vfs_subr.c.orig   Mon Sep 13 11:44:59 1999
+++ /usr/src/sys/kern/vfs_subr.cMon Sep 13 11:55:06 1999
@@ -1886,6 +1886,39 @@
simple_unlock(&spechash_slock);
return (count);
 }
+
+/*
+ * Calculate the total number of writers on a special device.
+ */
+int
+vwritecount(vp)
+   register struct vnode *vp;
+{
+   struct vnode *vq, *vnext;
+   int count;
+
+loop:
+   if ((vp->v_flag & VALIASED) == 0)
+   return (vp->v_writecount);
+   simple_lock(&spechash_slock);
+   for (count = 0, vq = *vp->v_hashchain; vq; vq = vnext) {
+   vnext = vq->v_specnext;
+   if (vq->v_rdev != vp->v_rdev || vq->v_type != vp->v_type)
+   continue;
+   /*
+* Alias, but not in use, so flush it out.
+*/
+   if (vq->v_writecount == 0 && vq != vp) {
+   simple_unlock(&spechash_slock);
+   vgone(vq);
+   goto loop;
+   }
+   count += vq->v_writecount;
+   }
+   simple_unlock(&spechash_slock);
+   return (count);
+}
+
 /*
  * Print out a description of a vnode.
  */
--- /usr/src/sys/ufs/ffs/ffs_vfsops.c.orig  Mon Sep 13 11:21:07 1999
+++ /usr/src/sys/ufs/ffs/ffs_vfsops.c   Mon Sep 13 17:08:23 1999
@@ -586,28 +586,33 @@
struct ucred *cred;
u_int64_t maxfilesize;  /* XXX */
size_t strsize;
-   int ncount;
+   int ncount, nwritecount;
 
dev = devvp->v_rdev;
cred = p ? p->p_ucred : NOCRED;
+   ronly = (mp->mnt_flag & MNT_RDONLY) != 0;
/*
-* Disallow multiple mounts of the same device.
+* Only allow multiple read-only mounts of the same device.
 * Disallow mounting of a device that is currently in use
 * (except for root, which might share swap device for miniroot).
 * Flush out any old buffers remaining from a previous use.
 */
-   error = vfs_mountedon(devvp);
+   error = ronly ? 0 : vfs_mountedon(devvp);
if (error)
return (error);
+   nwritecount = vwritecount(devvp);
+   if (nwritecount)
+   return (EBUSY);
ncount = vcount(devvp);
-
-   if (ncount > 1 && devvp != rootvp)
+   if (!ronly && ncount > 1 && devvp != rootvp)
return (EBUSY);
-   vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, p);
-   error = vinvalbuf(devvp, V_SAVE, cred, p, 0, 0);
-   VOP_UNLOCK(devvp, 0, p);
-   if (error)
-   return (error);
+   if (ncount <= 1) {
+   vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, p);
+   error = vinvalbuf(devvp, V_SAVE, cred, p, 0, 0);
+   VOP_UNLOCK(devvp, 0, p);
+   if (error)
+   return (error);
+   }
 
/*
 

Re: mounting a partition more than once

[Tony Finch]

Tony Finch  wrote:
>
>Is there a reason for disallowing concurrent read-only mounts of the
>same disk device? i.e. would things go pear-shaped if I added this
>capability? 

Well, in the absence of any comments I hacked around a bit and ended
up with the following patch (against 3.3-RC), which permits the same
block device to be mounted read-only more than once. The motivation
for this is to permit multiple chrooted environments to share the same
/usr partition.

Some things I wonder about this change is whether the mounts will share
the same pages in the buffer cache, and whether the resource
accounting is still right. I've subtly funted the meaning of
v_specmountpoint when multiple mounts happen; does this matter?

Tony.
-- 
f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix


--- /usr/src/sys/sys/fcntl.h.orig   Mon Sep 13 15:21:29 1999
+++ /usr/src/sys/sys/fcntl.hMon Sep 13 17:04:46 1999
@@ -93,6 +93,7 @@
 #defineFMARK   0x1000  /* mark during gc() */
 #defineFDEFER  0x2000  /* defer for next gc pass */
 #defineFHASLOCK0x4000  /* descriptor holds advisory 
lock */
+#defineFMOUNTING   0x8000  /* a block device is being 
mounted */
 #endif
 
 /* Defined by POSIX 1003.1; BSD default, but must be distinct from O_RDONLY. */
--- /usr/src/sys/miscfs/specfs/spec_vnops.c.origMon Sep 13 17:11:17 1999
+++ /usr/src/sys/miscfs/specfs/spec_vnops.c Mon Sep 13 15:37:22 1999
@@ -229,7 +229,7 @@
 * Do not allow opens of block devices that are
 * currently mounted.
 */
-   error = vfs_mountedon(vp);
+   error = (ap->a_mode & FMOUNTING) ? 0 : vfs_mountedon(vp);
if (error)
return (error);
return ((*bdevsw[maj]->d_open)(dev, ap->a_mode, S_IFBLK, p));
--- /usr/src/sys/kern/vfs_subr.c.orig   Mon Sep 13 11:44:59 1999
+++ /usr/src/sys/kern/vfs_subr.cMon Sep 13 11:55:06 1999
@@ -1886,6 +1886,39 @@
simple_unlock(&spechash_slock);
return (count);
 }
+
+/*
+ * Calculate the total number of writers on a special device.
+ */
+int
+vwritecount(vp)
+   register struct vnode *vp;
+{
+   struct vnode *vq, *vnext;
+   int count;
+
+loop:
+   if ((vp->v_flag & VALIASED) == 0)
+   return (vp->v_writecount);
+   simple_lock(&spechash_slock);
+   for (count = 0, vq = *vp->v_hashchain; vq; vq = vnext) {
+   vnext = vq->v_specnext;
+   if (vq->v_rdev != vp->v_rdev || vq->v_type != vp->v_type)
+   continue;
+   /*
+* Alias, but not in use, so flush it out.
+*/
+   if (vq->v_writecount == 0 && vq != vp) {
+   simple_unlock(&spechash_slock);
+   vgone(vq);
+   goto loop;
+   }
+   count += vq->v_writecount;
+   }
+   simple_unlock(&spechash_slock);
+   return (count);
+}
+
 /*
  * Print out a description of a vnode.
  */
--- /usr/src/sys/ufs/ffs/ffs_vfsops.c.orig  Mon Sep 13 11:21:07 1999
+++ /usr/src/sys/ufs/ffs/ffs_vfsops.c   Mon Sep 13 17:08:23 1999
@@ -586,28 +586,33 @@
struct ucred *cred;
u_int64_t maxfilesize;  /* XXX */
size_t strsize;
-   int ncount;
+   int ncount, nwritecount;
 
dev = devvp->v_rdev;
cred = p ? p->p_ucred : NOCRED;
+   ronly = (mp->mnt_flag & MNT_RDONLY) != 0;
/*
-* Disallow multiple mounts of the same device.
+* Only allow multiple read-only mounts of the same device.
 * Disallow mounting of a device that is currently in use
 * (except for root, which might share swap device for miniroot).
 * Flush out any old buffers remaining from a previous use.
 */
-   error = vfs_mountedon(devvp);
+   error = ronly ? 0 : vfs_mountedon(devvp);
if (error)
return (error);
+   nwritecount = vwritecount(devvp);
+   if (nwritecount)
+   return (EBUSY);
ncount = vcount(devvp);
-
-   if (ncount > 1 && devvp != rootvp)
+   if (!ronly && ncount > 1 && devvp != rootvp)
return (EBUSY);
-   vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, p);
-   error = vinvalbuf(devvp, V_SAVE, cred, p, 0, 0);
-   VOP_UNLOCK(devvp, 0, p);
-   if (error)
-   return (error);
+   if (ncount <= 1) {
+   vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, p);
+   error = vinvalbuf(devvp, V_SAVE, cred, p, 0, 0);
+   VOP_UNLOCK(devvp, 0, p);
+   if (error)
+   return (error);
+   }
 
/*
 * Only VMIO the backing de

mounting a partition more than once

[Tony Finch]

Is there a reason for disallowing concurrent read-only mounts of the
same disk device? i.e. would things go pear-shaped if I added this
capability? 

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix


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

mounting a partition more than once

[Tony Finch]

Is there a reason for disallowing concurrent read-only mounts of the
same disk device? i.e. would things go pear-shaped if I added this
capability? 

Tony.
-- 
f.a.n.finchf...@demon.netd...@dotat.ate pluribus unix


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

Re: damn ATX power supplies...

[Tony Finch]

Peter Wemm <[EMAIL PROTECTED]> wrote:
>
>On newer motherboards, it's addressable on the SMB bus (along with
>the SIMMS, the LM78/LM75/etc, the embedded LM75 in the newer CPU,
>etc). Anyway, the newer devices are programmable to do things like
>the 4-second power off delay, auto-on with AC, maintain previous
>state when AC restored, alarm clock time auto start, as well as the
>usual "turn off now" command from the APM bios.

Is there any software out there that speaks to /dev/smb?
intelligently? We have some Dell boxen with loads of SMB stuff in
them; it'd be nice to be able to see what's going on there.

Alternatively, are there freely-available SMB specs?

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix


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

Re: damn ATX power supplies...

[Tony Finch]

Peter Wemm  wrote:
>
>On newer motherboards, it's addressable on the SMB bus (along with
>the SIMMS, the LM78/LM75/etc, the embedded LM75 in the newer CPU,
>etc). Anyway, the newer devices are programmable to do things like
>the 4-second power off delay, auto-on with AC, maintain previous
>state when AC restored, alarm clock time auto start, as well as the
>usual "turn off now" command from the APM bios.

Is there any software out there that speaks to /dev/smb?
intelligently? We have some Dell boxen with loads of SMB stuff in
them; it'd be nice to be able to see what's going on there.

Alternatively, are there freely-available SMB specs?

Tony.
-- 
f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix


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

Re: Proposal: Add generic username for 3rd-party MTA's

[Tony Finch]

Sheldon Hearn  wrote:
>
>The numeric ID is not important. Neither is the name. So long as there's
>something that people maintaining ports can use. I've followed Solaris'
>lead on the choice of name, ``smtp''.

Hmm. One of my Solaris boxen has

mail:x:6:6:Unprivileged mail user:/:
smtp:x:0:0:Mail Daemon User:/:

(Presumably the smtp user is privileged in order to bind to port 25.)
I prefer user & group mail since it is non-cryptic and common.

Tony.
-- 
f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix


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

Re: Proposal: Add generic username for 3rd-party MTA's

[Tony Finch]

Sheldon Hearn <[EMAIL PROTECTED]> wrote:
>
>The numeric ID is not important. Neither is the name. So long as there's
>something that people maintaining ports can use. I've followed Solaris'
>lead on the choice of name, ``smtp''.

Hmm. One of my Solaris boxen has

mail:x:6:6:Unprivileged mail user:/:
smtp:x:0:0:Mail Daemon User:/:

(Presumably the smtp user is privileged in order to bind to port 25.)
I prefer user & group mail since it is non-cryptic and common.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix


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

Re: BSD XFS Port & BSD VFS Rewrite

[Tony Finch]

Terry Lambert  wrote:
>
>Has anyone mentioned to them that they will be unable to incorporate
>changes made to the GPL'ed version of XFS back into the IRIX version
>of XFS, without IRIX becoming GPL'ed?

That is not correct: if SGI only use code that they have full
ownership of in IRIX then they can distribute it separately under the
GPL without releasing the source to the rest of the OS. It's perfectly
valid to distribute software to different people under different
licences (e.g. softupdates, perl).

Tony.
-- 
f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix


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

Re: BSD XFS Port & BSD VFS Rewrite

[Tony Finch]

Terry Lambert <[EMAIL PROTECTED]> wrote:
>
>Has anyone mentioned to them that they will be unable to incorporate
>changes made to the GPL'ed version of XFS back into the IRIX version
>of XFS, without IRIX becoming GPL'ed?

That is not correct: if SGI only use code that they have full
ownership of in IRIX then they can distribute it separately under the
GPL without releasing the source to the rest of the OS. It's perfectly
valid to distribute software to different people under different
licences (e.g. softupdates, perl).

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix


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

Re: (2) hey

[Tony Finch]

Doug  wrote:
>
>Nothing in either RFC that you quoted, or any of your examples
>contradicted my actual point, which was that PTR records are not
>valid outside of in-addr.arpa name space.

AFAICT the second example I gave has a valid PTR record outside
in-addr.arpa. To give you a more concrete example I've reconfigured
the reverse DNS for dotat.at to change some time after midnight UTC to
use the RR "rev.dotat.at. PTR dotat.at."

>If you believe they are, give valid working examples and explain
>their meaning, since there currently is not a definition for their
>use outside of in-addr.arpa.

It means that rev.dotat.at points to dotat.at. When the
134.240.212.in-addr.arpa zone updates itself rev.dotat.at will be the
canonical name for 130.134.240.212.in-addr.arpa so reverse lookups
will work as expected.

You might also want to look at RFC 1886 which defines the ip6.int
domain, which like in-addr.arpa is full of PTR RRs.

Tony.
-- 
f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix


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

Re: (2) hey

[Tony Finch]

Doug <[EMAIL PROTECTED]> wrote:
>
>Nothing in either RFC that you quoted, or any of your examples
>contradicted my actual point, which was that PTR records are not
>valid outside of in-addr.arpa name space.

AFAICT the second example I gave has a valid PTR record outside
in-addr.arpa. To give you a more concrete example I've reconfigured
the reverse DNS for dotat.at to change some time after midnight UTC to
use the RR "rev.dotat.at. PTR dotat.at."

>If you believe they are, give valid working examples and explain
>their meaning, since there currently is not a definition for their
>use outside of in-addr.arpa.

It means that rev.dotat.at points to dotat.at. When the
134.240.212.in-addr.arpa zone updates itself rev.dotat.at will be the
canonical name for 130.134.240.212.in-addr.arpa so reverse lookups
will work as expected.

You might also want to look at RFC 1886 which defines the ip6.int
domain, which like in-addr.arpa is full of PTR RRs.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix


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

Re: (2) hey

[Tony Finch]

Doug  wrote:
>Louis A. Mamakos wrote:
>>[lost attribution]
>>> 
>>> That IS a violation of the standard, since A records are not valid
>>> for hosts in in-addr.arpa.
>> 
>> And next I suppose you'll tell me that PTR records are not valid
>> outsize of the IN-ADDR.ARPA portion of the DNS namespace?
>
> Given how PTR RR's are defined, I'd have to say, ayyup. 

I suggest you read RFC 2317 (classless reverse DNS). Among its
recommendations are setups like:

130.134.240.212.in-addr.arpa.CNAME 130.128/28.134.240.212.in-addr.arpa.
130.128/28.134.240.212.in-addr.arpa. PTR   dotat.at.

and:

130.134.240.212.in-addr.arpa. CNAME 130.rev.dotat.at.
130.rev.dotat.at  PTR   dotat.at.

RFC 2181 allows the / in the CNAME RRs. There's no reason for
restricting PTR RRs to a particular part of the name space, and indeed
this example shows that doing so can make administration unnecessarily
harder.

The real reverse DNS for dotat.at uses this more conservative setup:

130.134.240.212.in-addr.arpa.CNAME 130.128-28.134.240.212.in-addr.arpa.
130.128-28.134.240.212.in-addr.arpa. PTR   dotat.at.

Tony.
-- 
f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix


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

Re: (2) hey

[Tony Finch]

Doug <[EMAIL PROTECTED]> wrote:
>Louis A. Mamakos wrote:
>>[lost attribution]
>>> 
>>> That IS a violation of the standard, since A records are not valid
>>> for hosts in in-addr.arpa.
>> 
>> And next I suppose you'll tell me that PTR records are not valid
>> outsize of the IN-ADDR.ARPA portion of the DNS namespace?
>
> Given how PTR RR's are defined, I'd have to say, ayyup. 

I suggest you read RFC 2317 (classless reverse DNS). Among its
recommendations are setups like:

130.134.240.212.in-addr.arpa.CNAME 130.128/28.134.240.212.in-addr.arpa.
130.128/28.134.240.212.in-addr.arpa. PTR   dotat.at.

and:

130.134.240.212.in-addr.arpa. CNAME 130.rev.dotat.at.
130.rev.dotat.at  PTR   dotat.at.

RFC 2181 allows the / in the CNAME RRs. There's no reason for
restricting PTR RRs to a particular part of the name space, and indeed
this example shows that doing so can make administration unnecessarily
harder.

The real reverse DNS for dotat.at uses this more conservative setup:

130.134.240.212.in-addr.arpa.CNAME 130.128-28.134.240.212.in-addr.arpa.
130.128-28.134.240.212.in-addr.arpa. PTR   dotat.at.

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix


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

Re: mmap bug

[Tony Finch]

Matthew Dillon  wrote:
>
>One solution would be to map clean R+W pages RO and force a write fault
>to occur, allowing the system to recognize that there are too many dirty
>pages in vm_fault before it is too late and flush some of them.  The
>downside of this is that, of course, we take unnecessary faults.

Surely they aren't unnecessary faults if they are required for correctness?

Tony.
-- 
f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix


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

Re: mmap bug

[Tony Finch]

Matthew Dillon <[EMAIL PROTECTED]> wrote:
>
>One solution would be to map clean R+W pages RO and force a write fault
>to occur, allowing the system to recognize that there are too many dirty
>pages in vm_fault before it is too late and flush some of them.  The
>downside of this is that, of course, we take unnecessary faults.

Surely they aren't unnecessary faults if they are required for correctness?

Tony.
-- 
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix


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