Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x

2005-10-27 Thread Jason Thorpe
On Oct 26, 2005, at 10:22 AM, Bill Studenmund wrote: In the past, we (NetBSD folks) have talked about a devfs. One issue that has come up (I'll be honest, I've raised it a lot) is a desire to retain permission changes across boots, and to tie devices (when possible) to a device-specific

Re: FUD about CGD and GBDE

2005-03-05 Thread Jason Thorpe
On Mar 2, 2005, at 4:33 PM, ALeine wrote: You need 2^128 steps to break the encryption of a single sector. But you have no idea which of the 2^128 sectors is the right one, You may not know for sure, but you can make a pretty well educated guess. You are basically ignoring Roland's argument that

Re: kqueue, NOTE_EOF

2003-11-12 Thread Jason Thorpe
On Nov 12, 2003, at 10:40 AM, marius aamodt eriksen wrote: correct - this is the difference, kqueue will not yield any event at EOF. So, kqueue should simply be changed to report the event. I don't see any need for a separate EOF flag. EOF can simply be determined as normal in the kqueue case

Re: kqueue, NOTE_EOF

2003-11-12 Thread Jason Thorpe
On Nov 12, 2003, at 10:57 AM, marius aamodt eriksen wrote: right - the idea was to preserve existing semantics, while leaving the poll-like semantics optional. I'm not sure the existing semantics are anything more than a bug that should be fixed. -- Jason R. Thorpe [EMAIL PROTECTED]

Re: USB ethernet hacking

1999-12-20 Thread Jason Thorpe
On Sun, 19 Dec 1999 17:18:37 -0500 (EST) Bill Paul [EMAIL PROTECTED] wrote: Because this is not an asynchronous task that I'm trying to do here. I'm talking about reading and writing registers from the ethernet controller. If this was a PCI device, I'd be using

Re: Crypto in the kernel: where how?

1999-12-09 Thread Jason Thorpe
On Thu, 9 Dec 1999 17:01:38 -0800 (PST) Archie Cobbs [EMAIL PROTECTED] wrote: What is the plan (if any) for including crypto stuff in the kernel? As time goes on this will be more and more needed, eg. for IPSec and other VPN applications. At NetBSD, we already solved this problem with

Re: ip forwarding broken on alpha

1999-10-28 Thread Jason Thorpe
On Thu, 28 Oct 1999 21:32:51 -0400 (EDT) Andrew Gallatin [EMAIL PROTECTED] wrote: exception_return skipped the ipl lowering the check for an ast since I don't think you're ever going to need to check for an ast after an interrupt. Nonsense. ASTs are a key part of process

Re: FreeBSD and HP Jornado

1999-10-16 Thread Jason Thorpe
On Fri, 15 Oct 1999 17:29:07 -0700 Edward Elhauge [EMAIL PROTECTED] wrote: My other questions is if is a way of replacing the CE OS with something easier to customize and that might run either Perl or Java? What sort of processor does the Jornado have? If it's a MIPS-based machine,

Re: FreeBSD and HP Jornado

1999-10-16 Thread Jason Thorpe
On Sat, 16 Oct 1999 17:57:37 +0100 (BST) Robert Swindells [EMAIL PROTECTED] wrote: The high end one (820 ?) has a 190MHz SA1100 StrongArm. I don't think that there is any support in NetBSD/arm32 for either the SA1100 or SA1110. No, but it probably wouldn't be that hard to make it go

Re: alpha scheduling needs some tuning

1999-10-12 Thread Jason Thorpe
On Tue, 12 Oct 1999 23:37:53 -0400 (EDT) Andrew Gallatin [EMAIL PROTECTED] wrote: Has anybody noticed that scheduling appears to be broken on the alpha? On both i386 alpha, try: echo "main(){for(;;);}" foo.c cc foo.c /usr/bin/nice -20 ./a.out ; ./a.out FWIW, Ross Harvey

Re: TLB miss handler for alpha running FreeBSD-4.0

1999-09-17 Thread Jason Thorpe
On Thu, 16 Sep 1999 23:10:21 -0500 (CDT) Mohit Aron a...@cs.rice.edu wrote: ...well, I'm speaking from the NetBSD perspective, but it's the same in FreeBSD, because both use the OSF/1 PALcode... as I understand it, TLB misses on the alpha are handled by the software (as opposed to

Re: Tulip device driver question

1999-09-08 Thread Jason Thorpe
On Wed, 8 Sep 1999 10:12:51 -0400 (EDT) Bill Paul [EMAIL PROTECTED] wrote: Well, yes, but I made some assumptions in order to do it. The assumption is that whatever the current speed setting is now, the link partner's speed setting is exactly opposite. So if I detect the condition, I

Re: Tulip device driver question

1999-09-08 Thread Jason Thorpe
On Wed, 8 Sep 1999 00:17:52 +0200 (CEST) Wilko Bulte [EMAIL PROTECTED] wrote: There was also an DE-422 EISA card. Dunno if they are different. I'm not sure what a DE-422 had on it... Matt? Do you have/want one? I could try to get you one. EISA is dead of course, but older machines

Re: Tulip device driver question

1999-09-08 Thread Jason Thorpe
On Wed, 8 Sep 1999 10:12:51 -0400 (EDT) Bill Paul wp...@skynet.ctr.columbia.edu wrote: Well, yes, but I made some assumptions in order to do it. The assumption is that whatever the current speed setting is now, the link partner's speed setting is exactly opposite. So if I detect the

Re: Tulip device driver question

1999-09-08 Thread Jason Thorpe
On Wed, 8 Sep 1999 00:17:52 +0200 (CEST) Wilko Bulte wi...@yedi.iaf.nl wrote: There was also an DE-422 EISA card. Dunno if they are different. I'm not sure what a DE-422 had on it... Matt? Do you have/want one? I could try to get you one. EISA is dead of course, but older machines tend

Re: Tulip device driver question

1999-09-07 Thread Jason Thorpe
On Tue, 7 Sep 1999 03:11:24 -0400 (EDT) Bill Paul [EMAIL PROTECTED] wrote: The SiS 900 only has one combined status/control word in its descriptor structure (some of the bits mean different things depending on whether the descriptors are in the RX ring or TX ring) instead of a

Re: Tulip device driver question

1999-09-07 Thread Jason Thorpe
On Tue, 7 Sep 1999 21:13:22 -0400 (EDT) Bill Paul [EMAIL PROTECTED] wrote: Well, the older chipsets make it even harder on you: you have to know just the right way to twiddle the bits in the GPIO register in order to program the media settings, and to figure that out you're supposed to

Re: Tulip device driver question

1999-09-07 Thread Jason Thorpe
On Tue, 7 Sep 1999 03:11:24 -0400 (EDT) Bill Paul wp...@skynet.ctr.columbia.edu wrote: The SiS 900 only has one combined status/control word in its descriptor structure (some of the bits mean different things depending on whether the descriptors are in the RX ring or TX ring) instead of

Re: Tulip device driver question

1999-09-07 Thread Jason Thorpe
On Tue, 7 Sep 1999 21:13:22 -0400 (EDT) Bill Paul wp...@skynet.ctr.columbia.edu wrote: Well, the older chipsets make it even harder on you: you have to know just the right way to twiddle the bits in the GPIO register in order to program the media settings, and to figure that out you're

Re: Tulip device driver question

1999-09-06 Thread Jason Thorpe
On Fri, 03 Sep 1999 16:23:00 -0600 Wes Peters w...@softweyr.com wrote: See, for instance, the al, ax, mx, pn, vr, and wb drivers. ;^) ^^ Especially this one.. it's not a Tulip clone :-) Oh? vr(4) disagrees:

Re: Tulip device driver question

1999-09-01 Thread Jason Thorpe
On Wed, 01 Sep 1999 15:46:40 -0600 Wes Peters [EMAIL PROTECTED] wrote: Is this a real tulip, or one of the recent clones? Bill Paul has written a number of drivers for various near clones of the Tulip, none of which work quite like the Tulip (of course). See, for instance, the al,

Re: Tulip device driver question

1999-09-01 Thread Jason Thorpe
On Wed, 01 Sep 1999 15:46:40 -0600 Wes Peters w...@softweyr.com wrote: Is this a real tulip, or one of the recent clones? Bill Paul has written a number of drivers for various near clones of the Tulip, none of which work quite like the Tulip (of course). See, for instance, the al,

Re: undocumented vfork behaviour?

1999-08-26 Thread Jason Thorpe
On Fri, 27 Aug 1999 02:20:52 + (GMT) Terry Lambert [EMAIL PROTECTED] wrote: This is a bug. ...but it's a bug in fork(), too. Not just vfork(). For other bugs in vfork(), look at the fact that the vacation program does not correctly deal with messages. ...fwiw, NetBSD fixed the

Re: undocumented vfork behaviour?

1999-08-26 Thread Jason Thorpe
On Fri, 27 Aug 1999 02:20:52 + (GMT) Terry Lambert tlamb...@primenet.com wrote: This is a bug. ...but it's a bug in fork(), too. Not just vfork(). For other bugs in vfork(), look at the fact that the vacation program does not correctly deal with messages. ...fwiw, NetBSD fixed the

Re: setting up -STABLE for hack contest

1999-08-23 Thread Jason Thorpe
On Mon, 23 Aug 1999 17:44:47 -0700 "Dave Walton" [EMAIL PROTECTED] wrote: Hm, just did that. While reading up on nmap, I saw this: "TCP Initial Window -- This simply involves checking the window size on returned packets. [...] In their "completely rewritten" TCP stack for

Re: SPARC?

1999-08-23 Thread Jason Thorpe
On Mon, 23 Aug 1999 11:28:20 -0400 Dennis den...@etinc.com wrote: I heard a rumor that freebsd runs on a sparc, but I dont see any backing for that. Is it in the works? FreeBSD does not run on the SPARC. I think they've been talking about it for ... what, 5 years now... but it never

Re: setting up -STABLE for hack contest

1999-08-23 Thread Jason Thorpe
On Mon, 23 Aug 1999 17:44:47 -0700 Dave Walton wal...@nordicrecords.com wrote: Hm, just did that. While reading up on nmap, I saw this: TCP Initial Window -- This simply involves checking the window size on returned packets. [...] In their completely rewritten TCP stack

Re: mmap mapped segment length

1999-08-21 Thread Jason Thorpe
On Sat, 21 Aug 1999 02:10:47 -0600 Wes Peters [EMAIL PROTECTED] wrote: I discovered to my dismay today that the length field in the mmap call is a size_t, not an off_t. I was attempting to process a large (~50 MByte) file and found I was only processing the first 4 MBytes of it.

Re: mmap mapped segment length

1999-08-21 Thread Jason Thorpe
On Sat, 21 Aug 1999 02:10:47 -0600 Wes Peters w...@softweyr.com wrote: I discovered to my dismay today that the length field in the mmap call is a size_t, not an off_t. I was attempting to process a large (~50 MByte) file and found I was only processing the first 4 MBytes of it.

Re: BSD XFS Port BSD VFS Rewrite

1999-08-14 Thread Jason Thorpe
On Sat, 14 Aug 1999 10:38:17 -0700 Mike Smith [EMAIL PROTECTED] wrote: What the GPL does is require that full source for the program be included with the program, and that full source, in my example, would include a BSD-licensed XFS module. It also requires that the GPL be

Re: BSD XFS Port BSD VFS Rewrite

1999-08-14 Thread Jason Thorpe
On Fri, 13 Aug 1999 21:46:27 -0700 Mike Smith m...@smith.net.au wrote: So, if they were to simply put a BSD license on the code, then everyone would be happy, and there wouldn't be any of the dual-license confusion. It doesn't work like that; once it's been distributed with Linux

Re: BSD XFS Port BSD VFS Rewrite

1999-08-14 Thread Jason Thorpe
On Sat, 14 Aug 1999 10:38:17 -0700 Mike Smith m...@smith.net.au wrote: What the GPL does is require that full source for the program be included with the program, and that full source, in my example, would include a BSD-licensed XFS module. It also requires that the GPL be

Re: BSD XFS Port BSD VFS Rewrite

1999-08-13 Thread Jason Thorpe
On Fri, 13 Aug 1999 22:49:14 + (GMT) Terry Lambert [EMAIL PROTECTED] wrote: Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? SGI is plummetting to their

Re: BSD XFS Port BSD VFS Rewrite

1999-08-13 Thread Jason Thorpe
On Fri, 13 Aug 1999 19:49:10 -0400 (EDT) James Howard [EMAIL PROTECTED] wrote: I did, they have a feedback form I filled out yesterday. I mentioned that and that if they dual licensed the code, it could be used by the entire free software community, not just the hip Linux crowd and also

Re: BSD XFS Port BSD VFS Rewrite

1999-08-13 Thread Jason Thorpe
On Fri, 13 Aug 1999 22:49:14 + (GMT) Terry Lambert tlamb...@primenet.com wrote: Has anyone mentioned to them that they will be unable to incorporate changes made to the GPL'ed version of XFS back into the IRIX version of XFS, without IRIX becoming GPL'ed? SGI is plummetting to their

Re: BSD XFS Port BSD VFS Rewrite

1999-08-13 Thread Jason Thorpe
On Fri, 13 Aug 1999 19:49:10 -0400 (EDT) James Howard howar...@wam.umd.edu wrote: I did, they have a feedback form I filled out yesterday. I mentioned that and that if they dual licensed the code, it could be used by the entire free software community, not just the hip Linux crowd and

Re: BSD XFS Port BSD VFS Rewrite

1999-08-13 Thread Jason Thorpe
On Fri, 13 Aug 1999 19:37:42 -0700 (PDT) Kris Kennaway k...@hub.freebsd.org wrote: So, if they were to simply put a BSD license on the code, then everyone would be happy, and there wouldn't be any of the dual-license confusion. Unfortunately, by BSD-licensing the XFS code, SGI would

Re: BSD XFS Port BSD VFS Rewrite

1999-08-12 Thread Jason Thorpe
On 12 Aug 1999 11:01:06 +0200 Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: This prevents you from relicensing BSD software under the GPL. It does not prevent you from selling an OS that has both BSD and GPL bits, as long as the GPL bits come with full source. If you have an executable

Re: BSD XFS Port BSD VFS Rewrite

1999-08-12 Thread Jason Thorpe
On 12 Aug 1999 11:01:06 +0200 Dag-Erling Smorgrav d...@flood.ping.uio.no wrote: This prevents you from relicensing BSD software under the GPL. It does not prevent you from selling an OS that has both BSD and GPL bits, as long as the GPL bits come with full source. If you have an

Re: mmap bug

1999-08-11 Thread Jason Thorpe
On Wed, 11 Aug 1999 20:48:08 +0400 (MSD) Oleg Derevenetz [EMAIL PROTECTED] wrote: This small program, running as 'mmap', not 'mmap -u', can hang my machine. Is this a known bug in FreeBSD's kernel, or it is my fantasy ? Thank you for answer. If it hangs your system, must be a bug in

Re: mmap bug

1999-08-11 Thread Jason Thorpe
On Wed, 11 Aug 1999 20:48:08 +0400 (MSD) Oleg Derevenetz o...@oleg.sani-c.vrn.ru wrote: This small program, running as 'mmap', not 'mmap -u', can hang my machine. Is this a known bug in FreeBSD's kernel, or it is my fantasy ? Thank you for answer. If it hangs your system, must be a bug

Re: BSD-XFS Update

1999-08-11 Thread Jason Thorpe
On Wed, 11 Aug 1999 16:46:46 -0500 Alton, Matthew matthew.al...@anheuser-busch.com wrote: I am currently researching methods for implementing the 64-bit syscalls stat64(), fstat64(), lseek64() etc. delineated in the SGI design doc _64 Bit File Access_ by Adam Sweeney. ...which, of

Re: Berkeley IRS and NSS

1999-08-03 Thread Jason Thorpe
On Tue, 3 Aug 1999 11:28:29 -0600 Oscar Bonilla [EMAIL PROTECTED] wrote: Anyone knows about the BSD Information Retrieval Service (IRS) mentioned in http://www.padl.com/nss_ldap.html ? It seems to accomplish the same thing as the NSS stuff we've been talking about. In NetBSD, we

Re: Berkeley IRS and NSS

1999-08-03 Thread Jason Thorpe
On Tue, 3 Aug 1999 11:28:29 -0600 Oscar Bonilla oboni...@fisicc-ufm.edu wrote: Anyone knows about the BSD Information Retrieval Service (IRS) mentioned in http://www.padl.com/nss_ldap.html ? It seems to accomplish the same thing as the NSS stuff we've been talking about. In NetBSD, we

Re: MADV_SEQUENTIAL and GNU Grep

1999-07-29 Thread Jason Thorpe
On Thu, 29 Jul 1999 10:21:52 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: I'm testing it now along with the madvise(... MADV_DONTNEED) changes (to make them work on files in a reasonable way). When I implemented MADV_DONTNEED and MADV_FREE in NetBSD (UVM):

Re: MADV_SEQUENTIAL and GNU Grep

1999-07-29 Thread Jason Thorpe
On Fri, 30 Jul 1999 01:50:28 +0900 "Daniel C. Sobral" [EMAIL PROTECTED] wrote: Could you please elaborate on "permanent"? To what structure the information is currently attached, and what, if anything, can make that structure "go away", short of a reboot? As permanent as the object ...

Re: MADV_SEQUENTIAL and GNU Grep

1999-07-29 Thread Jason Thorpe
On Thu, 29 Jul 1999 09:26:12 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: Yes, it will work. Oops. I do see one problem though... if you do this the underlying file object will be marked for sequential operation even after the grep (in this case) exits. That is, an

Re: MADV_SEQUENTIAL and GNU Grep

1999-07-29 Thread Jason Thorpe
On Thu, 29 Jul 1999 10:52:02 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: Yes, we already do this, but only for OBJT_DEFAULT and OBJT_SWAP objects. We do not do this for file objects... it would make me rather nervous if we did :-) Why? I can think of at

Re: MADV_SEQUENTIAL and GNU Grep

1999-07-29 Thread Jason Thorpe
On Thu, 29 Jul 1999 10:21:52 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: Shoot, it barely took 10 minutes for me to move the behavior field from the object to the vm map entry. ...make sure the map entries are clipped properly. It's easy to miss this in the most

Re: MADV_SEQUENTIAL and GNU Grep

1999-07-29 Thread Jason Thorpe
On Thu, 29 Jul 1999 10:21:52 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: I'm testing it now along with the madvise(... MADV_DONTNEED) changes (to make them work on files in a reasonable way). When I implemented MADV_DONTNEED and MADV_FREE in NetBSD (UVM):

Re: MADV_SEQUENTIAL and GNU Grep

1999-07-29 Thread Jason Thorpe
On Fri, 30 Jul 1999 01:50:28 +0900 Daniel C. Sobral d...@newsguy.com wrote: Could you please elaborate on permanent? To what structure the information is currently attached, and what, if anything, can make that structure go away, short of a reboot? As permanent as the object ... i.e. as

Re: MADV_SEQUENTIAL and GNU Grep

1999-07-29 Thread Jason Thorpe
On Thu, 29 Jul 1999 09:26:12 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: Yes, it will work. Oops. I do see one problem though... if you do this the underlying file object will be marked for sequential operation even after the grep (in this case) exits.

Re: SMC 1211TX

1999-07-27 Thread Jason Thorpe
On Tue, 27 Jul 1999 14:14:33 -0700 "Kelly D. Lucas" [EMAIL PROTECTED] wrote: Is there a FreeBSD driver the the SMC 1211TX 10/100 EZ Ethernet Card? As far as I can tell, this is a RealTek 8139 board. -- Jason R. Thorpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL

Re: SMC 1211TX

1999-07-27 Thread Jason Thorpe
On Wed, 28 Jul 1999 09:44:03 +0800 Peter Wemm [EMAIL PROTECTED] wrote: As far as I can tell, this is a RealTek 8139 board. Oh my, SMC must be really lowering their standards... The SMC9432TX is still an EPIC/100. The newer revs of that board are bug-free (unlike earlier models).

Re: SMC 1211TX

1999-07-27 Thread Jason Thorpe
On Tue, 27 Jul 1999 14:14:33 -0700 Kelly D. Lucas k...@securify.com wrote: Is there a FreeBSD driver the the SMC 1211TX 10/100 EZ Ethernet Card? As far as I can tell, this is a RealTek 8139 board. -- Jason R. Thorpe thor...@nas.nasa.gov To Unsubscribe: send mail to

Re: SMC 1211TX

1999-07-27 Thread Jason Thorpe
On Wed, 28 Jul 1999 09:44:03 +0800 Peter Wemm pe...@netplex.com.au wrote: As far as I can tell, this is a RealTek 8139 board. Oh my, SMC must be really lowering their standards... The SMC9432TX is still an EPIC/100. The newer revs of that board are bug-free (unlike earlier models).

Re: PAM LDAP in FreeBSD, and userfs too.

1999-07-20 Thread Jason Thorpe
On Tue, 20 Jul 1999 10:02:43 +0100 Dominic Mitchell [EMAIL PROTECTED] wrote: How will you get around one of the major bugbears of the Solaris implementation, that is nscd serialises access to these databases? I understand that the caching will allow you to return most responses

Re: PAM LDAP in FreeBSD, and userfs too.

1999-07-20 Thread Jason Thorpe
On Tue, 20 Jul 1999 10:02:43 +0100 Dominic Mitchell dom.mitch...@palmerharvey.co.uk wrote: How will you get around one of the major bugbears of the Solaris implementation, that is nscd serialises access to these databases? I understand that the caching will allow you to return most

Re: PAM LDAP in FreeBSD, and userfs too.

1999-07-19 Thread Jason Thorpe
On Mon, 19 Jul 1999 20:44:18 +0100 Dominic Mitchell [EMAIL PROTECTED] wrote: Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... The plan for NetBSD is

Re: PAM LDAP in FreeBSD, and userfs too.

1999-07-19 Thread Jason Thorpe
On Mon, 19 Jul 1999 20:44:18 +0100 Dominic Mitchell dom.mitch...@palmerharvey.co.uk wrote: Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... The plan for

Re: PAM LDAP in FreeBSD

1999-07-19 Thread Jason Thorpe
On Mon, 19 Jul 1999 15:47:33 -0400 David E. Cross cro...@cs.rpi.edu wrote: PAM isn't going to cut it. This is outside of its realm. Things like ps, top, ls, chown, chmod, lpr, rcmd, who, w, (the list goes on) need to be able to pull 'passwd' entries from the LDAP server, and unless we

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Jason Thorpe
On Tue, 13 Jul 1999 23:18:58 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: What does that have to do with overcommit? I student administrate a undergrad CS lab at a university, and when student's programs misbehaved, they generate a fault and are killed. The only machines that

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Jason Thorpe
On Wed, 14 Jul 1999 12:43:07 + Niall Smart [EMAIL PROTECTED] wrote: Perhaps it could be an additional flag to mmap, in this way people wishing to run an overcommited system could do so but those writing programs which must not overcommit for certain memory allocations could ensure

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Jason Thorpe
On Thu, 15 Jul 1999 01:52:11 +0900 "Daniel C. Sobral" [EMAIL PROTECTED] wrote: ...um, so, make the code that deals with faulting in the stack a bit smarter. Uh? Like what? Like overcommitting, for instance? The beauty of overcommitting is that either you do it or you don't. :-) One

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Jason Thorpe
On Thu, 15 Jul 1999 01:59:12 +0900 "Daniel C. Sobral" [EMAIL PROTECTED] wrote: That's why you make it a switch. No, really, you *can* just make it a switch. So, enlighten me, please... how do you switch it in NetBSD? When the code to do it is implemented (not that hard, really,

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Jason Thorpe
On Tue, 13 Jul 1999 23:18:58 -0400 (EDT) John Baldwin jobal...@vt.edu wrote: What does that have to do with overcommit? I student administrate a undergrad CS lab at a university, and when student's programs misbehaved, they generate a fault and are killed. The only machines that

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Jason Thorpe
On Wed, 14 Jul 1999 12:43:07 + Niall Smart ni...@pobox.com wrote: Perhaps it could be an additional flag to mmap, in this way people wishing to run an overcommited system could do so but those writing programs which must not overcommit for certain memory allocations could ensure

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Jason Thorpe
On Thu, 15 Jul 1999 01:52:11 +0900 Daniel C. Sobral d...@newsguy.com wrote: ...um, so, make the code that deals with faulting in the stack a bit smarter. Uh? Like what? Like overcommitting, for instance? The beauty of overcommitting is that either you do it or you don't. :-) One

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Jason Thorpe
On Thu, 15 Jul 1999 01:59:12 +0900 Daniel C. Sobral d...@newsguy.com wrote: That's why you make it a switch. No, really, you *can* just make it a switch. So, enlighten me, please... how do you switch it in NetBSD? When the code to do it is implemented (not that hard, really, and it

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 10:11:14 -0400 (EDT) "Brian F. Feldman" [EMAIL PROTECTED] wrote: SVR4 has MAP_NORESERVE option for mmap(2) for this. So, default behaivour don't have to be overcommitment. Isn't that just like mmap()ing then mlock()ing the range? That would keep it in core.

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 11:13:49 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: SysV was totally and utterly broken in regards to swap allocation. The only major operating system that used it as a base was IRIX and SGI found out very quickly that pre-reserving swap is a

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 11:59:25 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: 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

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 14:14:52 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: If you don't have the disk necessary for a standard overcommit model to work, you definitely do not have the disk necessary for a non-overcommit model to work. You obviously didn't pay

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 14:16:54 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: ... and it doesn't mean squat. What, the absolutely critical server that you are trying to run decides to exit because it can't guarentee sufficient backing store? First of all, this situation

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 14:27:54 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: You are assuming that the situation actually occurs. In real life, it will not occur unless the critical server is running away with memory. I have never, ever run one of BEST's servers

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 14:31:38 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: :- I might be creating a very limited embedded system with just a few : small processes that are all written to *handle* out of memory situations. Really? Then setting resource limits from within

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 14:56:52 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: Jason, I am using real life situations to demonstrate my point. You are perfectly welcome to use your own REAL-LIFE situations to demonstrate yours. It is the real-life application that

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 15:37:26 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: When you write embedded systems like these, you do not run any general purpose binaries at all. You run fully custom binaries and you take control of the memory management yourself. Heh,

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 16:16:07 -0700 Mike Smith [EMAIL PROTECTED] wrote: Matt's point, which he's not making by virtue of talking too much, is that you can't make a "no overcommit" system behave like an "overcommit" system, and most people are used to the sort of things that the latter

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 16:24:53 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: I'm sure the feeling is mutual. More to the point, I really seriously doubt that any of the core developers would consider this idea either because it's been rejected in the past and, so far,

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 16:29:50 -0700 Mike Smith [EMAIL PROTECTED] wrote: You can make the "overcommit or not overcommit" option a switch, but the consumers of the system (may) need to change their behaviour as well. I never said they wouldn't have to. -- Jason R. Thorpe [EMAIL

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 16:56:26 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: You have to consider the probability of an event occuring, not just the possibility that the event might occur. If the probability is one in a million years, then it is not something you need

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 10:11:14 -0400 (EDT) Brian F. Feldman gr...@freebsd.org wrote: SVR4 has MAP_NORESERVE option for mmap(2) for this. So, default behaivour don't have to be overcommitment. Isn't that just like mmap()ing then mlock()ing the range? That would keep it in core. No,

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 11:13:49 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: SysV was totally and utterly broken in regards to swap allocation. The only major operating system that used it as a base was IRIX and SGI found out very quickly that pre-reserving swap

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 11:59:25 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: 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

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 14:14:52 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: If you don't have the disk necessary for a standard overcommit model to work, you definitely do not have the disk necessary for a non-overcommit model to work. You obviously didn't pay

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 14:16:54 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: ... and it doesn't mean squat. What, the absolutely critical server that you are trying to run decides to exit because it can't guarentee sufficient backing store? First of all, this

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 14:27:54 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: You are assuming that the situation actually occurs. In real life, it will not occur unless the critical server is running away with memory. I have never, ever run one of

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 14:31:38 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: :- I might be creating a very limited embedded system with just a few : small processes that are all written to *handle* out of memory situations. Really? Then setting resource limits from

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 14:56:52 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: Jason, I am using real life situations to demonstrate my point. You are perfectly welcome to use your own REAL-LIFE situations to demonstrate yours. It is the real-life application

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 15:12:14 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: The text size of a program is irrelevant, because swap is never allocated for it. The data and BSS are only relevant when they are modified. Bzzt. BSS is relevant when accessed (at

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 15:37:26 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: When you write embedded systems like these, you do not run any general purpose binaries at all. You run fully custom binaries and you take control of the memory management yourself.

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 15:44:40 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: So far nobody has been able to justify any good reasons for adding it to the system. I'm sorry, but just throwing out worst-case theories is not a good justification, nor is throwing

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 16:16:07 -0700 Mike Smith m...@smith.net.au wrote: Matt's point, which he's not making by virtue of talking too much, is that you can't make a no overcommit system behave like an overcommit system, and most people are used to the sort of things that the latter

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 16:24:53 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: I'm sure the feeling is mutual. More to the point, I really seriously doubt that any of the core developers would consider this idea either because it's been rejected in the past and,

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 16:29:50 -0700 Mike Smith m...@smith.net.au wrote: You can make the overcommit or not overcommit option a switch, but the consumers of the system (may) need to change their behaviour as well. I never said they wouldn't have to. -- Jason R. Thorpe

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-13 Thread Jason Thorpe
On Tue, 13 Jul 1999 16:56:26 -0700 (PDT) Matthew Dillon dil...@apollo.backplane.com wrote: You have to consider the probability of an event occuring, not just the possibility that the event might occur. If the probability is one in a million years, then it is not something

Re: Replacement for grep(1) (part 2)

1999-07-07 Thread Jason Thorpe
On 07 Jul 1999 20:57:16 +0200 Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: Don't use err() indiscriminately after a malloc() failure; malloc() doesn't set errno. This is a bug in malloc(3), is it not? -- Jason R. Thorpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL

Re: Heh heh, humorous lockup

1999-07-07 Thread Jason Thorpe
On Wed, 7 Jul 1999 17:03:16 -0700 (PDT) Matthew Dillon [EMAIL PROTECTED] wrote: If this could result in a smaller overall structure, it may be worth it. To really make the combined structure smaller we would also have to pair-down the fields in both structures. For example,

Re: Replacement for grep(1) (part 2)

1999-07-07 Thread Jason Thorpe
On 07 Jul 1999 20:57:16 +0200 Dag-Erling Smorgrav d...@flood.ping.uio.no wrote: Don't use err() indiscriminately after a malloc() failure; malloc() doesn't set errno. This is a bug in malloc(3), is it not? -- Jason R. Thorpe thor...@nas.nasa.gov To Unsubscribe: send mail to

  1   2   >