Re: Should URL's be pervasive.
Oh god, as everybody else is saying, I can't believe I'm getting involved in this, but... On Fri, Aug 31, 2001 at 09:58:21AM -0700, a little birdie told me that Richard Hodges remarked > > Why not parse it literally? For instance, http://www.ufp.org > would imply TCP, dest port 80, and host www.ufp.org. > > For ping, that would imply that I want to test the three-way > handshake on whatever is listening on port 80 at www.ufp.org > > For traceroute, I want to send a series of TCP SYN packets to > www.ufp.org, port 80 with increasing TTL values. Perhaps this No, it doesn't. http://www.ufp.org/ does NOT mean TCP port 80. www.ufp.org:80 means port 80, I don't know of any simple common way to say TCP. http://www.ufp.org/ means the host 'www.ufp.org' using the protocol 'http' with the TCP port 80 implicity as a result of the 'http'. Traceroute is not going to use HTTP. Ping is not going to use HTTP. Rpcinfo is not going to use HTTP. A mail client is not going to use HTTP (this one is perhaps debatable, but I'm sure as hell not going there). If you want to take a URI passed to 'ping', say, and parse out a hostname, that's one thing which I'm sure we could have endless disagreement about. But doing that is *NOT* parsing it as a URI. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
gzipped crashdumps
Anyone else think this patch from NetBSD is worthwhile?
Should I also extend it to support bzip2'ed dumps now that that's in
the base system, or would that be overkill?
Kris
Index: Makefile
===
RCS file: /mnt/ncvs/src/sbin/savecore/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- Makefile2001/03/26 14:33:23 1.5
+++ Makefile2001/09/01 08:15:14
@@ -5,8 +5,7 @@
SRCS= savecore.c zopen.c
MAN= savecore.8
-ZOPENPATH= ${.CURDIR}/../../usr.bin/compress
-.PATH: ${ZOPENPATH}
-CFLAGS+= -I${ZOPENPATH}
+DPADD+=${LIBZ}
+LDADD+=-lz
.include
Index: savecore.8
===
RCS file: /mnt/ncvs/src/sbin/savecore/savecore.8,v
retrieving revision 1.12
diff -u -r1.12 savecore.8
--- savecore.8 2001/07/10 11:02:27 1.12
+++ savecore.8 2001/09/01 08:11:50
@@ -72,7 +72,7 @@
Print out some additional debugging information.
.It Fl z
Compress the core dump and kernel (see
-.Xr compress 1 ) .
+.Xr gzip 1 ) .
.El
.Pp
.Nm Savecore
@@ -113,8 +113,8 @@
.Sh BUGS
The minfree code does not consider the effect of compression.
.Sh SEE ALSO
-.Xr compress 1 ,
.Xr getbootfile 3 ,
+.Xr gzip 1 ,
.Xr syslogd 8
.Sh HISTORY
The
Index: savecore.c
===
RCS file: /mnt/ncvs/src/sbin/savecore/savecore.c,v
retrieving revision 1.41
diff -u -r1.41 savecore.c
--- savecore.c 2001/06/09 01:41:03 1.41
+++ savecore.c 2001/09/01 08:06:48
@@ -63,8 +63,9 @@
#include
#include
#include
-#include "zopen.h"
+extern FILE *zopen(const char *fname, const char *mode);
+
#ifdef __alpha__
#define ok(number) ALPHA_K0SEG_TO_PHYS(number)
#endif
@@ -131,7 +132,7 @@
int get_crashtime __P((void));
voidget_dumpsize __P((void));
voidkmem_setup __P((void));
-voidlog __P((int, char *, ...));
+voidlog __P((int, char *, ...)) __printf0like(2, 3);
voidLseek __P((int, off_t, int));
int Open __P((const char *, int rw));
int Read __P((int, void *, int));
@@ -384,9 +385,9 @@
/* Create the core file. */
oumask = umask(S_IRWXG|S_IRWXO); /* Restrict access to the core file.*/
(void)snprintf(path, sizeof(path), "%s/vmcore.%d%s",
- savedir, bounds, compress ? ".Z" : "");
+ savedir, bounds, compress ? ".gz" : "");
if (compress)
- fp = zopen(path, "w", 0);
+ fp = zopen(path, "w");
else
fp = fopen(path, "w");
if (fp == NULL) {
@@ -463,9 +464,9 @@
/* Copy the kernel. */
ifd = Open(kernel ? kernel : getbootfile(), O_RDONLY);
(void)snprintf(path, sizeof(path), "%s/kernel.%d%s",
- savedir, bounds, compress ? ".Z" : "");
+ savedir, bounds, compress ? ".gz" : "");
if (compress)
- fp = zopen(path, "w", 0);
+ fp = zopen(path, "w");
else
fp = fopen(path, "w");
if (fp == NULL) {
--- /dev/null Sat Sep 1 01:13:34 2001
+++ zopen.c Sat Sep 1 01:10:14 2001
@@ -0,0 +1,39 @@
+/*
+ * Public domain stdio wrapper for libz, written by Johan Danielsson.
+ */
+
+#ifndef lint
+static const char rcsid[] =
+ "$FreeBSD$";
+#endif /* not lint */
+
+#include
+#include
+
+FILE *zopen(const char *fname, const char *mode);
+
+/* convert arguments */
+static int
+xgzread(void *cookie, char *data, int size)
+{
+return gzread(cookie, data, size);
+}
+
+static int
+xgzwrite(void *cookie, const char *data, int size)
+{
+return gzwrite(cookie, (void*)data, size);
+}
+
+FILE *
+zopen(const char *fname, const char *mode)
+{
+gzFile gz = gzopen(fname, mode);
+if(gz == NULL)
+ return NULL;
+
+if(*mode == 'r')
+ return (funopen(gz, xgzread, NULL, NULL, gzclose));
+else
+ return (funopen(gz, NULL, xgzwrite, NULL, gzclose));
+}
PGP signature
Ipnat device problems
Hello, since I recompiled my system and my kernel, ipnat device doesn't work anymore: #ipnat /dev/ipnat: open: Device not configured #ipfstat open: Device not configured ... I've got in kernel config: options IPFILTER#ipfilter support options IPFILTER_LOG#ipfilter logging options IPFIREWALL options IPFIREWALL_VERBOSE_LIMIT=100#limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT I didn't forget to do a mergemaster (it does the MAKEDEV all). Someone has got an idea ? Best regards, Chojin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote: > > I see (amost). > > > > Please format the macro the same as the other macros in the file. > > Index: apic_vector.s > === > RCS file: /home/ncvs/src/sys/i386/isa/apic_vector.s,v > retrieving revision 1.47.2.4 > diff -u -r1.47.2.4 apic_vector.s > --- apic_vector.s 18 Jul 2000 21:12:41 - 1.47.2.4 > +++ apic_vector.s 31 Aug 2001 19:24:24 - > @@ -653,7 +707,14 @@ > FAST_INTR(21,fastintr21) > FAST_INTR(22,fastintr22) > FAST_INTR(23,fastintr23) > -#define CLKINTR_PENDING movl $1,CNAME(clkintr_pending) > + > +#define CLKINTR_PENDING \ > + pushl $clock_lock; \ > + call s_lock;\ > + movl $1,CNAME(clkintr_pending); \ > + call s_unlock; \ > + addl $4, %esp > + > INTR(0,intr0, CLKINTR_PENDING) > INTR(1,intr1,) > INTR(2,intr2,) > The other macros also have a space befor the semicolons :). Otherwise OK. Better commit this (especially to 4.4R) until we have something better. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
:q:q![kevin.way@overtone.org: Re: import NetBSD rc system]
- Forwarded message from Kevin Way <[EMAIL PROTECTED]> - Date: Tue, 14 Aug 2001 06:34:26 + From: Kevin Way <[EMAIL PROTECTED]> To: Gordon Tetlow <[EMAIL PROTECTED]> Subject: Re: import NetBSD rc system On Mon, Aug 13, 2001 at 11:10:43PM -0700, Gordon Tetlow wrote: > Here's my big question. Do we try to maintain our boot order? Or are we > going to go with the boot order as presented by the NetBSD stuff? I don't see any reason to force the boot order to be maintained. As long as the dependancies are set correctly, i'd think the boot order would be determined solely by the output of rcorder. What am I missing? -Kevin Way - End forwarded message - -- If it weren't for my horse, I wouldn't have spent that year in college. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD Monthly Development Status Report -- Request For Submissions
It's that time again! I'm in the process of preparing the August, 2001 FreeBSD monthly status report, and as such am interested in seeing submissions in much the same style as previous months. Generally, this means about one paragraph of text per project describing events that have occured since the last status report (or two paragraphs for new projects, so as to introduce them). Large projects can be broken down into multiple sub-projects with seperate reports reports. If multiple developers are working on the same project, they should coordinate so as to submit only one report (or split it up into parts as appropriate along logical boundaries). Reports should relate to the FreeBSD Project, but are not limited to on-going software development: documentation, public relations, management, application developer relations, technology transfer, etc, are all relevant. Please submit reports in the following format: Project: (name here -- required field) URL: (URL, if any, here -- omit field if none) Contact: (name and e-mail address of one or more contact points -- required field) One paragraph on the topic of project status since the last report, indented two spaces, and wrapped at column 78. Plain text only, please. Please send submissions to: [EMAIL PROTECTED] The deadline for submissions is September 7, 2001, at 3:00pm EST. The report will be released soon thereafter. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Monthly Development Status Report -- Request For Submissions
On Sat, Sep 01, 2001 at 11:19:47AM -0400, Robert Watson wrote: > > It's that time again! I'm in the process of preparing the August, 2001 ^^ September one probably ;) Joe PGP signature
Re: FreeBSD Monthly Development Status Report -- Request For Submissions
On Sat, Sep 01, 2001 at 04:57:26PM +0100, Josef Karthauser wrote: > On Sat, Sep 01, 2001 at 11:19:47AM -0400, Robert Watson wrote: > > > > It's that time again! I'm in the process of preparing the August, 2001 > ^^ > September one probably ;) Ah no. My error. You're doing them retrospective aren't you? :) Sorry, Joe PGP signature
Re: Should URL's be pervasive.
On Fri, Aug 31, 2001 at 12:11:30AM +0400, [EMAIL PROTECTED] wrote: > Laurence Berland writes: > > Optimally, you could write a urlsh or something, and leave everyone else > > alone. The shell could do substitutions on URLs just like they do on > > wildcards etc, and the applications would not need to be rewritten, plus > > you wouldn't add bloat to those of us who don't want this in the system... > It is possible if interfaces of utilities is fully standartized. > For example -p flag in any command means port number. Actually, that's not true. The scp manpage says: -p Preserves modification times, access times, and modes from the original file. Also, tar has the same flag with the same meaning. > Such as > > mutt -l user -h host.domain > > as legal alternative of > > mutt [EMAIL PROTECTED] > [snip] > > -- > @BABOLO http://links.ru/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- --Spike Gronim [EMAIL PROTECTED] "Oh yes? An obscene triangle which, has more courage than the word." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should URL's be pervasive.
On Fri, Aug 31, 2001 at 02:15:09PM -0400, Michael Sinz wrote:
>
> I too have been hoping for (and building internal tools) that work
> this way. I really wish you could just do:
>
> open("nfs://server.name.dom/directory/file.txt")
NAME
amd - automatically mount file systems
...
DESCRIPTION
Amd is a daemon that automatically mounts filesystems whenever a file or
directory within that filesystem is accessed. Filesystems are automati-
cally unmounted when they appear to be quiescent.
> and have it work. That would be nice. (Replace the above with
> ftp: or http: or whatever other protocol would provide read and/or write
> access.)
What you're looking for is a substitute open() function. Perhaps
someone should just write a URI base library. Put it in the public
domain, of course, so that all UR base is belong to us
--
Paul Chvostek <[EMAIL PROTECTED]>
Operations / Development / Abuse / Whatever vox: +1 416 598-
IT Canadahttp://www.it.ca/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: gzipped crashdumps
In article <[EMAIL PROTECTED]>, Kris Kennaway <[EMAIL PROTECTED]> wrote: > > Anyone else think this patch from NetBSD is worthwhile? Yes yes yes yes yes! That's 5 votes in favor of it already. :-) > Should I also extend it to support bzip2'ed dumps now that that's in > the base system, or would that be overkill? I'm more or less neutral on that, but since the files are so big I bet bzip2 would be almost too slow to bear at reboot time. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should URL's be pervasive.
On Fri, 31 Aug 2001, David O'Brien wrote: > On Fri, Aug 31, 2001 at 09:58:21AM -0700, Richard Hodges wrote: > > > On the other hand, what exactly is http://www.ufp.org supposed to be useful > > > for when www.ufp.org is the same thing. > > > > Why not parse it literally? For instance, http://www.ufp.org > > would imply TCP, dest port 80, and host www.ufp.org. > > > > For ping, that would imply that I want to test the three-way > > handshake on whatever is listening on port 80 at www.ufp.org > > Do you have *ANY* clue how ping works??? It doesn't use TCP, for > starters... Duh! I KNOW that ping uses ICMP echo request. This thread is about a "what if" situation, and I was simply carrying to what I think was the logical conclusion. Did I claim that this would be a useful feature? NO! If you get a spare moment, why don't you (re)read Jonathon Swift's "A modest proposal". It's a good read. > > For traceroute, I want to send a series of TCP SYN packets to > > www.ufp.org, port 80 with increasing TTL values. Perhaps this > > would be a way to test connectivity to a service behind a firewall. > > Do you know how traceroute works?? For one, the destination host cannot > be listening on the port used. And you know that each progressive > traceroute packet sent out bumps the destination port by one, to help > trace the ICMP "time exceeded" / "port unreachable" responses. David, you obviously know a lot of things, but having a sense of humor would be of great help here. Jeez... -Richard --- Richard Hodges | Matriplex, inc. Product Manager | 769 Basque Way [EMAIL PROTECTED] | Carson City, NV 89706 775-886-6477| www.matriplex.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should URL's be pervasive.
On Sat, 1 Sep 2001, Matthew D. Fuller wrote: > > For traceroute, I want to send a series of TCP SYN packets to > > www.ufp.org, port 80 with increasing TTL values. Perhaps this > > No, it doesn't. > http://www.ufp.org/ does NOT mean TCP port 80. > www.ufp.org:80 means port 80, I don't know of any simple common way to > say TCP. > > http://www.ufp.org/ means the host 'www.ufp.org' using the protocol > 'http' with the TCP port 80 implicity as a result of the 'http'. > Traceroute is not going to use HTTP. Ping is not going to use HTTP. > Rpcinfo is not going to use HTTP. A mail client is not going to use > HTTP (this one is perhaps debatable, but I'm sure as hell not going > there). Agreed. I thought that it would be funny to carry this to an absurd conclusion, but I guess some people would rather just take the opportunity to assume ignorance in others. > If you want to take a URI passed to 'ping', say, and parse out a > hostname, that's one thing which I'm sure we could have endless > disagreement about. But doing that is *NOT* parsing it as a URI. Well, since humor doesn't work, I will be blunt. I think that the utilities and agents work just fine, thank-you-very-much. I think that adding URI handling to ping, traceroute, ftp, mail, etc. is a waste of time. To me, "mailto:"; suggests a TCP connection to port 25, and it is (at best) nuissance information when I want to do a ping or traceroute. The same with "http:". -Richard --- Richard Hodges | Matriplex, inc. Product Manager | 769 Basque Way [EMAIL PROTECTED] | Carson City, NV 89706 775-886-6477| www.matriplex.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gzipped crashdumps
On Sat, Sep 01, 2001 at 12:29:18PM -0700, John Polstra wrote: > In article <[EMAIL PROTECTED]>, > Kris Kennaway <[EMAIL PROTECTED]> wrote: > > > > Anyone else think this patch from NetBSD is worthwhile? > > Yes yes yes yes yes! That's 5 votes in favor of it already. :-) :-) > > Should I also extend it to support bzip2'ed dumps now that that's in > > the base system, or would that be overkill? > > I'm more or less neutral on that, but since the files are so big I > bet bzip2 would be almost too slow to bear at reboot time. Yes. Maybe I'll do some testing to see how much space it saves -- it might be useful as a non-default option for people who are low on disk space. Kris PGP signature
sysent in fork()
Hey, I have a question about sysent. If a modification to a processes p->p_sysent and associated substructures are made, are the changes propagated through fork to children? Thanks, Evan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD and Athlon Processors
On Fri, Aug 31, 2001 at 08:33:36PM -0400, Albert D. Cahalan wrote: > Well, since it didn't, I might as well explain the problem here too. > There are at least two major problems with VIA chips: [data curruption on VIA KT133/133A systems by pushing PCI and memory bus] Are you sure about that? I've pushed systems like that _very_ hard and not seen any problems, with Linux, NetBSD, or FreeBSD. The only trouble I have is IDE bus resets with CD-ROM drives, especially in FreeBSD. Since the same thing happens with a lot of IDE systems, I generally blame IDE; it's a broken-by-design interface in the first place. If this is really true, I would think it should be fairly easy to prove it. Now, go back in time about 2 years, and I wouldn't doubt it, because there were problems with the first VIA KT chipsets, and even the AMD architecture in general. Everything I've read suggests those problems have been fixed. If not, then it should be fairly easy to demonstrate this. I'm willing to donate time and a system to this since I'd really like to know. In fact, if this _really is_ true, then it would be a good idea for a substantial number of people to try and verify it: the VIA based motherboards for AMD are some of the best out there, as PC motherboards go anyway. -- "Star Wars Moral Number 17: Teddy bears are dangerous in herds." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What is VT_TFS?
On Fri, 31 Aug 2001, Zhihui Zhang wrote: > What is the file system that uses VT_TFS in vnode.h? Is it still available > on FreeBSD? Thanks. This type of filesystem was used by netcon package (http://www.netcon.com). However there is no new versions for FreeBSD above 2.x, so it probably can be safely removed. -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset
Nobody's formally asked the release engineers yet. I'd want to see a request sent to [EMAIL PROTECTED] in the usual way, with diffs attached, before I'd decide either way. - Jordan From: Martin Blapp <[EMAIL PROTECTED]> Subject: Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset Date: Sat, 1 Sep 2001 14:35:15 +0200 (CEST) > > > The other macros also have a space befor the semicolons :). Otherwise OK. > > Better commit this (especially to 4.4R) until we have something better. > > I also think that this is important to have fixed. Without this fix, > we would have been forced to change the platform for our software to a > working Linux SMP with no timedrift. > > But let Jordan decide if he likes it :-) > > Martin > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clock speedup on 4.X FreeBSD SMP and serverworks chipset
> The other macros also have a space befor the semicolons :). Otherwise OK. > Better commit this (especially to 4.4R) until we have something better. I also think that this is important to have fixed. Without this fix, we would have been forced to change the platform for our software to a working Linux SMP with no timedrift. But let Jordan decide if he likes it :-) Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Routing Performance?
The new P4s are shipping with 800mhz RAMBUS memory modules. Wouldn't 2GB of 800mhz RAM go a long way to evening out the performance between a PC/FreeBSD box and all but the most specialized, packet-pushing ASICs? I was doing some rough figuring, and could see how a P4 with its new bus and memory path would have trouble forwarding at least 2Gb/s. Am I missing something? Deepak Jain AiNET To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SO_REUSEPORT on unicast UDP sockets
Hello!
According to UNPv1 SO_REUSEPORT on UDP sockets can be used to bind more than
one socket to the same port (even with same source ip address). But quick
look on /sys/netinet/udp_usrreq.c function udp_input() shows that this will
work as expected (data stream duplicate) only on multicast/broadcast local
addresses. Please pay attention to the following code fragment comments:
if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) ||
in_broadcast(ip->ip_dst, m->m_pkthdr.rcvif)) {
struct inpcb *last;
/*
* Deliver a multicast or broadcast datagram to *all* sockets
* for which the local and remote addresses and ports match
* those of the incoming datagram. This allows more than
* one process to receive multi/broadcasts on the same port.
* (This really ought to be done for unicast datagrams as
* well, but that would cause problems with existing
* applications that open both address-specific sockets and
* a wildcard socket listening to the same port -- they would
* end up receiving duplicates of every unicast datagram.
* Those applications open the multiple sockets to overcome an
* inadequacy of the UDP socket interface, but for backwards
* compatibility we avoid the problem here rather than
* fixing the interface. Maybe 4.5BSD will remedy this?)
*/
Is there still any real need in such backward compatibility? Can such
functionality be added (fixed) with possibility to switch it off using sysctl
or kernel-build option?
I find such possibility realy useful at least for NetFlow data processing and
believe that it would be useful for many UDP-based protocols.
--
Regards,
Vladimir.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
