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 a
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 tha
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]>
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
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
> bus_space_read_X(
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 wi
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 sche
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 i
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,
ge
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, Ro
On Thu, 16 Sep 1999 23:10:21 -0500 (CDT)
Mohit Aron 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 x86 where they ar
On Thu, 16 Sep 1999 23:10:21 -0500 (CDT)
Mohit Aron <[EMAIL PROTECTED]> 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
On Wed, 8 Sep 1999 00:17:52 +0200 (CEST)
Wilko Bulte 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 to have EISA s
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
On Wed, 8 Sep 1999 10:12:51 -0400 (EDT)
Bill Paul 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 first
> toggle the
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
On Tue, 7 Sep 1999 21:13:22 -0400 (EDT)
Bill Paul 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
> read the media
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
On Tue, 7 Sep 1999 03:11:24 -0400 (EDT)
Bill Paul 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
> separate status and
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
>
On Fri, 03 Sep 1999 16:23:00 -0600
Wes Peters <[EMAIL PROTECTED]> 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:
On Fri, 03 Sep 1999 16:23:00 -0600
Wes Peters 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:
>
> The VIA
On Wed, 01 Sep 1999 15:46:40 -0600
Wes Peters 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, ax, mx, pn, vr
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, th
On Fri, 27 Aug 1999 02:20:52 + (GMT)
Terry Lambert 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 vacation(1) bug an
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 th
On Mon, 23 Aug 1999 17:44:47 -0700
"Dave Walton" 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 NT5, Microsof
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 sta
On Mon, 23 Aug 1999 11:28:20 -0400
Dennis 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 materialized.
NetBS
On Mon, 23 Aug 1999 11:28:20 -0400
Dennis <[EMAIL PROTECTED]> 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
On Sat, 21 Aug 1999 02:10:47 -0600
Wes Peters 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.
...first of all, I ass
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.
..
On Sat, 14 Aug 1999 10:38:17 -0700
Mike Smith 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 attached to that
On Fri, 13 Aug 1999 21:46:27 -0700
Mike Smith 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 it's
> no lon
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
On Fri, 13 Aug 1999 21:46:27 -0700
Mike Smith <[EMAIL PROTECTED]> 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 L
On Fri, 13 Aug 1999 19:37:42 -0700 (PDT)
Kris Kennaway 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 be allowing the
On Fri, 13 Aug 1999 19:49:10 -0400 (EDT)
James Howard 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 mentioned
> th
On Fri, 13 Aug 1999 19:37:42 -0700 (PDT)
Kris Kennaway <[EMAIL PROTECTED]> 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 w
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
On Fri, 13 Aug 1999 22:49:14 + (GMT)
Terry Lambert 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 death; it's not cle
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
On 12 Aug 1999 11:01:06 +0200
Dag-Erling Smorgrav 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 object which incl
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 executab
On Wed, 11 Aug 1999 16:46:46 -0500
"Alton, Matthew" 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 course, is completely unnecessa
On Wed, 11 Aug 1999 16:46:46 -0500
"Alton, Matthew" <[EMAIL PROTECTED]> 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 course, is
On Wed, 11 Aug 1999 20:48:08 +0400 (MSD)
Oleg Derevenetz 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 FreeBSD. Here is
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
On Tue, 3 Aug 1999 11:28:29 -0600
Oscar Bonilla 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 specifically didn't
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
On Thu, 29 Jul 1999 10:52:02 -0700 (PDT)
Matthew Dillon 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 least one instance where thi
On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
Matthew Dillon 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 common test case of advisi
On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
Matthew Dillon 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):
DONTNEED: deactivate page
On Fri, 30 Jul 1999 01:50:28 +0900
"Daniel C. Sobral" 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 long as
On Thu, 29 Jul 1999 09:26:12 -0700 (PDT)
Matthew Dillon 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 madvise() of
>
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,
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
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):
DONTN
On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> 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 common
On Thu, 29 Jul 1999 10:52:02 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> 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 least on
On Wed, 28 Jul 1999 09:44:03 +0800
Peter Wemm 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). I've had quite a l
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).
On Tue, 27 Jul 1999 14:14:33 -0700
"Kelly D. Lucas" 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
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-h
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 PRO
On Tue, 20 Jul 1999 10:02:43 +0100
Dominic Mitchell 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
> quickly, but on a bus
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
> q
On Mon, 19 Jul 1999 15:47:33 -0400
"David E. Cross" 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 PAM all of tho
On Mon, 19 Jul 1999 20:44:18 +0100
Dominic Mitchell 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 that things will a
On Mon, 19 Jul 1999 15:47:33 -0400
"David E. Cross" <[EMAIL PROTECTED]> 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 unle
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 i
On Thu, 15 Jul 1999 01:59:12 +0900
"Daniel C. Sobral" 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 is
in th
On Thu, 15 Jul 1999 01:52:11 +0900
"Daniel C. Sobral" 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 option i
On Wed, 14 Jul 1999 12:43:07 +
Niall Smart 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 they did not do
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, rea
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. :-)
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 en
On Tue, 13 Jul 1999 23:18:58 -0400 (EDT)
John Baldwin 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 reboot on us
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
On Tue, 13 Jul 1999 16:56:26 -0700 (PDT)
Matthew Dillon 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 to worry
> a
On Tue, 13 Jul 1999 16:29:50 -0700
Mike Smith 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
To Unsubscribe: sen
On Tue, 13 Jul 1999 16:24:53 -0700 (PDT)
Matthew Dillon 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, nobody has offere
On Tue, 13 Jul 1999 16:16:07 -0700
Mike Smith 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
> makes practica
On Tue, 13 Jul 1999 15:44:40 -0700 (PDT)
Matthew Dillon 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 embedded systems into the
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 ne
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 <[E
On Tue, 13 Jul 1999 15:37:26 -0700 (PDT)
Matthew Dillon 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, really? The camera s
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 fa
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 latte
On Tue, 13 Jul 1999 15:12:14 -0700 (PDT)
Matthew Dillon 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 least in NetBSD).
> T
On Tue, 13 Jul 1999 14:56:52 -0700 (PDT)
Matthew Dillon 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 matters, not a worst-c
On Tue, 13 Jul 1999 15:44:40 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> 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 embedde
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, r
On Tue, 13 Jul 1999 14:31:38 -0700 (PDT)
Matthew Dillon 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 each program is n
On Tue, 13 Jul 1999 14:27:54 -0700 (PDT)
Matthew Dillon 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 out of swap.
On Tue, 13 Jul 1999 15:12:14 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> 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 least i
On Tue, 13 Jul 1999 14:16:54 -0700 (PDT)
Matthew Dillon 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 simply does
>
On Tue, 13 Jul 1999 14:14:52 -0700 (PDT)
Matthew Dillon 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 attention to Chris's pos
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 ma
On Tue, 13 Jul 1999 11:59:25 -0700 (PDT)
Matthew Dillon 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 is fairly
>
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 with
1 - 100 of 134 matches
Mail list logo
