|
|
|
|
|
|
| Author |
Message |
server
*nix forums addict
Joined: 19 Feb 2005
Posts: 60
|
 Posted: Tue Mar 19, 2002 8:42 pm Post subject:
__P(()) Macro
|
|
|
|
message unavailable |
|
| Back to top |
|
 |
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Tue Mar 19, 2002 8:42 pm Post subject:
Re: __P(()) Macro
|
|
|
Kirk McKusick wrote:
| Quote: | OpenBSD has completed the cleanup of the __P(()) macro.
While we have agreed in principle to do the same, I note
many instances of __P(()) still exist. Hopefully someone
will take the bull by the horns and grunt through this task.
Kirk McKusick
|
I assume that only someone with -current sources could do
this? I.e. the delta is only applicable against -current,
not -stable, so it will be a 5.0 thing, not a 4.6 thing?
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Kirk McKusick
*nix forums beginner
Joined: 19 Mar 2002
Posts: 40
|
| Posted: Tue Mar 19, 2002 9:13 pm Post subject:
Re: __P(()) Macro
|
|
|
Date: Tue, 19 Mar 2002 13:42:09 -0800
From: Terry Lambert <tlambert2@mindspring.com>
To: Kirk McKusick <mckusick@mckusick.com>
CC: arch@freebsd.org
Subject: Re: __P(()) Macro
Kirk McKusick wrote:
| Quote: | > OpenBSD has completed the cleanup of the __P(()) macro.
> While we have agreed in principle to do the same, I note
> many instances of __P(()) still exist. Hopefully someone
> will take the bull by the horns and grunt through this task.
> Kirk McKusick
|
I assume that only someone with -current sources could do
this? I.e. the delta is only applicable against -current,
not -stable, so it will be a 5.0 thing, not a 4.6 thing?
-- Terry
It would be my assumption that this would only happen in the
5.0 tree.
Kirk
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Kirk McKusick
*nix forums beginner
Joined: 19 Mar 2002
Posts: 40
|
| Posted: Tue Mar 19, 2002 9:17 pm Post subject:
Re: __P(()) Macro
|
|
|
Date: Tue, 19 Mar 2002 14:21:16 -0800
From: Alfred Perlstein <bright@mu.org>
To: Kirk McKusick <mckusick@beastie.mckusick.com>
Cc: Terry Lambert <tlambert2@mindspring.com>, arch@freebsd.org
Subject: Re: __P(()) Macro
* Kirk McKusick <mckusick@beastie.mckusick.com> [020319 14:20] wrote:
| Quote: | > Date: Tue, 19 Mar 2002 13:42:09 -0800
> From: Terry Lambert <tlambert2@mindspring.com
> To: Kirk McKusick <mckusick@mckusick.com
> CC: arch@freebsd.org
> Subject: Re: __P(()) Macro
> Kirk McKusick wrote:
> > OpenBSD has completed the cleanup of the __P(()) macro.
> > While we have agreed in principle to do the same, I note
> > many instances of __P(()) still exist. Hopefully someone
> > will take the bull by the horns and grunt through this task.
>
> > Kirk McKusick
> I assume that only someone with -current sources could do
> this? I.e. the delta is only applicable against -current,
> not -stable, so it will be a 5.0 thing, not a 4.6 thing?
> -- Terry
> It would be my assumption that this would only happen in the
> 5.0 tree.
|
I'm making the sweep through the kernel now, may I touch ufs/ffs
or would that hinder your current devel?
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
You may do ufs/*. I can handle the change.
~Kirk
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Alfred Perlstein
*nix forums addict
Joined: 19 Mar 2002
Posts: 67
|
| Posted: Tue Mar 19, 2002 9:21 pm Post subject:
Re: __P(()) Macro
|
|
|
* Kirk McKusick <mckusick@beastie.mckusick.com> [020319 14:20] wrote:
| Quote: | Date: Tue, 19 Mar 2002 13:42:09 -0800
From: Terry Lambert <tlambert2@mindspring.com
To: Kirk McKusick <mckusick@mckusick.com
CC: arch@freebsd.org
Subject: Re: __P(()) Macro
Kirk McKusick wrote:
> OpenBSD has completed the cleanup of the __P(()) macro.
> While we have agreed in principle to do the same, I note
> many instances of __P(()) still exist. Hopefully someone
> will take the bull by the horns and grunt through this task.
> Kirk McKusick
I assume that only someone with -current sources could do
this? I.e. the delta is only applicable against -current,
not -stable, so it will be a 5.0 thing, not a 4.6 thing?
-- Terry
It would be my assumption that this would only happen in the
5.0 tree.
|
I'm making the sweep through the kernel now, may I touch ufs/ffs
or would that hinder your current devel?
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Julian Elischer
*nix forums Guru Wannabe
Joined: 20 Mar 2002
Posts: 279
|
| Posted: Wed Mar 20, 2002 9:31 pm Post subject:
Re: UFS2, GEOM & DARPA - don't get all excited, OK ?
|
|
|
One thing to look at:
Inode in dirent allocation..
there was a Usenix paper on this ..
It made a huge performance difference in some cases..
on the first link (one link to file only), you stash the inode
info into the dir. On creation of a 2nd link you actually allocate an
inode.
-------In the 1997 Usenix technical conference proceedings:----------
"Embedded inodes and Explicit Grouping: Exploiting Disk bandwidth
for small files"
Gregory R Ganger, M.Frans Kaashoek. MIT
-----------------------------
This paper actually describes several improvements to FFS, including
the one I mentionned above.
Kirk of course knows about this, but it should be compatible with Greg's
soft-updates work, and would be very cool to have..
All the work for the paper was done for FFS under OpenBSD
so it should be directly relevent. (It would be interesting to ask
Greg if we would be interested at all in participating in an FFS
rewrite because he's only second to Kirk on the topic, even if only on a
consultation basis)
On Wed, 20 Mar 2002, Poul-Henning Kamp wrote:
[NON-Text Body part not included]
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Wed Mar 20, 2002 9:47 pm Post subject:
Re: UFS2, GEOM & DARPA - don't get all excited, OK ?
|
|
|
Julian Elischer wrote:
| Quote: | One thing to look at:
Inode in dirent allocation..
there was a Usenix paper on this ..
It made a huge performance difference in some cases..
|
Microsoft has an approach simialt to this.
The call it "The FAT Filesystem".
8-)  .
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Wed Mar 20, 2002 11:37 pm Post subject:
Re: UFS2, GEOM & DARPA - don't get all excited, OK ?
|
|
|
Julian Elischer wrote:
| Quote: | On Wed, 20 Mar 2002, Terry Lambert wrote:
Julian Elischer wrote:
One thing to look at:
Inode in dirent allocation..
there was a Usenix paper on this ..
It made a huge performance difference in some cases..
Microsoft has an approach simialt to this.
The call it "The FAT Filesystem".
8-) .
haha
read the papaer.
http://www.pdos.lcs.mit.edu/pubs.html
under "Storage management"
|
Haha.
Personally, I prefer PDF:
http://citeseer.nj.nec.com/ganger97embedded.html
Also, read the earlier paper about the same thing:
http://www.usenix.org/publications/library/proceedings/sf94/forin.html
It's well known that making the directory entry into the
inode works really well, particularly when you handicap
the caching (as they did in the earlier MACH paper, in an
apparent attempt to make their numbers better).
You can get the same improvement in FFS by faulting in the
inodes when you do a directory traversal, so that when you
go to open/stat the inodes, they are already in core.
This was one of the basis of the paper that I, Ed Lane,
and Bryan Cardoza weren't allowed to present in 1994 because
of the USL lawsuit, after the USL acquisition by Novell.
You can also get a big improvement by returning stat
information each time it is changed, and with "open" and
other calls, particularly when you are implementing a
file system server.
Also, one of the earliest technical discussions we had on
FS issues at Whistle dealt with actually allocating reference
nodes for hard links, which, among other things, results in
a different vnode per reference path, which has the effect
of making parent pointers reliable (e.g. "fdgetpath()" can
be made to work).
If you look at the MD-DOS MACH FS paper from 1194, their
assumptions are obviously the wrong things to do: they had
to slow down FFS for their MS-DOS FS to beat it, including
caching all the FAT blocks in core. It's pretty trivial to
get a locality based cache of directory and inode blocks
in the FFS case, as well, to get similar performance.
Actually, this approach should be obvious from the NetWare
NWFS approach in Native NetWare, which has a RAM requirement
proportional to the disk size for mounts because the directory
structure is cached in core in its entirety.
Right now, FreeBSD does somewhat the wrong thing, in not
resulting in pages being faulted in when a non-blocking
availability check occurs (e.g. a check on something that
will not block if the data is not available, but triggers
a prefetch). The FreeBSD non-blocking I/O implementation
actually suffers because of this, since you really want
unavailable disk data to result in a fault and a conversion,
rather than blocking.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Julian Elischer
*nix forums Guru Wannabe
Joined: 20 Mar 2002
Posts: 279
|
| Posted: Wed Mar 20, 2002 11:57 pm Post subject:
Re: UFS2, GEOM & DARPA - don't get all excited, OK ?
|
|
|
haha
read the papaer.
http://www.pdos.lcs.mit.edu/pubs.html
under "Storage management"
On Wed, 20 Mar 2002, Terry Lambert wrote:
| Quote: | Julian Elischer wrote:
One thing to look at:
Inode in dirent allocation..
there was a Usenix paper on this ..
It made a huge performance difference in some cases..
Microsoft has an approach simialt to this.
The call it "The FAT Filesystem".
8-) .
-- Terry
|
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Poul-Henning Kamp
*nix forums Guru
Joined: 21 Mar 2002
Posts: 436
|
| Posted: Thu Mar 21, 2002 5:00 am Post subject:
Re: UFS2, GEOM & DARPA - don't get all excited, OK ?
|
|
|
In message <Pine.BSF.4.21.0203201313500.6793-100000@InterJet.elischer.org>, Jul
ian Elischer writes:
| Quote: |
One thing to look at:
Inode in dirent allocation..
there was a Usenix paper on this ..
It made a huge performance difference in some cases..
|
That is why I specifically said that we are not going to do it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Mark Murray
*nix forums beginner
Joined: 24 Mar 2002
Posts: 49
|
| Posted: Sun Mar 24, 2002 4:14 pm Post subject:
Re: Why isn't __progname declared in a header?
|
|
|
| Quote: | Next question, what header should it go into? I'm quite happy to do
the work.
libc/include/libc_private.h is almost right.
Hmm. It is implemented in csu/*/crt[01].c, so how about
csu/common/_progname.h?
Further from being almost right. It would be a new header with very little
in it, and isn't in libc's tree any more than libc's header is in csu's
tree.
|
So what direction do I go in the get it closer to "right"?
__progname is implemented in csu/, so it make sense for me to have
its header there. Only two files in any other library
(lib/libc/gen/[gs]etprogname.c) actually need this information, so it
makes sense (to me anyway) for them to have some kind of special
case to get it. I don't like a plain declaration, as that makes
diverting declarations (more) possible.
M
--
o Mark Murray
\_
O.\_ Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Garance A Drosihn
*nix forums Guru Wannabe
Joined: 21 Mar 2002
Posts: 190
|
| Posted: Mon Apr 01, 2002 2:46 am Post subject:
Re: UFS snapshots in current
|
|
|
At 9:48 PM -0500 3/31/02, Robert Watson wrote:
| Quote: | On Sun, 31 Mar 2002, Garance A Drosihn wrote:
Hmm. Is there any way for a regular user-land process to
tell if a given file is a snapshot? Something in the stat()
info, or some other way to tell?
Look for the SF_SNAPSHOT flag. I don't recall if this is
exported via the flags field via stat(), but it may well be.
|
It looks like it is. In fact, it looks like we could just
change fflagstostr() to check for it, and 'ls -lo' would show
'snap' in the field of interesting flags. This might be a
good idea, since a snapshot file is (I assume) truly
read-only. (I assume it's like schg, except that you can't
even use chflags to make it writable).
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Brian Somers
*nix forums beginner
Joined: 04 Apr 2002
Posts: 14
|
| Posted: Thu Apr 04, 2002 3:17 pm Post subject:
Re: Your change to in.c to limit duplicate networks is causing trouble
|
|
|
I've crossposted to -net and -arch as this could probably do with a
review from a larger audience....
| Quote: | Brian Somers writes:
| > In message: <20020325172024.B60771@uriah.heep.sax.de
| > Joerg Wunsch <j@uriah.heep.sax.de> writes:
| > : As Alan Clegg wrote:
| > :
| > : > Is there any motion to pull this back?
| > :
| > : There was only consensus to special-case the BOOTP case.
| > :
| > : As i understand it, the change itself was more than desirable for
| > : PPP connections (so no surprise it was Brian who committed it).
|
| > dhclient is still broken, however. The 0.0.0.0 should be the special
| > case, not bootp.
|
| Yes, I agree.
|
| The question is.... should interface address assignments with
| destinations of 0.0.0.0 have host routes created in the first place ?
|
| I'd tend to think not.
|
| Doing this will make things consistent, but maybe at the expense of
| breaking something else - under ``usual'' circumstances. I'm
| thinking along the lines of some program that may configure a
| destination address of 0.0.0.0 and then expect to be able to do stuff
| with the routing table - such as adding a route via 0.0.0.0 or calling
| sendto() or connect() with 0.0.0.0 as the destination.
|
| I'm guessing that dhclient will continue to work without a host route
| as it writes raw IP packets, and I haven't heard of any problems with
| running multiple dhclients using the old in.c code where second and
| subsequent SIOCAIADDRs with a 0.0.0.0 destination had no host route.
| I haven't tested it yet though.
|
| If nobody objects, I'll tweak things so that destinations of 0.0.0.0
| don't add host routes and see if it breaks anything I know of. I'll
| post patches to -arch and cc -net when I get something working.
Sounds reasonable. I can test it when you have something since I'm hitting
this on a few machines around here.
Doug A.
|
The attached patches seem to make things work for BOOTP with multiple
interfaces and for ppp expecting failures for duplicate destination
address assignments.
The code now avoids adding a host route if the interface address is
0.0.0.0, and always treats a failure to add a host route as fatal
(previously, it masked EEXIST for some reason - I guessed because it
was trying to handle address re-assignment, but that works ok with
this patch).
If people could get some time to review it, it'd be appreciated.
Cheers.
--
Brian <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org>
Index: netinet/in.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/in.c,v
retrieving revision 1.63
diff -u -r1.63 in.c
--- netinet/in.c 1 Apr 2002 21:31:06 -0000 1.63
+++ netinet/in.c 4 Apr 2002 16:52:59 -0000
@@ -661,7 +661,7 @@
{
register u_long i = ntohl(sin->sin_addr.s_addr);
struct sockaddr_in oldaddr;
- int s = splimp(), flags = RTF_UP, error;
+ int s = splimp(), flags = RTF_UP, error = 0;
oldaddr = ia->ia_addr;
ia->ia_addr = *sin;
@@ -723,17 +723,21 @@
return (0);
flags |= RTF_HOST;
}
- if ((error = rtinit(&(ia->ia_ifa), (int)RTM_ADD, flags)) == 0)
- ia->ia_flags |= IFA_ROUTE;
- if (error != 0 && ia->ia_dstaddr.sin_family == AF_INET) {
- ia->ia_addr = oldaddr;
- return (error);
+ /*
+ * Don't add routing table entries for interface address entries
+ * of 0.0.0.0. This makes it possible to assign several such address
+ * pairs with consistent results (no host route) and is required by
+ * BOOTP.
+ */
+ if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY) {
+ if ((error = rtinit(&ia->ia_ifa, (int)RTM_ADD, flags)) != 0) {
+ ia->ia_addr = oldaddr;
+ return (error);
+ }
+ ia->ia_flags |= IFA_ROUTE;
}
- /* XXX check if the subnet route points to the same interface */
- if (error == EEXIST)
- error = 0;
/*
* If the interface supports multicast, join the "all hosts"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Joerg Wunsch
*nix forums beginner
Joined: 04 Apr 2002
Posts: 1
|
| Posted: Thu Apr 04, 2002 5:58 pm Post subject:
Re: Your change to in.c to limit duplicate networks is causing trouble
|
|
|
As Brian Somers wrote:
| Quote: | The code now avoids adding a host route if the interface address is
0.0.0.0, and always treats a failure to add a host route as fatal
(previously, it masked EEXIST for some reason - I guessed because it
was trying to handle address re-assignment, but that works ok with
this patch).
|
I think that will be fatal for the sppp case with dynamic IP
address negotiation. We use 0.0.0.0 as the local IP address
for the unnegotiated PPP link then, with the idea that it's
still possible to route through the interface anyway. For
dial-on-demand PPP links (like on ISDN), the routed packets
will then trigger the dialout event. In the course of the
PPP negotiations, an actual local IP address will be negotiated
and assigned, but we first need some packets to pass through the
PPP layer in order to trigger this.
Perhaps it would still be possible to use per-interface routes
even after your change (-iface isp0 etc.), but currently, a number
of documents describe that it's possible to use local address
0.0.0.0 and still get normal routing behaviour for those links.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
stephen macmanus
*nix forums beginner
Joined: 04 Apr 2002
Posts: 2
|
| Posted: Thu Apr 04, 2002 7:10 pm Post subject:
Re: Your change to in.c to limit duplicate networks is causing trouble
|
|
|
| Quote: | The code now avoids adding a host route if the interface address is
0.0.0.0, and always treats a failure to add a host route as fatal
(previously, it masked EEXIST for some reason - I guessed because it
was trying to handle address re-assignment, but that works ok with
this patch).
|
One effect of the masked EEXIST is to suppress the spurious error
which occurs when adding an alias IP address (SIOCAIFADDR) on the
same logical subnet as an existing IP address. Users have no way
of knowing that it's actually safe to simply ignore the error in
that situation, so the masking should probably be preserved.
Stephen
------------------
Stephen Macmanus #include <std_disclaimer.h>
stephenm@bayarea.net
- - - if ((error = rtinit(&(ia->ia_ifa), (int)RTM_ADD, flags)) == 0)
- - - ia->ia_flags |= IFA_ROUTE;
- - - if (error != 0 && ia->ia_dstaddr.sin_family == AF_INET) {
- - - ia->ia_addr = oldaddr;
- - - return (error);
+ /*
+ * Don't add routing table entries for interface address entries
+ * of 0.0.0.0. This makes it possible to assign several such address
+ * pairs with consistent results (no host route) and is required by
+ * BOOTP.
+ */
+ if (ia->ia_addr.sin_addr.s_addr != INADDR_ANY) {
+ if ((error = rtinit(&ia->ia_ifa, (int)RTM_ADD, flags)) != 0) {
+ ia->ia_addr = oldaddr;
+ return (error);
+ }
+ ia->ia_flags |= IFA_ROUTE;
}
- - - /* XXX check if the subnet route points to the same interface */
- - - if (error == EEXIST)
- - - error = 0;
/*
* If the interface supports multicast, join the "all hosts"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Tue Dec 02, 2008 5:50 am | All times are GMT
|
|
Nutritional Supplements | Mortgage Calculator | Myspace Layouts | Работа в Канаде | Debt Consolidation
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
