Re: Why 'dd' does not seek over 'char' devs (specifically raw disk
On Tue, 13 Jul 1999, Luigi Rizzo wrote: Hi, i have a question. Why 'dd' does not seek over 'char' devs (specifically raw disk partitions). Not all character devices support seeking. So, we work with the LCD... Sorry, I don't like this either. It would be better, maybe, just to fix character devices. couldn't we first try lseek and only do the reads on char devs where the lseek fails ? lseek() won't usually fail unless it's something like EBADF. It merely sets the current fd's offset. It would be nice to be able to tell from a device driver if it supports seeking (da) or not (sa). Hmm... actually, if we just specify somehow that we support either direct or sequential access... this would be possible. You certainly make a good case. modify your local copy of dd to do what you want. generally this is not the kind of things you can do when your system has already gone bad (this was a laptop's disk...) The problem is that dd skip= is used a lot on tape devices. Here, a seek would not work. I notice that on output lseek _is_ used also on char devices. And how else would you do it? ok, stupid observation! cheers luigi ---+- Luigi RIZZO, lu...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ First International Workshop on Networked Group Communication ---+- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
But I have a valid point: can we do something better than posting a SIGKILL to the largest process? Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Why 'dd' does not seek over 'char' devs (specifically raw disk
On Tue, 13 Jul 1999, John Polstra wrote: In article pine.bsf.4.10.9907131042310.76301-100...@janus.syracuse.net, Brian F. Feldman gr...@freebsd.org wrote: On Tue, 13 Jul 1999, Luigi Rizzo wrote: couldn't we first try lseek and only do the reads on char devs where the lseek fails ? lseek() won't usually fail unless it's something like EBADF. It merely sets the current fd's offset. It would be nice to be able to tell from a device driver if it supports seeking (da) or not (sa). Hmm... actually, if we just specify somehow that we support either direct or sequential access... this would be possible. It would be a big improvement if dd could handle seeking on character disk devices. I'm reasonably certain there exists some ioctl (perhaps related to reading disk labels) which could be used to figure out whether a character device was a disk or not. A simple fix like that would make dd a lot more useful for the case Luigi brought up. Okay, I implemented it, and it's in -CURRENT. I forgot about dsioctl()... I was thinking in majors and minors, and that they'd have to be hardcoded in... ;) This is better. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
On Tue, 13 Jul 1999, Matthew Dillon wrote: :But I have a valid point: can we do something better than posting a SIGKILL :to the largest process? : : Brian Fundakowski Feldman _ __ ___ ___ ___ ___ : gr...@freebsd.org _ __ ___ | _ ) __| \ We could have the ability to mark processes as being more or less preferable as kill candidates. I'm not sure I really care anymore, though... there is so much disk space available now that it is fairly difficult to run the system out of swap space. I don't think I've run any of my personal systems out of swap space for at least a year now! Usually the biggest process is the one responsible (note: MFS processes do not count, and they are immune from being killed). We need some kind of hysteresis... a process took up all my swap left, got killed, then my X server got killed too. I'd like something that says I don't want process X killed unless it has run away with over Y of memory. But I'd also like to see FreeBSD not kill two processes to prevent a deadlock. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Tue, 13 Jul 1999, Ian Dowse wrote: In message pine.bsf.4.10.9907130946220.76301-100...@janus.syracuse.net, Bria n F. Feldman writes: On 13 Jul 1999, Ville-Pertti Keinonen wrote: gr...@freebsd.org (Brian F. Feldman) writes: It's out with the bad, in with the good. Pidentd code is pretty terrible . The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) If anyone wants to audit my code for security, I invite them to. Did you mean to avoid reading through symlinks using the open + fstat method mentioned earlier in the thread? No, I meant to avoid opening a file the user couldn't, or reading from a dev. Why not actually store the fake ID in a symbolic link? That way you just do a readlink(), which would be safer, neater and faster than reading a file. A user can set up a fake ID with something like: ln -s Warm-Fuzzy .fakeid Hysterical raisins. ~/.fakeid being a text file is how it's always been done. That would be a better idea if I didn't mind confusing the hell out of people :) Ian Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
We don't _need_ pidentd anymore. It will load down a system more than the inetd's implementation of ident will. Therefore, pidentd should be phased out. Other than that, pidentd should be using http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
On Tue, 13 Jul 1999, Matthew Dillon wrote: There are other ways. For example, even if a user account is resource limited, root processes (such as sendmail, popper, identd, and so forth) are not. Attacks against these servers generally result in very high loads and sometimes make it difficult to login to fix the problem, but do not result in running out of swap. Inetd is rate-limited by default nowadays, so this really doesn't apply. -Matt Matthew Dillon dil...@backplane.com Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Mon, 12 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. I like this suggestion. I worry about a trend I'm seeing, with more and more people keen to replace existing code with their own virgin code which hasn't had any serious field time behind it. This seems like a very Linuxy development trend. It's the way the Bazaar works, but not in a Cathedral. Rather, you have a look at what's already there and try to work on it. You don't start your own wing a few feet from the Cathedral in the hopes that someone will bash down a similar wing elsewhere and join yours to the main building. It's "out with the bad, in with the good." Pidentd code is pretty terrible. The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) If anyone wants to audit my code for security, I invite them to. But frankly, I highly doubt anyone will find anything to exploit. And, why would bugtraq advisories against other identds apply to my ident_stream service? This is an entirely different code base. Waffle waffle. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Mon, 12 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. I like this suggestion. I worry about a trend I'm seeing, with more and more people keen to replace existing code with their own virgin code which hasn't had any serious field time behind it. This seems like a very Linuxy development trend. It's the way the Bazaar works, but not in a Cathedral. Rather, you have a look at what's already there and try to work on it. You don't start your own wing a few feet from the Cathedral in the hopes that someone will bash down a similar wing elsewhere and join yours to the main building. It's out with the bad, in with the good. Pidentd code is pretty terrible. The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) If anyone wants to audit my code for security, I invite them to. But frankly, I highly doubt anyone will find anything to exploit. And, why would bugtraq advisories against other identds apply to my ident_stream service? This is an entirely different code base. Waffle waffle. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 01:49:59 -0400, "Brian F. Feldman" wrote: inetd already has the built-in equivalent to that. Maybe it's possible to make a REAL ident (*cough* the one I wrote) an option, inetd has that service off by default. That sounds much more like it. I will say that I suspect this is a bad move. The more I think about it, the more I think we don't want the kitchen sink in there. Inetd only offers a limited auth service to prevent delays in the servicing of requests from local users on remote hosts. Anyone who wants to use the auth service for other things should probably use a specialized piece of software to do that. I don't think inetd needs this functionality built in. I think that what you really want is pidentd imported into the base system. And while it's noble to want a GNU-free base system and I applaud efforts in that direction, you should probably slow down and read pidentd's license agreement. :-) Personally, I don't think there's anything wrong with leaving pidentd as a port. I find pidentd gross, to say the least. I don't see why not to kill it... And this service is very small, so it doesn't make inetd "huge". It's not feeping creaturism because I replaced the ident service there with a working one. Then the user can select one of two lines for a real ident service or a fake one. DES has some interesting ideas in this direction. Take a look at closed PR 11796 if and when you start thinking about how to implement this. Ciao, Sheldon. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Doug wrote: 3. Having a built in version of a "real" ident run out of inetd would be *very* welcome by the people that need it. pidentd is a bloated, buggy pig. Thank you. That's why I wrote it. 4. I agree with Sheldon that returning "real" responses by default would be a bad thing. The current ability to send fake responses is a good thing, but having the option to do real ident would also be good. Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. How in the world could my inetd ident service be exploited? I just fixed the only problematic feature, fake id, to make it not read anything but a regular file and not let you try to use someone else's name. I can't see any way that any part of it could be exploited... HTH, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Warner Losh wrote: In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : Good idea. I'll have it check to see that it's a regular file. Make sure that you do this with the stat, open, fstat interlocking so that there isn't a race here. I have this fixed in my latest code (on freefall of course). I did not use an original stat because that's pointless, as it adds another race condition. The only downside to my approach is that if it's a symlink to a dev, the dev can get opened/closed, and d_open/d_close be called. Warner Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rtfm rewritten in C
On Sun, 11 Jul 1999, Chris Costello wrote: On Sun, Jul 11, 1999, Brian F. Feldman wrote: I can manage C code much better than I can manage Perl code and C is faster than Perl. Trying to start ANOTHER holy war? :) I meant that you don't have to compile/interpret/whatever-you-wanna-call-it with compiled C code as you do with Perl. Plus the first -- I'm terrible with keeping Perl code managed. I agree. Perl, while more flexible, can be MUCH more of a mess. -- Chris Costello[EMAIL PROTECTED] To be, or not to be, those are the parameters. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Kevin Day wrote:
Is it worth it to write an identd for FreeBSD? With one sysctl added, it's
trivial to implement. If an identd would be desired, then should I make a
separate one, or rewrite the current inetd's internal identd shim? I
don't see a reason for pidentd when we could have an identd built in by
me fixing inetd up, and it would all take up less space.
There is the question - what for? identd is of questionable use at best.
The best use of identd I have seen is crypted cookies that would allow
an attackee to identify an attacker in a non-privacy-invasive manner.
In 3 years of running this at an ISP, I have never seen it used in anger.
Under normal circumstances (${BIGNUM} Wintendo boxes running IRC
clients), the info given is completely useless.
Just to add a counter-point here, I run an ISP that offers shell accounts.
We get idiot customers using IRC for all sorts of nasty things at times, and
identd is the only method I have for knowing who did it when I get
complaints.
However, pidentd is rather buggy of late, and tends to freak out a lot. If
we could have an 'official' identd, I'd like it. :)
Go ahead and try out mine then! You'll need the following patches from
http://www.FreeBSD.org/~green/ :
socred.patch (not necessary for 4.0; some parts require manual attention in
3.X, as it won't patch perfectly; this is already applied in 4.0)
getcred.patch
inetd_ident.patch
Patch them in in order, making sure they apply correctly. Then make includes,
rebuild the kernel, rebuild modules, install kernel and modules, rebuild
inetd, edit inetd.conf to enable the built-in auth service, and
reboot. Let me know how it goes. I hope to make this standard as part of 4.0 :)
Kevin
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Sheldon Hearn wrote: On Sun, 11 Jul 1999 01:49:59 -0400, Brian F. Feldman wrote: inetd already has the built-in equivalent to that. Maybe it's possible to make a REAL ident (*cough* the one I wrote) an option, inetd has that service off by default. That sounds much more like it. I will say that I suspect this is a bad move. The more I think about it, the more I think we don't want the kitchen sink in there. Inetd only offers a limited auth service to prevent delays in the servicing of requests from local users on remote hosts. Anyone who wants to use the auth service for other things should probably use a specialized piece of software to do that. I don't think inetd needs this functionality built in. I think that what you really want is pidentd imported into the base system. And while it's noble to want a GNU-free base system and I applaud efforts in that direction, you should probably slow down and read pidentd's license agreement. :-) Personally, I don't think there's anything wrong with leaving pidentd as a port. I find pidentd gross, to say the least. I don't see why not to kill it... And this service is very small, so it doesn't make inetd huge. It's not feeping creaturism because I replaced the ident service there with a working one. Then the user can select one of two lines for a real ident service or a fake one. DES has some interesting ideas in this direction. Take a look at closed PR 11796 if and when you start thinking about how to implement this. Ciao, Sheldon. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Niall Smart wrote:
I don't see a point to that. However, I am finished. Please go to
http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch.
Hmm,
+#ifdef FAKEID
+ snprintf(fakeid_path, sizeof(fakeid_path), %s/.fakeid,
pw-pw_dir);
+ fakeid = fopen(fakeid_path, r);
+ if (fakeid) {
$ ln -s /etc/master.passwd ~/.fakeid
Ouch. (One possible saving grace here is that you truncate
after 16 characters).
Good idea. I'll have it check to see that it's a regular file.
+ if (!*cp || getpwnam(cp)) {
+ pw = getpwuid(uc.cr_uid);
+ cp = pw-pw_name;
+ goto printit;
+ }
What is this code trying to do? If the ~/.fakeid file is invalid
or the user is attempting to impersonate another then revert? A
comment would be nice. You forget to check for pw == NULL here
(but you don't earlier ;) and I don't think the goto is necessary.
If pw lookup for that uid succeeded before, why won't it succeed now? In
fact, I didn't even need the pw = , but that would be depending on
current static behavior...
Regards,
Niall
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Doug wrote: 3. Having a built in version of a real ident run out of inetd would be *very* welcome by the people that need it. pidentd is a bloated, buggy pig. Thank you. That's why I wrote it. 4. I agree with Sheldon that returning real responses by default would be a bad thing. The current ability to send fake responses is a good thing, but having the option to do real ident would also be good. Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. How in the world could my inetd ident service be exploited? I just fixed the only problematic feature, fake id, to make it not read anything but a regular file and not let you try to use someone else's name. I can't see any way that any part of it could be exploited... HTH, Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Matthew Dillon wrote:
: 2. Most shell services do a good job of keeping ident reliable. They need
: to do that because most IRC networks heavily penalize clients that don't
: return any ident.
:
:This is changing. In the face of ${BIGNUM} Windoze boxes giving ident
:answers like HAX0r, there is little point, except for the administrator
:of the box _giving_ the ident. If that was me, it would be _low_ on my
:list.
ident is extremely useful when taken in the proper context. It doesn't
really matter what a user-owned box returns. An IRC administrator only
cares about two things:
* If the irc client is connecting from an (ISP's) multi-user shell
machine, that the ident contain sufficient information to identify
the user.
* If the irc client is connecting from a single-user machine, such as
a windoz box, the IRC administrator has the IP address and times
involved, which is again sufficient for the user's ISP to identify
the user.
When a user is abusing an IRC server, the IRC administrator has two
choices:
* If it is coming from an ISP who takes abuse seriously, the IRC
administrator need only identify the user sufficiently (IP and time,
or ident info if coming from a shared shell box) such that the ISP
can kick the user off the service.
* If it is coming from an ISP who does not take abuse seriously, the
IRC administrator locks out the entire ISP.
At BEST ident was turned on on all machines and it returned the user's
real user name. It did that because it made it a whole lot easier for us
to handle abuse issues, it cut abuse significantly, and it cut
abuse-related email from remote IRC admins significantly because they
could lockout specific users based on the ident info without having to
contact us.
I don't work at BEST any more, but I would love to see kernel support
for ident lookups. To make identd work reasonably well, I had to hack
the server to timeout after a few seconds worth of cpu-bound searching
through KVM, because it would sometimes get into scanning loops.
Well, it's here now. I've committed it in 4.0, and would MFC it except it
would require the struct socket changes I made in -CURRENT. See my pidentd
freebsd.c replacement (using this) at http://www.FreeBSD.org/~green/freebsd4.c
-Matt
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: rtfm rewritten in C
On Sun, 11 Jul 1999, Chris Costello wrote: On Sun, Jul 11, 1999, Tim Vanderhoek wrote: On Sat, Jul 10, 1999 at 11:45:39PM -0500, Chris Costello wrote: So far, it seems the functionality is the same. A tarball is availible at http://www.calldei.com/~chris/rtfm.tar.gz What was the advantage of rewriting it in C? I can manage C code much better than I can manage Perl code and C is faster than Perl. Trying to start ANOTHER holy war? :) -- Chris Costelloch...@calldei.com If you have a procedure with 10 parameters, you probably missed some. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Warner Losh wrote: In message pine.bsf.4.10.9907111408060.25135-100...@janus.syracuse.net Brian F. Feldman writes: : Good idea. I'll have it check to see that it's a regular file. Make sure that you do this with the stat, open, fstat interlocking so that there isn't a race here. I have this fixed in my latest code (on freefall of course). I did not use an original stat because that's pointless, as it adds another race condition. The only downside to my approach is that if it's a symlink to a dev, the dev can get opened/closed, and d_open/d_close be called. Warner Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Warner Losh wrote: In message pine.bsf.4.10.9907112031200.31726-100...@janus.syracuse.net Brian F. Feldman writes: : I have this fixed in my latest code (on freefall of course). I did not : use an original stat because that's pointless, as it adds another race : condition. The only downside to my approach is that if it's a symlink : to a dev, the dev can get opened/closed, and d_open/d_close be called. How does the original stat add a race condition. You stat the file, open it, then fstat it. If the two match you know you're good. If they don't, you can detect that something bad has happened Ahh, I misunderstood you. In _this_ case you just proposed, the stat is really pointless. What good would it do? Warner Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: rtfm rewritten in C
On Sun, 11 Jul 1999, Chris Costello wrote: On Sun, Jul 11, 1999, Brian F. Feldman wrote: I can manage C code much better than I can manage Perl code and C is faster than Perl. Trying to start ANOTHER holy war? :) I meant that you don't have to compile/interpret/whatever-you-wanna-call-it with compiled C code as you do with Perl. Plus the first -- I'm terrible with keeping Perl code managed. I agree. Perl, while more flexible, can be MUCH more of a mess. -- Chris Costelloch...@calldei.com To be, or not to be, those are the parameters. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
a BSD identd
Is it worth it to write an identd for FreeBSD? With one sysctl added, it's trivial to implement. If an identd would be desired, then should I make a separate one, or rewrite the current inetd's internal identd shim? I don't see a reason for pidentd when we could have an identd built in by me fixing inetd up, and it would all take up less space. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sat, 10 Jul 1999, Sheldon Hearn wrote: On Sat, 10 Jul 1999 11:50:01 -0400, "Brian F. Feldman" wrote: I don't see a reason for pidentd when we could have an identd built in by me fixing inetd up, and it would all take up less space. Hi Brian, If you do end up messing with inetd's existing ident service, please make sure that the default behaviour remains the same and that the operator must do something to enable an ident service that reports more than just "UNKNOWN-ERROR". Thanks, Sheldon. I don't see a point to that. However, I am finished. Please go to http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch. =) Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: a BSD identd
On Sun, 11 Jul 1999, Kevin Day wrote:
Is it worth it to write an identd for FreeBSD? With one sysctl added, it's
trivial to implement. If an identd would be desired, then should I make a
separate one, or rewrite the current inetd's internal identd shim? I
don't see a reason for pidentd when we could have an identd built in by
me fixing inetd up, and it would all take up less space.
There is the question - what for? identd is of questionable use at best.
The best use of identd I have seen is crypted cookies that would allow
an attackee to identify an attacker in a non-privacy-invasive manner.
In 3 years of running this at an ISP, I have never seen it used in anger.
Under normal circumstances (${BIGNUM} Wintendo boxes running IRC
clients), the info given is completely useless.
Just to add a counter-point here, I run an ISP that offers shell accounts.
We get idiot customers using IRC for all sorts of nasty things at times, and
identd is the only method I have for knowing who did it when I get
complaints.
However, pidentd is rather buggy of late, and tends to freak out a lot. If
we could have an 'official' identd, I'd like it. :)
Go ahead and try out mine then! You'll need the following patches from
http://www.FreeBSD.org/~green/ :
socred.patch (not necessary for 4.0; some parts require manual attention in
3.X, as it won't patch perfectly; this is already applied in 4.0)
getcred.patch
inetd_ident.patch
Patch them in in order, making sure they apply correctly. Then make includes,
rebuild the kernel, rebuild modules, install kernel and modules, rebuild
inetd, edit inetd.conf to enable the built-in "auth" service, and
reboot. Let me know how it goes. I hope to make this standard as part of 4.0 :)
Kevin
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
a BSD identd
Is it worth it to write an identd for FreeBSD? With one sysctl added, it's trivial to implement. If an identd would be desired, then should I make a separate one, or rewrite the current inetd's internal identd shim? I don't see a reason for pidentd when we could have an identd built in by me fixing inetd up, and it would all take up less space. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
On Sat, 10 Jul 1999, Sheldon Hearn wrote: On Sat, 10 Jul 1999 11:50:01 -0400, Brian F. Feldman wrote: I don't see a reason for pidentd when we could have an identd built in by me fixing inetd up, and it would all take up less space. Hi Brian, If you do end up messing with inetd's existing ident service, please make sure that the default behaviour remains the same and that the operator must do something to enable an ident service that reports more than just UNKNOWN-ERROR. Thanks, Sheldon. I don't see a point to that. However, I am finished. Please go to http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch. =) Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: a BSD identd
inetd already has the built-in equivalent to that. Maybe it's possible to make a REAL ident (*cough* the one I wrote) an option, inetd has that service off by default. Then the user can select one of two lines for a real ident service or a fake one. I should probably take the FAKEID stuff out, or make sure that noone can fake another user with it. Hmm... I'll fix that in the next few minutes, I guess. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: hardware
On Fri, 9 Jul 1999, Axis wrote: I have been using *BSD* for around 3 years now. My problem is thatI have always used the console for system administration duties. I really want to put a kick *** system together to run X with all of the luxuries. I have noticed there is not that much support for sound cards andvideo display adapters. Given your experience, Could you please inform me of which sound card and video display adapter works best with FreeBSD. I suggest a nice TNT or TNT2 (Ultra too)-based card for video. They have nice 2D acceleration and okay 3D acceleration. The 3D acceleration is great, but limited by the slow architecture of the current X/GL/GLX implementation. I get very nice, but nowhere near current Windoze-driver-speed, 3D accel using this baby (just don't expect to play much Quake 3 with it in FreeBSD yet.) As for sound cards, I use a SB16. These are very well-supported and run nicely with either sound driver. Mine is an old SB16 4.13 (full-length ISA, software configured (not PnP)), and works perfectly. If you want something newer (more expensive too), other people than I will point you on your way. Thanxs Axis FreeBSD, OpenBSD, NetBSD, BSDI all have one simularity; They are all better than LINUX or (Like Its Not UNIX). :) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Strange select/poll behaviour [EBADF inconsistancy]
On Thu, 8 Jul 1999, Matthew Dillon wrote: :Hmm, you're right. Arguably, it could return EINVAL. Actually, the :man page documents this behavior, although it gets the 256 number wrong. : : If nfds is greater than the number of open files, select() is not guaran- : teed to examine the unused file descriptors. For historical reasons, : select() will always examine the first 256 descriptors. : :-- :Jonathan This piece of the manual is justifying the fact that select() is not currently checking past the current number of open files -- which is how select() works now. The second part of that manual entry is just plain wrong: If you pass an nd value less then 256 it will only check that number of descriptors, it no longer examines a minimum of 256. So shouldn't someone correct it? I'll do it if noone else wants to. It would definitely not be appropriate to return EINVAL. I concur. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
sysctl question
How do I set up a sysctl so that I may pass in a two pointers: one to pass in some data another to receive some data ? Is it possible? Otherwise, I think I should just do something with passing in an arbitrary data buffer (pointer to, rather) which contains the data necessary on entrance on exit will receive the (other type) of data as output. Right now, I have myself confused with the sysctl interface and I'm attempting to use oldptr, oldlen, newptr, and newlen all at the same time which is definitely wrong. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poll() vs select()
On Tue, 6 Jul 1999, John Polstra wrote: In article [EMAIL PROTECTED], The application itself has to get involved if it wants to do async name lookups, or async anything else, for that matter. Suppose you do have an async thread to do hostname lookups as you propose. What is the application going to do while that thread is waiting for the lookup to complete? It depends on the application, and thus it has to be coded into the application. Maybe there's nothing useful the application could do until the lookup returns. I've been told that it works fine to use libc_r and put the name lookups into a separate thread. But to take advantage of it, the application has to have something useful it wants to do (and can do) in the meantime. It would let the other threads run more while the lookup is occurring. Wouldn't that be the most natural expectation of it? Or would this be too hard without kernel-assisted threading? John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
On Tue, 6 Jul 1999, Chris Costello wrote: On Tue, Jul 6, 1999, Doug wrote: I'm confused about this script. How does it differ from 'apropos'? It differs in that it _uses_ apropos (or 'whatis' if you specify the -e flag), as well as a Texinfo search, as well as a FAQ search, using the FAQ pages at http://www.freebsd.org/FAQ/. It's meant to be an information center for those just getting started with FreeBSD. RTFM isn't a newby-apparent term. Name it help(1). Doug -- Chris Costello[EMAIL PROTECTED] It's 10 o'clock. Do you know where your child processes are? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
On Tue, 6 Jul 1999, Chris Costello wrote: On Tue, Jul 6, 1999, Brian F. Feldman wrote: RTFM isn't a newby-apparent term. Name it help(1). That would cause problems with bash users. They already have a builtin help command. Which can be disabled in the bash port before the next release... help(1) is really a much more appropriate name. -- Chris Costello[EMAIL PROTECTED] On a clear disk you can seek forever. - Denning To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
On Tue, 6 Jul 1999, Jordan K. Hubbard wrote: Which can be disabled in the bash port before the next release... No, that's a really stupid idea. Thanks! But still, I don't think rtfm is very appropriate... Can we look for something better, more obvious? Or perhaps it would be in the motd like /stand/sysinstall is people would need to be aware of this. - Jordan Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poll() vs select()
On Tue, 6 Jul 1999, John Polstra wrote: In article pine.bsf.4.10.9907042155090.66085-100...@janus.syracuse.net, The application itself has to get involved if it wants to do async name lookups, or async anything else, for that matter. Suppose you do have an async thread to do hostname lookups as you propose. What is the application going to do while that thread is waiting for the lookup to complete? It depends on the application, and thus it has to be coded into the application. Maybe there's nothing useful the application could do until the lookup returns. I've been told that it works fine to use libc_r and put the name lookups into a separate thread. But to take advantage of it, the application has to have something useful it wants to do (and can do) in the meantime. It would let the other threads run more while the lookup is occurring. Wouldn't that be the most natural expectation of it? Or would this be too hard without kernel-assisted threading? John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm' script
On Tue, 6 Jul 1999, Chris Costello wrote: On Tue, Jul 6, 1999, Doug wrote: I'm confused about this script. How does it differ from 'apropos'? It differs in that it _uses_ apropos (or 'whatis' if you specify the -e flag), as well as a Texinfo search, as well as a FAQ search, using the FAQ pages at http://www.freebsd.org/FAQ/. It's meant to be an information center for those just getting started with FreeBSD. RTFM isn't a newby-apparent term. Name it help(1). Doug -- Chris Costelloch...@calldei.com It's 10 o'clock. Do you know where your child processes are? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm' script
On Tue, 6 Jul 1999, Chris Costello wrote: On Tue, Jul 6, 1999, Brian F. Feldman wrote: RTFM isn't a newby-apparent term. Name it help(1). That would cause problems with bash users. They already have a builtin help command. Which can be disabled in the bash port before the next release... help(1) is really a much more appropriate name. -- Chris Costelloch...@calldei.com On a clear disk you can seek forever. - Denning To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm' script
On Tue, 6 Jul 1999, Jordan K. Hubbard wrote: Which can be disabled in the bash port before the next release... No, that's a really stupid idea. Thanks! But still, I don't think rtfm is very appropriate... Can we look for something better, more obvious? Or perhaps it would be in the motd like /stand/sysinstall is people would need to be aware of this. - Jordan Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm' script
On Tue, 6 Jul 1999, Doug wrote: On Tue, 6 Jul 1999, Brian F. Feldman wrote: On Tue, 6 Jul 1999, Jordan K. Hubbard wrote: Which can be disabled in the bash port before the next release... No, that's a really stupid idea. Thanks! But still, I don't think rtfm is very appropriate... Can we look for something better, more obvious? Or perhaps it would be in the motd like /stand/sysinstall is people would need to be aware of this. I think your logic is faulty here. There are already many adequate resources in the motd, but your argument for the 'rtfm script' presupposes that the person has not looked at the motd, because if they had they wouldn't need the script. /bin/rtfmsh? Honestly, while this is one of those things that sounds good when you first start talking about it, in practice I don't see what we gain from it. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
Don't ICBM coordinates require an elevation. BTW, I'm at 38.75N 76.87W for the lovely list :) Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poll() vs select()
On Sun, 4 Jul 1999, Archie Cobbs wrote: Christopher Sedore writes: A new, faster event notification system would be great. But don't forget to include *all* events, not just file descriptor readability/writability. I.e., signal delivery, child exit notification, maybe even support for an arbitrary number of (independent) timers. And make the events independent from each other -- to avoid problems like when an application completely hangs for 90 seconds when it calls gethostbyname(). An async thread to do hostname lookups would be great! Wouldn't be too hard in libc_r, would it? But in regular apps, setitimer and sigsetjmp() would be a solution. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting LILO to FreeBSD
On Sun, 4 Jul 1999, Archie Cobbs wrote: Long ago I was a Linux hacker before converting to FreeBSD. I thought LILO was great and beat the heck out of FreeBSD's booteasy... But now, we have the FreeBSD loader courtesy of the BTX toolchain and the hard-working loader hackers :) -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
On Sun, 4 Jul 1999, Jordan K. Hubbard wrote: I'm going to have a core team page worked on which has pictures and brief bios, perhaps something by next week. Such things may seem frivolous, but I it helps people relate a little more directly to the core team if they can see what they look like and read a bit about them. Same for the committers group, but at 165+ members that's going to be a somewhat larger, long-term project. :-) How about including a link with the e-mail address link on the relevant page to point http://www.FreeBSD.org/~user/personal.html? Either that or, for putting things on a single page, have everyone put their stuff in their ~/public_html in a specified location (i.e. bio.txt (bio.sgml?) self.jpg) and having the document projecteers use that as a base? If noone else wants to, I could do this, but keep it separate from the docproj... - Jordan Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poll() vs select()
On Sun, 4 Jul 1999, Archie Cobbs wrote: Christopher Sedore writes: A new, faster event notification system would be great. But don't forget to include *all* events, not just file descriptor readability/writability. I.e., signal delivery, child exit notification, maybe even support for an arbitrary number of (independent) timers. And make the events independent from each other -- to avoid problems like when an application completely hangs for 90 seconds when it calls gethostbyname(). An async thread to do hostname lookups would be great! Wouldn't be too hard in libc_r, would it? But in regular apps, setitimer and sigsetjmp() would be a solution. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Porting LILO to FreeBSD
On Sun, 4 Jul 1999, Archie Cobbs wrote: Long ago I was a Linux hacker before converting to FreeBSD. I thought LILO was great and beat the heck out of FreeBSD's booteasy... But now, we have the FreeBSD loader courtesy of the BTX toolchain and the hard-working loader hackers :) -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: bpfilter - bpf patches [LONG]
On Sat, 3 Jul 1999, Doug wrote: Dag-Erling Smorgrav wrote: [Bcc:ed to net, committers; please follow up on hackers] Attached are patches for renaming 'pseudo-device bpfilter' to 'peudo-device bpf', courtesy of glimpse(1) and ed(1). LINT and GENERIC build fine with these patches; I haven't tried to run a kernel built with them, though. Also, although I caught and corrected a few spacing nits caused by chopping off five letters, there may be some I didn't catch. If no-one objects, I'll commit this to -CURRENT in a few days. Forgive me if this is a stupid question, but are there any circumstances where naming the kernel include file "bpf.h" would conflict with /usr/include/net/bpf.h? In any case, this is a long overdue, and welcome change. Thank you. :) Doug How would that conflict? "bpf.h" is a local include, so it's not the same include path set. Plus, it would only be included as bpf.h if -I/sys/net. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poll() vs select()
On Sat, 3 Jul 1999, Jonathan Lemon wrote: On Jul 07, 1999 at 01:01:07AM -0400, Brian F. Feldman wrote: On Fri, 2 Jul 1999, Jonathan Lemon wrote: As for new code, use whichever you are comfortable with. Personally, I would recommend poll(), since it provides some added functionality over select() that makes for easier programming. poll() is a huge pain to use, which is why I recommend select(). Whichever you're comfortable with. poll() isn't a pain once you know how to use it, and it does bring additional benefits. I don't see how you can not find poll() a pain when compared to select(). It requires so much set-up, much like (for instance) aio_write() as opposed to write(). I suppose if you're masochistic, you won't mind doing that :) -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: support for i386 hardware debug watch points
On Sat, 3 Jul 1999, Peter Wemm wrote: Thomas David Rivers wrote: Is there any interest in supporting something like this in FreeBSD? I'm volunteering to spend some cycles on this, but I don't want to go to the effort if there's little chance that the work would be integrated. Thanks, -Brian -- Brian DeanSAS Institute Inc brd...@unx.sas.com Brian - Scan through the mail archives - I brought this up about this time last year, I think... There were several responses - some people may be willing to assist... I'll chime in.. I'd be quite willing to bring something like this in, assuming it was done reasonably cleanly. It shouldn't be too hard to do it without imparing portability across cpu/arch types. I think this would be quite useful, especially if gdb could be made aware of it too. I think this would be great too, but I have a concern. Not all CPUs (x86) support this; make ABSOLUTELY sure it doesn't do this kind of thing on hardware which doesn't support it, please! - Dave Rivers - Cheers, -Peter -- Peter Wemm - pe...@freebsd.org; pe...@yahoo-inc.com; pe...@netplex.com.au To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: bpfilter - bpf patches [LONG]
On Sat, 3 Jul 1999, Doug wrote: Dag-Erling Smorgrav wrote: [Bcc:ed to net, committers; please follow up on hackers] Attached are patches for renaming 'pseudo-device bpfilter' to 'peudo-device bpf', courtesy of glimpse(1) and ed(1). LINT and GENERIC build fine with these patches; I haven't tried to run a kernel built with them, though. Also, although I caught and corrected a few spacing nits caused by chopping off five letters, there may be some I didn't catch. If no-one objects, I'll commit this to -CURRENT in a few days. Forgive me if this is a stupid question, but are there any circumstances where naming the kernel include file bpf.h would conflict with /usr/include/net/bpf.h? In any case, this is a long overdue, and welcome change. Thank you. :) Doug How would that conflict? bpf.h is a local include, so it's not the same include path set. Plus, it would only be included as bpf.h if -I/sys/net. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BUG boot-time messages
On Sat, 3 Jul 1999, Jim Pazarena wrote: The following messages appear on the display as my FreeBSD machine is booting. The spelling of failed is totally incorrect, and it would sure be nice to see the spelling corrected on a future release. I don't see that in FreeBSD's HEAD, RELENG_2_2, or RELENG_3 branches. To: p...@mail.qcislands.net Subject: BUG boot-time messages From: Charlie Root r...@ns2.qcislands.net Date: Sat, 3 Jul 1999 10:01:34 -0700 -- Jul 3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x330 Jul 3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x334 Jul 3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x230 Jul 3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x234 Jul 3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x130 Jul 3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x134 ^^^ -- Jim Pazarena mailto:p...@qcislands.net http://www.qcislands.net/paz To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BUG boot-time messages
On Sat, 3 Jul 1999, Kenneth D. Merry wrote: Brian F. Feldman wrote... On Sat, 3 Jul 1999, Jim Pazarena wrote: The following messages appear on the display as my FreeBSD machine is booting. The spelling of failed is totally incorrect, and it would sure be nice to see the spelling corrected on a future release. I don't see that in FreeBSD's HEAD, RELENG_2_2, or RELENG_3 branches. To: p...@mail.qcislands.net Subject: BUG boot-time messages From: Charlie Root r...@ns2.qcislands.net Date: Sat, 3 Jul 1999 10:01:34 -0700 -- Jul 3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x330 Jul 3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x334 Jul 3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x230 Jul 3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x234 Jul 3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x130 Jul 3 03:53:46 ns2 /kernel: bt_isa_probe: Probe failled for card at 0x134 ^^^ It was fixed in -current in April by phk, and merged to -stable by Justin in May. Good reason for me not to see it ;) Ken -- Kenneth Merry k...@plutotech.com Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: how to start to be a hacker?
On Sat, 3 Jul 1999, Janie Dykes wrote: When scouring through the threads - this one in particular caught my attention. In my experience, which is still very new, I think all of you make excellent points. For the most part, the novice/average person, believes that hackers are malicious, destructive individuals. A huge number of computer users are misled and misinformed about the true definition of the term 'hacker'. This is unfortunate - if those people could spend some time reading the brilliant posts to this list, they might realize that we are not all 16 year olds, hiding behind the glow *cough* Care to explain that comment? of the monitor, reading their email and stealing their passwords and credit card information and posting it on IRC. I have a point. :] The first time I experienced that curiosity - I got a little carried away. eh hem I learned that my skills, which included aptness and dexterity, had been misdirected. Upon my awakening, I was blessed with my mentor. He challenged me to use my skills productively. In retrospect, I learned [the hard way] and gained some experience with some help from my mentor [some of you may know Peter Mountain - BRU2000]. All in all, there are many contributing factors to becoming a hacker. I rarely post to this list - so I hope that my lengthy post doesn't offend. So on that note - I will continue observing the minds at work. Thanks for the opportunity to post - Janie Dykes Wes Peters wrote: G. Adam Stanislav wrote: On Sat, Jul 03, 1999 at 01:18:52AM -0600, Wes Peters wrote: You either are a hacker, or you are not. It is not something someone else can teach you. This deserves a FAQ entry. What an awesome response. But it's certainly NOT something that you just are, either. You have to have talent, but you also have to have experience. This is most often done by a mentor. If you have the innate curiosity mentioned in my message, you will obtain experience whether you have a mentor or not. Experience is best obtained by trying things. It cannot be imparted by anyone else (although, it can be encouraged). And, in some cases, disasters averted. I think all of us here have seen a few graphic examples lately of what happens when the mentoring process doesn't work. I think being a hacker is a combination of talent, ethics, and experience. I've known talented and experienced programmers who weren't hackers, either because they didn't have the innate curiousity you mention or because they were ethically challenged and used their skills to steal, cheat, and destroy, which are *not* part of the hacker ethos. Hackers create, crackers steal and destroy. But I'm certain you new that. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poll() vs select()
On Sun, 4 Jul 1999, Peter Wemm wrote: Brian F. Feldman wrote: On Fri, 2 Jul 1999, Jonathan Lemon wrote: In article local.mail.freebsd-hackers/Pine.LNX.3.95.990702160538.27513C-10 0...@crb.crb-web.com you write: now supports the select() and poll() system calls. My question is really one of usage. Why would one us poll() over select()? Is select eventually go ing to go away for some reason? select() as a user-level call will never go away; there is a large base of code that uses it. poll() is faster (it doesn't have to do bit twiddling), and it's interface is cleaner (it can report invalid fd's, something select() can't do). As its functionality is a superset of select()'s, it is used as the internal implementation for select(). Actually, select() doesn't require horrendous amounts of copyin()s, which poll() does. So have you benchmarked the two? I'd expect select to be faster. Actually.. select() has three copyins and three copyouts per call. poll() has one copyin and one copyout per call. But poll() copies in HUGE amounts of data compared to the few bytes for thousands of FDs that select does. Now what I particular like is the event queue system that David Filo put together for Yahoo. In a nutshell you create a queue (a fd), and then register the descriptors you want to monitor with the queue. You then run an accept()-like loop where the accept returns the fd number that has met the conditions you asked for. For example, if you wanted to know if fd number 4251 becomes readable, then the accept would return 4251. This has potential to work across multiple processes sharing a queue so that events could get round robined or whatever. The other good part is that it maintains the state and lists persistantly and doesn't have to keep copying it to/from the kernel. It handles 50,000 to 100,000 connections without too much trouble. You can still use this with select as the queue fd becomes readable when there is an event waiting for your process. Is there interest in doing something like this in general? Yes! That would not replace select() or poll(), but it would be awesome to have! Cheers, -Peter -- Peter Wemm - pe...@freebsd.org; pe...@yahoo-inc.com; pe...@netplex.com.au To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
On Fri, 2 Jul 1999, Anthony Kimball wrote: Lizard has a tetris game built in for those long waits... Now THAT is cool. It's a better idea to not have people waiting for a long time. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lizard...
On Fri, 2 Jul 1999, Anthony Kimball wrote: Lizard has a tetris game built in for those long waits... Now THAT is cool. It's a better idea to not have people waiting for a long time. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poll() vs select()
On Fri, 2 Jul 1999, Jonathan Lemon wrote: In article local.mail.freebsd-hackers/pine.lnx.3.95.990702160538.27513c-100...@crb.crb-web.com you write: now supports the select() and poll() system calls. My question is really one of usage. Why would one us poll() over select()? Is select eventually going to go away for some reason? select() as a user-level call will never go away; there is a large base of code that uses it. poll() is faster (it doesn't have to do bit twiddling), and it's interface is cleaner (it can report invalid fd's, something select() can't do). As its functionality is a superset of select()'s, it is used as the internal implementation for select(). Actually, select() doesn't require horrendous amounts of copyin()s, which poll() does. So have you benchmarked the two? I'd expect select to be faster. As for new code, use whichever you are comfortable with. Personally, I would recommend poll(), since it provides some added functionality over select() that makes for easier programming. poll() is a huge pain to use, which is why I recommend select(). -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: environment strings
On Tue, 29 Jun 1999, Greg Lehey wrote: On Monday, 28 June 1999 at 23:32:59 -0400, Amol Mohite wrote: What I want to know is the exact position of these variables on the stack. As I said, at the top. and if anywhere I can find some data, on the exact compisoition of the stcak, then it will be very helpful. references of books and websites wil be most helpful. I think that, for FreeBSD, the source is the only place you'll find it. There's a brief description in "Porting UNIX Software" (http://www.ora.com/catalog/port/noframes.html), but that's not specific to FreeBSD. That's not true, Greg. I'm sure you of all people know that it (the composition of address space) is described in "The Design and Implementation of the 4.4BSD Operating System," even if things are slightly different in FreeBSD of today (especially addresses.) Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
On Tue, 29 Jun 1999, Brian F. Feldman wrote: That's not true, Greg. I'm sure you of all people know that it (the composition of address space) is described in "The Design and Implementation of the 4.4BSD Operating System," even if things are slightly different in FreeBSD of today (especially addresses.) Should we expect to see something similar in the next revision of your book? Describing this would be nice, because lots of people get curious about this :) Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
On Tue, 29 Jun 1999, Greg Lehey wrote: On Monday, 28 June 1999 at 23:32:59 -0400, Amol Mohite wrote: What I want to know is the exact position of these variables on the stack. As I said, at the top. and if anywhere I can find some data, on the exact compisoition of the stcak, then it will be very helpful. references of books and websites wil be most helpful. I think that, for FreeBSD, the source is the only place you'll find it. There's a brief description in Porting UNIX Software (http://www.ora.com/catalog/port/noframes.html), but that's not specific to FreeBSD. That's not true, Greg. I'm sure you of all people know that it (the composition of address space) is described in The Design and Implementation of the 4.4BSD Operating System, even if things are slightly different in FreeBSD of today (especially addresses.) Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: environment strings
On Tue, 29 Jun 1999, Brian F. Feldman wrote: That's not true, Greg. I'm sure you of all people know that it (the composition of address space) is described in The Design and Implementation of the 4.4BSD Operating System, even if things are slightly different in FreeBSD of today (especially addresses.) Should we expect to see something similar in the next revision of your book? Describing this would be nice, because lots of people get curious about this :) Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Improving the Unix API y,
On Sun, 27 Jun 1999, Alexander Viro wrote:
As for the opening with no permissions - well, it would make *big* sense
if we could narrow down the API and move chown(), chmod(), etc. into libc
leaving f-variants in the kernel. Binary compatibility... Extreme variant
might include {set,get}sockopt extended to files and doing both *stat and
*ch{mod,own,flags} via that. Out of curiosity - did somebody on *BSD side
play with that?
Actually, instead of *big* sense, that makes *no* sense.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Connect and so on..
On Fri, 25 Jun 1999, Mike Smith wrote: static struct sockaddr_in servaddr; This needs to be a valid structure in USER space, not kernel. OK. I suspected as much. Question is: how do I open a connection from KERNEL space? You don't. If you're really desperate to do this, you'll have to patch _all_ of the system calls to work out whether they're being called from the kernel or from userspace. There's actually a lot of utility in this, as it makes calling them easier from ABI modules as well. If you're looking for a nice, relatively easy FreeBSD hacking project, there's one right there. Another argument to the syscall format... I remember we took the retval away (stuck it in proc) and now we could replace it with that. That's beside the point. He doesn't need to initiate the connection in userland, just pass in the context (user-space sockaddr_in) for it to use. The other mistake is he thinks this will make the whole thing atomic... I'm not so sure about that one. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Karl Denninger wrote: On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote: We're adding some machines at work for (essentially) cgi processing only. It was never considered to use anything less than 2 cpu boxes, and the current round of testing is going so well that we're seriously considering 4 cpu boxes because they are not that much more expensive and our processing is highly CPU bound. I agree that redundancy is a good thing, but at some point the increased network latency exceends the point of diminishing returns for the redundancy factor. In short, increasing SMP efficiency should really be a priority for N2 systems. Agreed. But this is a BIG job, because to do that you have to solve the one big kernel lock problem and go to fine-grained locking. This is a non-trivial job. We don't need fine-grained locks. We would get good performance if we could get (say) per-subsystem locks. -- Karl Denninger (k...@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Alfred Perlstein wrote: On Thu, 24 Jun 1999, Karl Denninger wrote: A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. Hey, y'know getppid() is safe, i'll just take the lock out. this function xxx() is safe until this point I can process a lot before actually needing this lock... y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here if I just do this something here, I really am re-entrant and safe.. Providing a simple api for spinlocks and mutexes would be very nice. Something along the lines of how spl()s work? And mutex allocation like what we do with malloc types, maybe? If some of the FreeBSD gods (core) said something along the lines of we'd like to see the process table have XXX method of access and locking people will code it, the same way with the many other subsystems. Things like pmap and UFS and INET will be a royal pain to get SMP safe, however baby steps towards lifting the lock for simpler subsystems will lead the way. FreeBSD has the most intellegent people in the industry working together, all that is needed is a starting point. -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Alfred Perlstein wrote: On Thu, 24 Jun 1999, Brian F. Feldman wrote: On Thu, 24 Jun 1999, Alfred Perlstein wrote: On Thu, 24 Jun 1999, Karl Denninger wrote: A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. Hey, y'know getppid() is safe, i'll just take the lock out. this function xxx() is safe until this point I can process a lot before actually needing this lock... y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here if I just do this something here, I really am re-entrant and safe.. Providing a simple api for spinlocks and mutexes would be very nice. Something along the lines of how spl()s work? And mutex allocation like what we do with malloc types, maybe? I'm not sure what you mean by the refernce to malloc types, I just thought something along the lines of mutex_t with an API for trying, allocating, freeing and initializing them. I meant something like an extensible set of mutex groups, like our kernel malloc uses. New mutex types would be added. Instead of per- function mutexes, a single mutex type could be used for multiple functions that are the same in usage of sensitive resources. Just an idea... Also, some really interesting things could be done via per-CPU resource pools to lower the amount of contention on objects. Pardon the niaveness of this idea, but things like per-CPU malloc areas and each CPU haveing a queue for CPUs if memory is free'd by a processor that down't own it. Things like someone signalling another processor if one of its free queues becomes full, or if a CPU finds its pool exhausted. -Alfred Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Connect and so on..
On Wed, 23 Jun 1999, Dan Seguin wrote:
Hi All.
I'm trying to create a system call that will burst a (pseudo) quick tcp
message out to a remote host every time that it is called. I've got the
system call all worked out as a kld, it loads and restores without a
hitch.
Good, you're mostly there then!
I use the calling proc's table as it is passed to the system call, and am
trying to call socket and connect as if the user process originally called
them one by one (from userland syscall 97 and 98). I seem to be getting
the correct behaviour from socket, but the connect call fails. After
DDB'ing and breaking on the call to connect, it appears to fail at copyin
with an EFAULT (invalid address). Call stack: copyin from getsockaddr from
connect. What am I missing here, and/or what incorrect assumptions have I
made? I'm including the actual system call function below.
copyin() is done to get the sockaddr from the connect call. A copyin() is a
user-space
to kernel-space memory copy, so you have a problem in your code (I'll point out
where
below).
Thanks!
Dan
P.S. I test the system call from userland with a small C prog that uses
syscall().
CODE starts
static int init_comms(p, uap)
struct proc *p;
register struct nosys_args *uap;
{
int sockfd1, stat;
struct socket_args socket_uap;
struct connect_args connect_uap;
static struct sockaddr_in servaddr;
This needs to be a valid structure in USER space, not kernel.
socket_uap.domain = PF_LOCAL;
socket_uap.type = SOCK_STREAM;
socket_uap.protocol = 0;
stat = socket(p, socket_uap);
if (stat)
return stat;
sockfd1 = p-p_retval[0];
bzero(servaddr, sizeof(servaddr));
servaddr.sin_family = AF_LOCAL;
servaddr.sin_port = htons(13);
servaddr.sin_len= sizeof servaddr;
if ( inet_aton((char *) 127.0.0.1, servaddr.sin_addr) = 0 )
This is a bogus cast. const char * to char *?
printf(\ninet_aton failed.\n);
So return EINVAL.
printf(\nservaddr: %x\n, servaddr.sin_addr.s_addr);
AHEM! Why??
/* Prints 17e */
Try using servaddr.sin_addr.saddr = 0;
connect_uap.s = sockfd1;
connect_uap.name = (caddr_t) servaddr;
That's the problem. It needs to point to (say) uap-servaddr;
connect_uap.namelen = sizeof servaddr;
stat = 0;
stat = connect(p, connect_uap);
printf(\nConnect Stat: %d\n, stat);
Take that out.
/* Prints 14 (EFAULT) */
return 0;
return stat instead. The standard is to use a variable named error.
}
- Code Ends ---
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Note that I haven't checked the correctness of the code other than a quick
glance.
These errors are real, though.
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Wed, 23 Jun 1999, Garance A Drosihn wrote: At 4:39 PM +0930 6/23/99, Greg Lehey wrote: On Tuesday, 22 June 1999 at 23:52:25 -0700, Mike Smith wrote: [someone said] | [someone said] | Ok, so let's follow Microsoft's industry-leading documentation | standards. | | He said commercial, not toy. Given that I've just spent a very unhappy couple of weeks demonstrating that this toy you're referring to outperforms us by a factor of anything from 3 to 10 on a range of basic benchmarks, Really? This is so different from anything I've heard that I'm astounded. How about some details? I also found Mike's comment on performance interesting. I assume he's talking about system performance, and not documentation performance. Was this when testing WinNT-2000, or just the latest service pack on WinNT 4? s/interesting/unbelievable/g and you've got my reaction. This makes so little sense that I can't even imagine it. --- Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu Senior Systems Programmer or dro...@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ispell(1) is for WIMPs (was Re: vi(1) is for whimps)
This belongs in freebsd-chat, if anywhere. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/sys/kern imgact_gzip.c
On Tue, 22 Jun 1999, Kris Kennaway wrote:
On Tue, 22 Jun 1999, Brian F. Feldman wrote:
Date: Tue, 22 Jun 1999 01:08:04 -0400 (EDT)
From: Brian F. Feldman gr...@unixhelp.org
To: Kris Kennaway kkenn...@physics.adelaide.edu.au
Cc: Peter Wemm pe...@netplex.com.au, Jean-Marc Zucconi j...@freebsd.org,
h...@freebsd.org, cvs-committ...@freebsd.org, cvs-...@freebsd.org
Subject: Re: cvs commit: src/sys/kern imgact_gzip.c
On Tue, 22 Jun 1999, Kris Kennaway wrote:
On Tue, 22 Jun 1999, Peter Wemm wrote:
Ahh yes, I forgot that / was read-write for MFS boots. However:
#!/bin/sh
skip=18
if /usr/bin/tail +$skip $0 | gzip -cd /tmp/gztmp$$; then
chmod 700 /tmp/gztmp$$
prog=`echo $0 | sed 's|^.*/||'`
if /bin/ln /tmp/gztmp$$ /tmp/$prog 2/dev/null; then
trap '/bin/rm -f /tmp/gztmp$$ /tmp/$prog; exit $res' 0
(/bin/sleep 5; /bin/rm -f /tmp/gztmp$$ /tmp/$prog) 2/dev/null
/tmp/$prog ${1+$@}; res=$?
else
trap '/bin/rm -f /tmp/gztmp$$; exit $res' 0
(/bin/sleep 5; /bin/rm -f /tmp/gztmp$$) 2/dev/null
/tmp/gztmp$$ ${1+$@}; res=$?
fi
else
echo Cannot decompress $0; exit 1
fi; exit $res
This is the unpatched (insecure) version of gzexe (all the
/tmp/gztmp$$'s),
but it's functionally the same.
Now, if tail, sh, gzip, chmod, ln, sleep, rm, etc are all in the gzexe'd
crunched linked binary, how is it supposed to decompress itself? sh
itself
is part of the crunched binary, so what is going to decode sh when sh
itself
is a shell script?
Yes, that seems to be a problem - gzexe depends on those executables.
However
it shouldn't be too hard to recode this decompressor in C to perform the
same
job without any external dependencies. The question is whether that would
be
easier than fixing the kernel to handle gzipped ELF binaries
transparently -
almost certainly it would be.
How's what I attached?
[Context left in for cross-post to hackers]
Hmm..I don't have a deflate on my system. This should be linked static as
well, otherwise you need the runtime linker + libraries, and that has a 69k
overhead (when stripped). Possibly this could be optimized further..I don't
know if this is small enough to be useful however.
It's a proof of concept, it didn't need to be static. I don't have a program
to do deflate either. What I know is that you said it would be hard, but
it was not very hard to make a framework to do what gzexe does in C.
Mike's suggestion of a gzipped MFS image is probably best for things like boot
floppies.
Kris
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
-
Never criticize anybody until you have walked a mile in their shoes,
because by that time you will be a mile away and have their shoes.
-- Unknown
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/sys/kern imgact_gzip.c
On Wed, 23 Jun 1999, Kris Kennaway wrote: On Tue, 22 Jun 1999, Brian F. Feldman wrote: Hmm..I don't have a deflate on my system. This should be linked static as well, otherwise you need the runtime linker + libraries, and that has a 69k overhead (when stripped). Possibly this could be optimized further..I don't know if this is small enough to be useful however. It's a proof of concept, it didn't need to be static. I don't have a program to do deflate either. What I know is that you said it would be hard, but it was not very hard to make a framework to do what gzexe does in C. Actually: The question is whether that would be easier than fixing the kernel to handle gzipped ELF binaries transparently - almost certainly it would be. I said it would be easy(ier) :) FWIW, compiling libc.a and libz.a with -Os brings the overhead down to 67416 bytes per executable. Linked dynamically it's 4829 bytes (i.e. the other 62k is library code), so it doesn't look like there's much room for improvement. This sure seems like enough to replace a.out gzip support. Taking the compression/decompression routines out of the kernel would save memory and result in roughly the same amount of space being used. If we had a deflate program, this would work quite well =) Kris - Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes. -- Unknown To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: Re: misc/11796: Bad lines in 3.2-RELEASE inetd.conf]
By the way, I'd recommend all -CURRENT users, after making world, make a new copy of pidentd. The code to grovel through the kernel to find socket info is MUCH less sickening now, so identd is less of a performance hit and less likely to fail due to race conditions. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Introduction
On Sat, 19 Jun 1999, Doug Rabson wrote: On 19 Jun 1999, Dag-Erling Smorgrav wrote: Ruslan Ermilov r...@ucb.crimea.ua writes: * Clean the existing code (both userland and kernel) (10-20% done) * Re-design the ipfw's API * Port the existing functionality to the new API * Proceed with new features Pretty please with sugar on top, design an API that can be extended without breaking binary compatibility. We've had too much of that for no good reason (at least once between 2.2.7 and 2.2.8, and once between 3.1 and 3.2). As far as possible, all new apis in the kernel should be designed with a stable ABI. Its pretty simple if you follow a few simple rules: 1. Hide implementation data structures. Access all information outside the core implementation using function calls. 2. Try to avoid using complex structures in the api. Each structure in an api defines part of its ABI. Changing that structure later breaks the ABI. 3. Keep the external api as simple as possible. As a rule of thumb, try to write manpages for each function. If you can't describe the function accurately and concisely in a manpage then its too complex. It might be worth (discussion of) making ipfilter the firewall of choice for 4.0. There would of course be rule conversion scripts/programs (ipfw-ipf(5)), and ipfilter would be converted to a KLD, cruft removed (I'm going to work on these), and ipfilter KLD support (currently options IPFILTER_LKM) made a non-option. It seems that our pretty proprietary ipfw is no longer a good idea. And if Luigi ported all of his stuff to ipfilter from ipfw, and I did per-[ug]id support for ipfilter (which I will), we'll definitely be ahead. Ipfilter is a win for compatibilty/ubiquity, and seems to be faster than ipfw anyway. Are there any technical arguments against ipfilter or for ipfw? Note that: political arguments do not count, a conversion method will be available for ipfw users, and we should have anything special (DummyNet, uid/gid-based filtering) ported over to ipfilter. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd.Phone: +44 181 442 9037 Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Firewalls (was Re: Introduction)
On 19 Jun 1999, Dag-Erling Smorgrav wrote: Brian F. Feldman gr...@unixhelp.org writes: It might be worth (discussion of) making ipfilter the firewall of choice for 4.0. There would of course be rule conversion scripts/programs (ipfw-ipf(5)), and ipfilter would be converted to a KLD, cruft removed (I'm going to work on these), and ipfilter KLD support (currently options IPFILTER_LKM) made a non-option. It seems that our pretty proprietary ipfw is no longer a good idea. If ipfilter can to everything ipfw can (judging from ipf(5), it can) and you even manage to keep an ipfw(8) command around so those who want kan keep using the old syntax still can, then I for one have no objections. Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a simple Perl script should be sufficient. Not quite as trivial as you think. ipfw and ipf are completely backwards when it comes to rule order: in ipfw, the first rule matched takes effect; in ipf, the last rule matched takes effect. Plus, ipf doesn't have rule numbers (but there's similar functionailty.) If you think you can get used to them both enough to tackle this, I'll handle other things, and we can have a working replacement for crufty old ipfw. Note that Luigi's extra ipfw functionality and my extra ipfw functionality _will_ be wanted in ipf before everyone is necessarily willing to switch. I have a feeling there will be some holdouts that, even if ipfw is removed, they'll MFS (merge from stable) ipfw back just because they want to keep the old way. Ipfw could be dead for 4.0-RELEASE, as I see it now. More discussion is, however, necessary. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Introduction
On Sat, 19 Jun 1999, Doug Rabson wrote: On 19 Jun 1999, Dag-Erling Smorgrav wrote: Brian F. Feldman gr...@unixhelp.org writes: It might be worth (discussion of) making ipfilter the firewall of choice for 4.0. There would of course be rule conversion scripts/programs (ipfw-ipf(5)), and ipfilter would be converted to a KLD, cruft removed (I'm going to work on these), and ipfilter KLD support (currently options IPFILTER_LKM) made a non-option. It seems that our pretty proprietary ipfw is no longer a good idea. If ipfilter can to everything ipfw can (judging from ipf(5), it can) and you even manage to keep an ipfw(8) command around so those who want kan keep using the old syntax still can, then I for one have no objections. Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a simple Perl script should be sufficient. Does ipfilter support divert sockets? It still needs: divert sockets Luigi's stuff (dummynet and bridging) my stuff -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd.Phone: +44 181 442 9037 Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Firewalls (was Re: Introduction)
On 19 Jun 1999, Dag-Erling Smorgrav wrote: Brian F. Feldman gr...@unixhelp.org writes: On 19 Jun 1999, Dag-Erling Smorgrav wrote: Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a simple Perl script should be sufficient. Not quite as trivial as you think. ipfw and ipf are completely backwards when it comes to rule order: in ipfw, the first rule matched takes effect; in ipf, the last rule matched takes effect. Just throw in 'quick' and ipfilter behaves just like ipfw. I figured that out. Come to think of it, I rather like quick much better than ipf's default way. Note that Luigi's extra ipfw functionality and my extra ipfw functionality _will_ be wanted in ipf before everyone is necessarily willing to switch. Divert sockets, dummynet and credential-based filtering would be sorely missed if they weren't ported to ipfilter. Definitely. Working on ipfilter is probably better than reinventing the wheel again. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Introduction
It has fwd stuff :) Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Firewalls (was Re: Introduction)
On Sat, 19 Jun 1999, Julian Elischer wrote: As a contributor to ipfw, notice that I will be sticking my oar into the water when it comes to deleting it unless I'm very sure that the ipf stuff is better. Unless you're Danish you don't just get to delete bits of the tree without a lot of agreement, especially from those who are working on it.. (in this case luigi and I would both be extrememly interested). Deleting IPFW would be a _long_ time from now, if at all. What it looks like now is: 1. making ipf and ipfw equivalent in functionality 2. cleaning up both 3. MAYBE starting a brand new firewall project I wasn't planning on trying to rip something out from under anyone :) On Sat, 19 Jun 1999, Brian F. Feldman wrote: On 19 Jun 1999, Dag-Erling Smorgrav wrote: Brian F. Feldman gr...@unixhelp.org writes: It might be worth (discussion of) making ipfilter the firewall of choice for 4.0. There would of course be rule conversion scripts/programs (ipfw-ipf(5)), and ipfilter would be converted to a KLD, cruft removed (I'm going to work on these), and ipfilter KLD support (currently options IPFILTER_LKM) made a non-option. It seems that our pretty proprietary ipfw is no longer a good idea. If ipfilter can to everything ipfw can (judging from ipf(5), it can) and you even manage to keep an ipfw(8) command around so those who want kan keep using the old syntax still can, then I for one have no objections. Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a simple Perl script should be sufficient. Not quite as trivial as you think. ipfw and ipf are completely backwards when it comes to rule order: in ipfw, the first rule matched takes effect; in ipf, the last rule matched takes effect. Plus, ipf doesn't have rule numbers (but there's similar functionailty.) If you think you can get used to them both enough to tackle this, I'll handle other things, and we can have a working replacement for crufty old ipfw. Note that Luigi's extra ipfw functionality and my extra ipfw functionality _will_ be wanted in ipf before everyone is necessarily willing to switch. I have a feeling there will be some holdouts that, even if ipfw is removed, they'll MFS (merge from stable) ipfw back just because they want to keep the old way. Ipfw could be dead for 4.0-RELEASE, as I see it now. More discussion is, however, necessary. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
