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" 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 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, 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Mon, 17 May 1999 01:11:40 -0500
Jacques Vidrine wrote:
> It doesn't run on FreeBSD, only on Linux and Windows NT. Pity, because
> it is very neat.
I think the Connectix Virtual PC is cooler; VMware only runs on Linux
and NT because it requires gross hacks to redirect e.g. I/O space acce
On Mon, 17 May 1999 23:40:03 +0200
Andreas Braukmann wrote:
> ... and the Connectix Virtual PC is available for FreeBSD?
No, it's a MacOS program.
> that's for sure, ... from a theoretically point of view at least.
> But I suppose, that the virtual machine approach would lead to more
> pe
On Sun, 30 May 1999 21:28:31 -0700 (PDT)
Bill Huey wrote:
> Possibly, but the thing that bothers me is that I've heard more
> derogatory comments directed against Linux user on this list
> than I have seen come from Microsoft.
...because Microsoft isn't Unix, so being displeased with its ap
On Tue, 1 Jun 1999 10:09:59 +0200
Alexander Maret wrote:
> At first I tried my FreeBSD machine and I got about 800-900 collisions.
> Second I booted on the same machine linux and I only got 4 (!) collisions.
It's also possible that Linux isn't counting the collisions properly.
> I have no
On Tue, 1 Jun 1999 18:08:35 -0700
Arun Sharma wrote:
> Going through the 4.4 BSD book, I learnt that the purpose of the pv_table
> is to be able to locate all the mappings to a given physical page.
>
> However, comparing this to the Linux approach, which chains vm_area_struct
> (analogous
On Sat, 5 Jun 1999 03:24:07 -0500 (EST)
"John S. Dyson" wrote:
> > I don't want to be a pest, because this really shouldn't be on an
> > open forum. But John: I would ask you questions and the answers I
> > would get would be in the form: "Nobody understands that
> > cod
On 19 Jun 1999 17:30:13 +0200
Dag-Erling Smorgrav wrote:
> Divert sockets, dummynet and credential-based filtering would be
> sorely missed if they weren't ported to ipfilter.
...but if they were ported to IP Filter, then lots of other systems could
use them, too.
-- Jason R. Thorpe
On Thu, 24 Jun 1999 15:02:25 -0700 (PDT)
Matthew Jacob wrote:
> I was talking about this on linux-kernel, but it also applies to *BSD...
>
> What're folks' motions of a settable system unique identifier, available
> prior to mountroot? This identifier has to be 64 bits or better and must
On Thu, 24 Jun 1999 23:41:34 -0700 (PDT)
Matthew Jacob wrote:
> More generally a system unique identifier available early (pre mountroot)
> could be useful for a number of things. Why're you asking?
The intended usage:
(1) Could influence where it is stored.
(2) Might be ut
On Fri, 25 Jun 1999 15:55:03 -0600
Wes Peters wrote:
> Are there enough bytes available in the BIOS NVRAM? That would do
> nicely as a place to store it.
If you want this to be widely adoped across the free OS community
(hell, even if you want both of FreeBSD's platforms to support it),
yo
On Fri, 25 Jun 1999 16:18:04 -0600
Wes Peters wrote:
> > Whose BIOS NVRAM?
>
> The host system BIOS NVRAM. I thought we were looking for a per-host
> ID here, right?
I think Matt meant "which vendor's BIOS?"
-- Jason R. Thorpe
To Unsubscribe: send mail to majord...@freebsd.o
On Sun, 27 Jun 1999 20:43:28 -0400 (EDT)
Alexander Viro wrote:
> Forced revoke()? But then there is mmap() and IIRC revoke() on *BSD
> doesn't unmap the stuff. Oh, shit, there is such thing as pending
> unlink... Does vgone() force it?
It doesn't unmap the region, but it doesn't allow any m
On Mon, 28 Jun 1999 12:54:12 -0700 (PDT)
Matthew Dillon wrote:
> mmap bypasses the vnode. What you propose will not work because even if
> the VM object is process-specific, the pages underlying the VM object are
> not. If several processes are mmap()ing overlapping portions of
On 07 Jul 1999 20:57:16 +0200
Dag-Erling Smorgrav 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
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe free
On Wed, 7 Jul 1999 16:55:28 -0700 (PDT)
Julian Elischer wrote:
> or do what Kirk wants to do and merge the VM and Vnode structures
> I belive the UVM does a bit in this direction due to kirk's influence.
A uvm_object is not a standalone thing in UVM. Every thing that's
mappable in UVM has a
On Wed, 7 Jul 1999 17:03:16 -0700 (PDT)
Matthew Dillon 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, the vnode
> s
On Thu, 08 Jul 1999 08:36:19 +0800
Peter Wemm wrote:
> Out of curiosity, how does it handle the problem of small 512 byte
> directories? Does it consume a whole page or does it do something smarter?
> Or does the ubc work apply to read/write only and the filesystem itself
> continues to us
On Wed, 7 Jul 1999 18:21:03 -0700 (PDT)
Matthew Dillon wrote:
> Now, I also believe that when UVM maps those pages, it makes them
> copy-on-write so I/O can be initiated on the data without having to
> stall anyone attempting to make further modifications to the VM object.
>
On Tue, 13 Jul 1999 10:11:14 -0400 (EDT)
"Brian F. Feldman" 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, it's not t
On Tue, 13 Jul 1999 11:13:49 -0700 (PDT)
Matthew Dillon 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 stupid idea - and
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: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: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: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 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: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: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 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 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: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 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: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: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 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 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: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 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 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 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 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 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 Fri, 25 Jun 1999 16:18:04 -0600
Wes Peters <[EMAIL PROTECTED]> wrote:
> > Whose BIOS NVRAM?
>
> The host system BIOS NVRAM. I thought we were looking for a per-host
> ID here, right?
I think Matt meant "which vendor's BIOS?"
-- Jason R. Thorpe <[EMAIL PROTECTED]>
To Unsubs
On Sun, 27 Jun 1999 20:43:28 -0400 (EDT)
Alexander Viro <[EMAIL PROTECTED]> wrote:
> Forced revoke()? But then there is mmap() and IIRC revoke() on *BSD
> doesn't unmap the stuff. Oh, shit, there is such thing as pending
> unlink... Does vgone() force it?
It doesn't unmap the region, but it
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 [EMAI
On Wed, 7 Jul 1999 16:55:28 -0700 (PDT)
Julian Elischer <[EMAIL PROTECTED]> wrote:
> or do what Kirk wants to do and merge the VM and Vnode structures
> I belive the UVM does a bit in this direction due to kirk's influence.
A uvm_object is not a standalone thing in UVM. Every thing that's
m
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 exam
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 c
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
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
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 atte
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 situat
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 s
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
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 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 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 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 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 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: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 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 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 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 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 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 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 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 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 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 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).
1 - 100 of 134 matches
Mail list logo
