Re: 64 bit endian routines
Nate Lawson <[EMAIL PROTECTED]> writes: > Both scsi and geom implement unaligned access functions that perform byte > ordering. I never intended to supplant them with __bswap*(). What I want > is for machine/endian.h to have functions that provide 16-64 bit endian > conversions in both aligned and unaligned access forms. After these functions > are there, I'd like us to unify use of them and remove driver-private > versions. Sounds good, though would be more appropriate unless they're MD. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64 bit endian routines
Nate Lawson <[EMAIL PROTECTED]> writes: > First, the simple question: what's the simplest cross-platform way of > implementing scsi_ulto4b and scsi_4btoul (/sys/cam/scsi/scsi_all.h) for > 64 bit values. GEOM (/sys/geom/geom_enc.c) implements it via a 64 bit > cast in g_enc_le8. Is this the best current way? Maybe the byteorder(9) macrofunctions with a union? > Second, anyone done work on unifying our various byte ordering macros? > Besides htonl and ntohl, there are scsi_*ul*, g_enc_*, openssl/aes_locl.h, > machine/endian.h, arpa/nameser.h, and I'm sure there are others. Perhaps > the best thing is to add macros similar to geom_enc_* to machine/endian.h. > Any ideas? Most of these could probably be implemented in terms of the __bswap*() functions in , except for vendor sources like openssl, and htonl and ntohl which already are. I'm not sure if there would be an advantage to moving the geom byte ordering functions to (I guess phk didn't either). Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fork rate limit
Mike Makonnen <[EMAIL PROTECTED]> writes: > On Sun, 3 Feb 2002 02:35:46 +0400 > Gaspar Chilingarov <[EMAIL PROTECTED]> wrote: > > > I've got such situation on our free shellbox set up in the > > university - some newbies were kidding with old while(1) fork(); > > attack. Finnaly they got hit by memory limits set up for each > > user, but anyway they were taking a lot of processor time. I > > prefer to limit some uid's ability to do many forks in some > > short period - like 'no more than 200 forks in 10 seconds' or > > smthng like this. > > Lock them out of the box for a while. If they do it again ban them > forever. The students will learn pretty quickly not to do such things. He should be able to pick his own administrative policy. > This means less work for you, and no need to continuously maintain diffs > against the kernel sources. IMO it's a *very,very* bad thing to > introduce changes into the kernel that might introduce unintended side > effects when the problem can be solved administratively. Obviously he is intending his changes to be committed; hence, the patches will be applicable to -CURRENT. This is an area where FreeBSD is lacking. I can't understand why you wish to stifle his work. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The Hurd
Ashutosh S. Rajekar <[EMAIL PROTECTED]> writes: [...] > GPL conflicts with FreeBSD's artistic license. [...] FreeBSD is actually licensed under a much less restrictive license, the BSD license. See any source file out of src/gnu for details. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
kldload(2) family (was Re: loadable aio)
[Moved to -arch, BCC'd to -hackers.] Peter Pentchev <[EMAIL PROTECTED]> writes: > Okay, so it's not documented in the manual, but one look at the source > should suffice :) :( > As Mike said, there is a search path. However, the current directory > is tried first. If a file by that name is not found in the current > directory, the search path is, well, searched ;) The search path > is available in the kern.module_path sysctl or in the output of > 'kldconfig -r'. Oh no, it's worse than I feared. > This is similar to what shells have been doing for decades, with > the added feature of an implicit '.' at the start of the search path. Yes, the usual approach shells take is much better designed. Here's how I would design this interface: o _kldload(2) accepts a file path (similar to open(2)) o kldunload(2) accepts a filename (no path) o kldload(3) accepts a module name (procfs), file name (procfs.ko), or file path (/boot/kernel/procfs.ko). o Search paths for kldload(3) are controlled by the environment variable `KLDPATH' (similar to MANPATH and PATH). o When kldload(3) locates a module file, it calls _kldload(2). o kldload(8) uses kldload(3) o kldunload(8) uses kldunload(2) The main advantage of this design is that it allows a Unix programmer to utilize it. :) Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: loadable aio
Mike Smith <[EMAIL PROTECTED]> writes:
> > Terry Lambert <[EMAIL PROTECTED]> writes:
> > > There is so much "goo" around the module loading these days; there
> > > are incursions into "mount" and all sorts of other programs that
> > > should not know about module loading.
> >
> > The kldload(2) interface alone is enough to make me cringe. The way
> > in which it locates a module to load appears to be black magic.
>
> What part of searching a path for a matching file is "black magic"?
>
> Shells have been doing this for decades...
%%%
/*
* Load /boot/kernel/procfs.ko
* XXX: why does this work?
*/
chdir("/");
kldload("procfs");
/*
* Load /boot/kernel/procfs.ko
* XXX: why does this work?
*/
chdir("/");
kldload("procfs.ko");
/*
* Load /boot/kernel/procfs.ko
*/
kldload("/boot/kernel/procfs.ko"); /* Proper interface */
/*
* Move procfs.ko from /boot/kernel to /tmp, then load the copy in /tmp.
*/
system("/bin/mv /boot/kernel/procfs.ko /tmp");
chdir("/tmp");
kldload("procfs.ko"); /* XXX: this doesn't work. */
%%%
If that's not black magic, I'd like to know what is. I'd like to
refer you to the kldload(2) manual, but unfortunately it doesn't
document how kldload(2) works. :(
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: loadable aio
Terry Lambert <[EMAIL PROTECTED]> writes: > There is so much "goo" around the module loading these days; there > are incursions into "mount" and all sorts of other programs that > should not know about module loading. The kldload(2) interface alone is enough to make me cringe. The way in which it locates a module to load appears to be black magic. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding si_fd to struct __siginfo ...
Richard Sharpe <[EMAIL PROTECTED]> writes: > >There was already a big mess of a discussion about how this would > >be much better done via kqueue than with realtime signals. > > > >I guess if you can get a working implementation that is compatible > >with the existing interfaces it would work, however it's a _much_ > >better idea to use kqueue to deliver this sort of notification. > > > >And yes, it has been discussed in the lists already. > > > OK, I will go and look at the discussion ... Unfortunately this discussion mistakenly took place on a FreeBSD mailing list intended for administrative-only issues, so it isn't publicly available on our end. Luckily, a Samba mailing list was on the CC line. You should be able to find it on the <[EMAIL PROTECTED]> archives circa September 2001. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
Paul Halliday <[EMAIL PROTECTED]> writes: > Due to my limited intelligence and poor cognitive skills I > consider a PR to be a waste until someone that actually knows what they > are doing reports the same problem. > > The card compiles, works like a charm. However, No mixer control > with any app that I have tried; aumix, xmms, etc. (which all worked before > the sup) You're half way there. Now, just add the name/model of your sound card, when it broke, and you've got a PR. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
Paul Halliday <[EMAIL PROTECTED]> writes: > My soundcard on my lappy has been broken since 4.4. And to be > brutally honest, it's really starting to piss me off. Enough to open a PR? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
Michael Scheidell <[EMAIL PROTECTED]> writes: > I doubt hardware related > I can get it to do it on two seperate boxes. > Updating to freebsd 4.4 is a bad option, with all the reported ports and > services broken. I'm not aware of any services that broke between 4.3 and 4.4. Care to elaborate? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Caldera and the Ancient UNIX license
Warren Toomey <[EMAIL PROTECTED]> writes: > As for commercial use, that's a separate issue. I don't know how easy > it would be for us to talk Caldera into allowing that. Isn't Caldera keen on the BSD license? Here's a relevent quote: "Following the acquisition of Webmin by Caldera, all past and future versions of Webmin are available under the BSD license." Perhaps Caldera would be interested in releasing this gem into the open source community. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New feutures...........
Rafter Man <[EMAIL PROTECTED]> writes: > 2. I hope that in the furture the FreeBSD developers will rewrite the system in C++. I think you're alone on that one. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
Warner Losh <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]> Mike Barcroft writes: > : 386 support has been removed from -CURRENT. -CURRENT also doesn't > : support 486SX's out of the box, one is required to load a kernel > : module from the loader if they need FPU emulation. > > I assume that you mean that the GENERIC kernel doesn't support i386. > You can still build a kernel for i386 machines on -current. Oops, you're right, I was mistaken. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
Leo Bicknell <[EMAIL PROTECTED]> writes: > Put generically, I want to see a way for users to have FreeBSD make > better use of their hardware with at-most them having to select a > single option of a menu of 4-5 choices. The guy who just bought > a gig of ram because it came in a cracker jack box should be able > to click the 'use an obscene amount of memory to make everything > faster' button, without having to understand the 300+ things he > could tune in a kernel, or loader.conf, or whereever else you can > set things. Great, I'd love to see your patches. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
Leo Bicknell <[EMAIL PROTECTED]> writes: > The problem with GENERIC is it is the lowest common denominator. > While it's really cool we can still boot on a 386 with 4 meg of > RAM, making the compromises to make that happen is not terribly > useful. 386 support has been removed from -CURRENT. -CURRENT also doesn't support 486SX's out of the box, one is required to load a kernel module from the loader if they need FPU emulation. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
Wilko Bulte <[EMAIL PROTECTED]> writes: > On Wed, Dec 05, 2001 at 11:51:02AM -0500, Mike Barcroft wrote: > > Jim Durham <[EMAIL PROTECTED]> writes: > > > Duh... right. OGS..(Old Guy Syndrome). I actually just did a cvsup to > > > RELENG_4_4 and it didn't have the fixes. I guess I'll rephrase my > > > question... "Can we have the patches in REGENG_4_4?". > > > > RELENG_4_4 is for security fixes only. Consider using -STABLE if you > > require additional improvements. > > s/security/security and critical bug/ Did I miss a change in policy? The original announcement about RELENG_4_3 said: : 2) INTRODUCTION OF THE RELENG_4_3 SECURITY BRANCH :-- : : As of FreeBSD 4.3-RELEASE, the security officer will be providing : support for a new CVS branch consisting of 4.3-RELEASE plus all : released security patches from FreeBSD Security Advisories. This : branch carries the CVS branch tag of ``RELENG_4_3'', and can be : tracked using the usual source distribution methods such as cvsup : using this branch tag. : : In contrast to 4.3-STABLE (``RELENG_4''), which carries security : updates as well as general bugfixes and feature enhancements, the : RELENG_4_3 release branch will carry ONLY security fixes: it is : intended for users of FreeBSD who do not wish to track the full : 4.3-STABLE branch but who wish to keep their system up-to-date with : security fixes in a semi-automated manner (i.e. without applying : patches by hand). : : This practise of using a release branch to hold security fixes is : likely to be continued for future releases of FreeBSD. I was hoping to find more information in the Handbook, but we seem to be missing a chapter about this. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
Jim Durham <[EMAIL PROTECTED]> writes: > Duh... right. OGS..(Old Guy Syndrome). I actually just did a cvsup to > RELENG_4_4 and it didn't have the fixes. I guess I'll rephrase my > question... "Can we have the patches in REGENG_4_4?". RELENG_4_4 is for security fixes only. Consider using -STABLE if you require additional improvements. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please commit this port: ports/31188: New port: www/orion-cur rent
Koster, K.J. <[EMAIL PROTECTED]> writes: > I am fully aware that -hackers is not the right forum for this discussion, > and I apologise for the noise. I tried the appropriate mailing lists first > and got ignored. You are the second person to respond to two mails to > -ports, one to -java and one to -hackers. > > I'm open to other ideas on how to get this port committed. The best advice I can give is to just be patient. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Please commit this port: ports/31188: New port: www/orion-current
Koster, K.J. <[EMAIL PROTECTED]> writes: > Guys, please. Is there noone with a tiny bit of time on their hands and > -ports commit privs? I've been bugging -java -ports and now -hackers and get > no reaction at all. What happened to the close-a-PR drive? This is inappropriate discussion for -hackers so you're unlikely to find a response here. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
David O'Brien <[EMAIL PROTECTED]> writes: > Actually, I find it weird and counter intuitive that syslogd will not > log to the files in the config file (/etc/syslog.conf) unless they > already exists. It really feels like we are living with a programming > bug 25 years later > > If I didn't want syslogd to log something, I would not have it in > syslog.conf. syslog.conf would require fields for user:group and permissions in order for that to work, otherwise syslogd would have no idea how you want your log files created. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
Mike Barcroft <[EMAIL PROTECTED]> writes: > void <[EMAIL PROTECTED]> writes: > > On Fri, Oct 26, 2001 at 08:04:36PM -0700, Kris Kennaway wrote: > > > I assume you mean "as soon as the configuration file is modified"? > > > That would be a big violation of POLA. > > > > No ... > > Yes! Just to clarify. This is still a POLA violation. If a log file is pulled out from underneath syslogd(8), one wouldn't expect it to start logging again, even if the file was re-created. Just like one wouldn't expect it to create a new log file. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
void <[EMAIL PROTECTED]> writes: > On Fri, Oct 26, 2001 at 08:04:36PM -0700, Kris Kennaway wrote: > > I assume you mean "as soon as the configuration file is modified"? > > That would be a big violation of POLA. > > No ... Yes! > The traditional log-rotation dance goes something like: > > mv log log.0 > touch log > kill -1 `cat /var/run/syslogd.pid` > gzip log.0 > > I'm suggesting that the "kill" could be left out if syslogd got the same > smarts as "tail -F". I recommend using newsyslog(8) for rotating log files. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
strnstr(3) - New libc function for review
[BCC'd to -hackers for additional comments.]
Hello,
I would appreciate comments/reviews of the following new addition to
libc. It is largely based off the current strstr(3) implementation.
Patch attached and also available at:
http://people.FreeBSD.org/~mike/patches/strnstr.diff
Best regards,
Mike Barcroft
strnstr.diff
Add a new libc function, strnstr(3), which allows one to limit the
number of characters that are searched. This is especially useful
with file operations and non-NUL terminated strings.
Index: lib/libc/string/Makefile.inc
===
RCS file: /cvs/src/lib/libc/string/Makefile.inc,v
retrieving revision 1.23
diff -u -r1.23 Makefile.inc
--- lib/libc/string/Makefile.inc31 Jul 2001 16:34:52 - 1.23
+++ lib/libc/string/Makefile.inc5 Oct 2001 00:30:43 -
@@ -10,6 +10,7 @@
memcpy.c memmove.c memset.c rindex.c strcasecmp.c strcat.c strchr.c \
strcmp.c strcoll.c strcpy.c strcspn.c strdup.c strerror.c \
strlcat.c strlcpy.c strlen.c strmode.c strncat.c strncmp.c strncpy.c \
+ strnstr.c \
strpbrk.c strrchr.c strsep.c strsignal.c strspn.c strstr.c strtok.c \
strxfrm.c swab.c wcscat.c wcschr.c wcscmp.c wcscpy.c wcscspn.c \
wcslcat.c wcslcpy.c wcslen.c wcsncat.c wcsncmp.c wcsncpy.c wcspbrk.c \
@@ -36,6 +37,7 @@
MLINKS+=strerror.3 perror.3 strerror.3 sys_errlist.3 strerror.3 sys_nerr.3
MLINKS+=strlcpy.3 strlcat.3
MLINKS+=strtok.3 strtok_r.3
+MLINKS+=strstr.3 strnstr.3
MLINKS+=wmemchr.3 wmemcmp.3 wmemchr.3 wmemcpy.3 \
wmemchr.3 wmemmove.3 wmemchr.3 wmemset.3 \
wmemchr.3 wcscat.3 wmemchr.3 wcschr.3 \
--- /dev/null Thu Oct 4 21:11:00 2001
+++ lib/libc/string/strnstr.c Thu Oct 4 20:37:01 2001
@@ -0,0 +1,70 @@
+/*-
+ * Copyright (c) 2001 Mike Barcroft <[EMAIL PROTECTED]>
+ * Copyright (c) 1990, 1993
+ * The Regents of the University of California. All rights reserved.
+ *
+ * This code is derived from software contributed to Berkeley by
+ * Chris Torek.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. All advertising materials mentioning features or use of this software
+ *must display the following acknowledgement:
+ * This product includes software developed by the University of
+ * California, Berkeley and its contributors.
+ * 4. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include
+__RCSID("@(#)strstr.c 8.1 (Berkeley) 6/4/93");
+__FBSDID("$FreeBSD$");
+
+#include
+
+/*
+ * Find the first occurrence of find in s, where the search is limited to the
+ * first slen characters of s.
+ */
+char *
+strnstr(s, find, slen)
+ const char *s;
+ const char *find;
+ size_t slen;
+{
+ char c, sc;
+ size_t len;
+
+ if ((c = *find++) != '\0') {
+ len = strlen(find);
+ do {
+ do {
+ if ((sc = *s++) == '\0' || slen-- < 1)
+ return (NULL);
+ } while (sc != c);
+ if (len > slen)
+ return (NULL);
+ } while (strncmp(s, find, len) != 0);
+ s--;
+ }
+ return ((char *)s);
+}
Index: lib/libc/string/strstr.3
===
RCS file: /cvs/src/lib/libc/string/strstr.3,v
retrieving revision 1.7
diff -u -r1.7 strstr.3
--- lib/libc/string/strstr.31 Oct 2001 16:09:
Re: corrupted 'w' output
[Moved to -current, BCC'd to -hackers] Eugene L. Vorokov <[EMAIL PROTECTED]> writes: > Hello, > > I updated from -current yesterday, ran "make world; make kernel KERNCONF=X" > and went to bed. When I rebooted with fresh kernel this morning, I noticed > something strange: > > vel@bugz:/usr/src # w > 3:47PM up 5:38, 4 users, load averages: 0.00, 0.11, 0.08 > USER TTY FROM LOGIN@ IDLE WHAT > vel p0 kg.infotecs.ru 10:11AM 2 ssh -l vel bsx.ru > vel p1 kg.infotecs.ru 10:22AM - w > vel p2 kg.infotecs.ru 12:13PM 1:55 \M-[\M-!\^D\b (tcsh) > vel p3 kg.infotecs.ru 12:53PM 2 \M-[\M-!\^D\b (tcsh) > > This only happens for terminals that are in a shell, when something else > is running, output isn't corrupted. I think someone reported similar problem > with 'ps' output. > > Regards, > Eugene Those shell argv[0]'s are generated by login(1). I wonder if it was a recent commit to src/usr.bin/login/login.c that is causing it. Can you try locally backing out Rev. 1.68 (and Rev 1.36 of Makefile)? You will ofcourse have to relogin to see whether the w(1) output has changed. BTW, I can't reproduce this problem locally. Is there any special about your local configuration, particularly regarding PAM? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Proposed Utility - detach(1)
I would appreciate comments on the usefulness of a utility which would allow one to detach a process from a TTY. I imagine the utility would be very small and just call daemon(3) and execlp(3). Would a utility like this be useful? Is this functionality already available in a system utility? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [RFC] whois(1) - recursive IP searches
Mike Barcroft <[EMAIL PROTECTED]> writes: > I would appreciate comments on the following patch: > http://testbed.q9media.net/freebsd/whois.20010622.patch > > It does the following: > > o Implement recursive IP Address searches based on the results of > a query to ARIN. This allows a user to type 'whois 210.139.255.223' > and get the expected results. > [Requested by joe and phk] > o Update documentation to reflect this. > o Clean up some grammar nearby. If anyone is interested in committing this, I've opened a PR. PR #: bin/28426 Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [RFC] whois(1) - recursive IP searches
On 6/22/01 4:59 AM, Volker Stolz at [EMAIL PROTECTED] wrote: > In local.freebsd-hackers, you wrote: >> I would appreciate comments on the following patch: >> http://testbed.q9media.net/freebsd/whois.20010622.patch >> >> o Implement recursive IP Address searches based on the results of >> a query to ARIN. This allows a user to type 'whois 210.139.255.223' >> and get the expected results. >> [Requested by joe and phk] > > This and some of the other stuff discussed recently looks like what > other people have been building into whois-*servers* like whois.thur.de > by [EMAIL PROTECTED] (just try 'whois -h whois.thur.de > 210.139.255.223'). I don't understand the solution your proposing. Are you suggesting that we flood whois.thur.de with FreeBSD requests, or are you suggesting we have every whois server in the world switch to this software? > Why not keep whois(1) lean and put the "custom" stuff in a port? > On the other hand, I fully understand that people might disagree :) What's the point of software in the base system, if it doesn't do anything useful? If you want to find out who owns an IP block, you want to type 'whois (dotted-quad)' without having to know which country it was assigned to. Similarly, if you want to know who owns a .com, you're not going to be required to know which registrar they chose. whois(1) is an information gathering tool, after all. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[RFC] whois(1) - recursive IP searches
I would appreciate comments on the following patch: http://testbed.q9media.net/freebsd/whois.20010622.patch It does the following: o Implement recursive IP Address searches based on the results of a query to ARIN. This allows a user to type 'whois 210.139.255.223' and get the expected results. [Requested by joe and phk] o Update documentation to reflect this. o Clean up some grammar nearby. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: whois(1) patch for review
> I did not follow things going on carefully for almost two months while > I'd a deal with graduate project, but now since it's finished (Yay!!!) > and I got some time I started to dig to old patches (made during last > three months) and it's one of them. :) I'd incorporated few missing > points from Mike's PR and have on hold Joachim's (I have plans and ideas > to make it even more optimized). > > So, if people also started to work on this topic it shows its > actuality, IMHO. :-) Arg.. I wish you had contacted me before doing this work. From looking at your patch, your using an old copy of my work. The newest one is available at: http://testbed.q9media.net/freebsd/whois.patch and will be committed very-shortly-now(tm). Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
