Re: FreeBSD on S/390?

[Thomas David Rivers]

> 
> 
> Long shot, probably, but I've got a bunch of virtual machines on an IBM
> S/390 mainframe, and while we're running SuSE Linux on most of them, on a
> whim I tossed out the idea of running FreeBSD on one of them, and to my
> surprise, it was taken seriously.
> 
> So, has anyone done any work with getting FreeBSD running on a S/390?  
> What can I do to make it happen if there's interest?
> 
> Ken
> 

 I'd like to see it as well

 I beleive we'd be willing to help with it too.. as resources permit.

- Dave Rivers -

--
[EMAIL PROTECTED] Work: (919) 676-0847
Get your mainframe (370) `C' compiler at http://www.dignus.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: FreeBSD on S/390?

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, 
Ken Bolingbroke writes:
>
>Long shot, probably, but I've got a bunch of virtual machines on an IBM
>S/390 mainframe, and while we're running SuSE Linux on most of them, on a
>whim I tossed out the idea of running FreeBSD on one of them, and to my
>surprise, it was taken seriously.
>
>So, has anyone done any work with getting FreeBSD running on a S/390?  
>What can I do to make it happen if there's interest?

I certainly think it is a worthwhile task.  I have long been advocating
it publically.  I can't promise that I have much time for it but I'll
do what I can to help.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ipchains ported to FreeBSD

[Dan Nelson]

In the last episode (Mar 01), jett tayer said:
> can ipchains / iptables be ported to FreeBSD... this is a suggestion
> if u dont mind.

We've already got ipfw and ipfilter; why in the world would we need a
third packet-filtering systam? :)


-- 
Dan Nelson
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Inheriting the nodump flag

[Dima Dorfman]

> > Attached below is a port of NetBSD's patch to FreeBSD's dump(8).
> > dump's tree walker is a little weird, so the patch is a little more
> > complicated than calling fts_set with FTS_SKIP.  For the technical
> > details of what it does, see:
> > http://lists.openresources.com/NetBSD/tech-kern/msg00453.html.
> [.]
> > Comments?
> 
> Just that I noticed a typo in a comment where ``inherited'' is misspelt 
> ``herited'' going via your URL but it's fixed in the attached 
> patch :-)  It's probably worth updating the web page.

That page is the archive of the [EMAIL PROTECTED] mailing list, and
as such can't be changed (much less by me).  I provided it because it
offers a very good technical explanation of the patch, which I didn't
want to repeat.  I took the patch there almost verbatim, except for,
obviously, the exact placement of the code, and the comments; I didn't
take the latter because the person who wrote it isn't a natural
English speaker (as far as I can tell, anyway), and as such didn't
write such great comments ("such great" being a reference to the
English grammar and spelling, not their technical accuracy).

> 
> I'd certainly like to see this committed - I'm sick of backing up 
> release directories, cvs repositories and /usr/obj :-)

Yes, this was my motivation for porting this, too. :-)

Thanks

Dima Dorfman
[EMAIL PROTECTED]

P.S.  I just sent this patch to -audit per request of rwatson.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

ipchains ported to FreeBSD

[jett tayer]

hello,
 
can ipchains / iptables be ported to 
FreeBSD...
this is a suggestion if u dont 
mind.
 
jett

FreeBSD on S/390?

[Ken Bolingbroke]

Long shot, probably, but I've got a bunch of virtual machines on an IBM
S/390 mainframe, and while we're running SuSE Linux on most of them, on a
whim I tossed out the idea of running FreeBSD on one of them, and to my
surprise, it was taken seriously.

So, has anyone done any work with getting FreeBSD running on a S/390?  
What can I do to make it happen if there's interest?

Ken


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Setting memory allocators for library functions.

[Jos Backus]

For your collective amusement, here's a post that talks about how OS/2 handles
memory allocation. DosAllocMem() has a flags argument, and one of the flags
requests the OS to actually commit the memory.

http://w3.hethmon.com/os2isp/1998/Apr/Msgs/l2w96957.html

http://www.stidolph.com/os2api/Dos/DosAllocMem.html

So even IBM must have thought it not to be such a bad idea.

-- 
Jos Backus _/  _/_/_/"Modularity is not a hack."
  _/  _/   _/-- D. J. Bernstein
 _/  _/_/_/ 
_/  _/  _/_/
[EMAIL PROTECTED] _/_/   _/_/_/use Std::Disclaimer;

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Inheriting the nodump flag

[Brian Somers]

> Attached below is a port of NetBSD's patch to FreeBSD's dump(8).
> dump's tree walker is a little weird, so the patch is a little more
> complicated than calling fts_set with FTS_SKIP.  For the technical
> details of what it does, see:
> http://lists.openresources.com/NetBSD/tech-kern/msg00453.html.
[.]
> Comments?

Just that I noticed a typo in a comment where ``inherited'' is misspelt 
``herited'' going via your URL but it's fixed in the attached 
patch :-)  It's probably worth updating the web page.

I'd certainly like to see this committed - I'm sick of backing up 
release directories, cvs repositories and /usr/obj :-)

> Thanks in advance
> 
>   Dima Dorfman
>   [EMAIL PROTECTED]

Cheers.
-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: questions regarding the MGET function.

[Bosko Milekic]

Shankar Agarwal wrote:

> Hi,
> Can you please tell me when did the MGET function change it
> implementation from using MALLOC to using pool_get to allocate a
mbuf. I

Never. We don't use pool_get(). That's a NetBSD-ism. :-)

The mbuf subsystem uses its own allocator and stats are kept in
mbstat which is exported via sysctl. Things like netstat(1) can fetch
this information for you.

> am having a trouble finding out how does the memstats keep track of
the
> mbufs allocated through pool_get.
> Thanks
> Regards
> Shankar



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: memorylocked resource (was "Setting memory allocators...")

[Matt Dillon]

::Along the same lines (matt probably knows the answer) is it
::easy to force paging in and locking down of any memory associated
::with a process so that mlockall(MCL_FUTURE) together with
::an appropriate memorylocked limit gives the requested
::memory semantics?  I'd have to check through the specs to see
::how mmap() is supposed to play with mlockall().
::
::Please leave aside most resource management issues
::for now, I'm assuming the main use for this is debugged
::small closed embedded systems, only bring up kickers.
::
::Peter
::Peter Dufault ([EMAIL PROTECTED])   Realtime development, Machine control,

Heh heh.  I didn't answer that very well the first time eh?

In regards to mlockall(MCL_FUTURE).  Hmm.  Well, you could certainly
implement it inside vm_fault but there are a couple of other cases
where the system manually enters a page into the user's page table. 
I haven't researched it but I would not expect it to be difficult.

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: memorylocked resource (was "Setting memory allocators...")

[Matt Dillon]

Hmm.  Well, mlock() is one of those system calls that virtually
nobody has worked on since inception.  The most I've done with it
has been to fix bugs.  The resource issues for mlock() aren't
really good enough to prevent misuse in a general multiuser system.
The resource is per-process rather then per-user, and in fact not
even implemented.   And the locked memory is not advisory so there is
no way for the kernel to recover it under heavy load conditions until 
the process releases it or exits.

If you grep for RLIMIT_MEMLOCK you find a minimal implementation of
the resource limit in vm/vm_mmap.c.  'pmap_wired_count' is not defined,
so the implementation is to be root-only and to ignore the resource limit.
Even with pmap_wired_count implemented the implementation is per-process,
which is not sufficient protection.

-Matt

:Why is the mlock(2) call restricted to the super user instead
:of enforcing it through per-user or per-login class limits?
:I was checking to see if most of the pieces were in place for
:"mlockall(MCL_FUTURE)" and noticed the "memorylocked infinity"
:setting in limits (I didn't know about memorylocked).  Setting
:"memorylocked 0" for normal users is a flexible way to address
:this, then create a special class of programs that are permitted
:to do some locking.
:
:Along the same lines (matt probably knows the answer) is it
:easy to force paging in and locking down of any memory associated
:with a process so that mlockall(MCL_FUTURE) together with
:an appropriate memorylocked limit gives the requested
:memory semantics?  I'd have to check through the specs to see
:how mmap() is supposed to play with mlockall().
:
:Please leave aside most resource management issues
:for now, I'm assuming the main use for this is debugged
:small closed embedded systems, only bring up kickers.
:
:Peter
:
:--
:Peter Dufault ([EMAIL PROTECTED])   Realtime development, Machine control,

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

questions regarding the MGET function.

[Shankar Agarwal]

Hi,
Can you please tell me when did the MGET function change it
implementation from using MALLOC to using pool_get to allocate a mbuf. I
am having a trouble finding out how does the memstats keep track of the
mbufs allocated through pool_get.
Thanks
Regards
Shankar

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to actually find out whether data hit the disk?

[Matt Dillon]

:> is it possible to actually find out whether data hit the disk or not for
:> a particular run of 1-7?
:
:Answer to your question:
:
:Do an msync with MS_SYNC someplace.  Also, use MAP_NOSYNC in
:mmap until 4.3 when Matt Dillon plans to make that the default behavior.

I plan on making it the default behavior only for Linux emulation,
to emulate what Linux does.

For FreeBSD native you still need to specify MAP_NOSYNC.  Eventually
I hope to make it the default behavior for FreeBSD native but some
work needs to be done on the VM heuristics first (or on an incremental
system sync) to avoid collecting too many dirty pages.

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: Generating Core Dump Programmatically

[John Baldwin]

On 28-Feb-01 Marc W wrote:
> 
> 
> I'm trying to ensure robust shutdown on my machine.  Thus, I've
> installed signal handlers for a bunch of nasty looking signals.  In my
> new handler, after all critical state is saved, I then call abort(3),
> and all seems to work well.
> 
> EXCEPT -- some signals generate core files when left with the
> default behaviour.  Is there some straightforward way to do this?

Hmm, perhaps make sure you have the default SIGSEGV handler installed after
your cleanup and do:

*(int *)NULL = 1;

or some such?  Then again, the core dump you get may not be all that useful...

> thanks.
> 
> marc.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use 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

subscribe

[khb]

subscribe


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Setting memory allocators for library functions.

[Arun Sharma]

On Tue, Feb 27, 2001 at 10:39:13PM -0800, Julian Elischer wrote:
> no, something specifically designed around kernel type of actions.
> declarations of "physical pointer", "kvm pointer" "User Pointer"
> for example, and being able to declare a structure (not 'struct') 
> and say "this list is 'per process'"  and have the list head 
> automatically in the proc struct
> without haviong to add it there.. i.e backwards from today..

Rumor has it that MS has several compiler extensions, just for supporting
their kernel. Some of what you say above could be built on top of the
compiler, declaratively. Language support works well in cases where writing
the same code by hand is tedious and error prone or down right ugly - like
several hundred if (foo = null) return blah checks.

-Arun

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Converting Perforce to CVS

[Anton Berezin]

On Mon, Feb 26, 2001 at 02:31:33PM -0800, John Wilson wrote:
> On Sun, 25 Feb 2001 22:00:31 -0600, Michael C . Wu wrote:
>>  On Sun, Feb 25, 2001 at 09:17:38AM -0800, John Wilson scribbled:

>>> If you still have the Perforce->CVS conversion script, I would be
>>> very grateful if you could e-mail it to me.

>>  Such a script is available for download on www.perforce.com.

> No, there isn't.  They have a CVS to Perforce script, not Perforce to
> CVS (please don't ask who in their right mind would want to go from
> Perforce to CVS :)

> Well, if Anton doesn't respond, I guess I'll just have to write one
> myself...

Well, it took a month for you request it...  Not that I was deliberately
waiting the same period before sending it, but..   ;-)


http://www.tobez.org/download/p42cvs

Beware it is very unpolished and probably requires your inspection
before using it.  I used it once, and it worked for me.

Cheers,
+Anton.
-- 
May the tuna salad be with you.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to actually find out whether data hit the disk?

[Peter Dufault]

> > Do an msync with MS_SYNC someplace.  Also, use MAP_NOSYNC in
> > mmap until 4.3 when Matt Dillon plans to make that the default behavior.
> 
> Ahh, no.  That's the other way around - I do not *want* it to hit the
> disk, but would like to *know* when it nevertheless does.

OK, doing a stat and checking the mtime should give you
the info at the expense of polling, I can't think of another way.

Peter

--
Peter Dufault ([EMAIL PROTECTED])   Realtime development, Machine control,
HD Associates, Inc.   Fail-Safe systems, Agency approval

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to actually find out whether data hit the disk?

[Anton Berezin]

[ putting hackers- back here]

On Wed, Feb 28, 2001 at 06:07:50AM -0800, Mike Smith wrote:
> > > I am doing the following, on the partition with softupdates turned on:
> > > 
> > > 1. fd = open("a file", O_CREAT)
> > > 2. mmap(fd)
> > > 3. sequencial write to mmapped region
> > > 4. some other processing
> > > 5. munmap
> > > 6. unlink
> > > 7. close
> > > 
> > > Since this is a supposedly high-perfomance application, I am interested
> > > that data do NOT hit the disk.  I understand that softupdates do a good
> > > job at that.  The time taken by step 4 is usually sub-second, but
> > > sometimes it can take longer (network delays etc.).  The question is -
> > > is it possible to actually find out whether data hit the disk or not for
> > > a particular run of 1-7?
> 
> The *real* question here is - why are you using a file at all?
> 
> You could trivially replace open/mmap with malloc, and munmap/unlink/
> close with free.  If you don't want the operation to go to disk, don't 
> apply disk-file semantics to it at all.

That's a sort of memory overcommit protection.  The files/buffers are
potentially large (say, ~20MB-100MB), there can be several of those in a
process, and there are going to be several copies of a process.  So
neither malloc() nor anonymous mmap() do the job.  In most cases they
would work just fine (i.e, the typical buffer size is 2K-500K), but so
will do the file-backed mmap().  In the bad case, however, the
file-backed mmap() will have an advantage of not coredumping.  ;-)

%Anton.
-- 
May the tuna salad be with you.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to actually find out whether data hit the disk?

[Anton Berezin]

On Wed, Feb 28, 2001 at 08:57:31AM -0500, Peter Dufault wrote:
> > I am doing the following, on the partition with softupdates turned on:
> > 
> > 1. fd = open("a file", O_CREAT)
> > 2. mmap(fd)
> > 3. sequencial write to mmapped region
> > 4. some other processing
> > 5. munmap
> > 6. unlink
> > 7. close
> > 
> > Since this is a supposedly high-perfomance application, I am interested
> > that data do NOT hit the disk.  I understand that softupdates do a good
> > job at that.  The time taken by step 4 is usually sub-second, but
> > sometimes it can take longer (network delays etc.).  The question is -
> > is it possible to actually find out whether data hit the disk or not for
> > a particular run of 1-7?
> 
> Answer to your question:
> 
> Do an msync with MS_SYNC someplace.  Also, use MAP_NOSYNC in
> mmap until 4.3 when Matt Dillon plans to make that the default behavior.

Ahh, no.  That's the other way around - I do not *want* it to hit the
disk, but would like to *know* when it nevertheless does.

=Anton.
-- 
May the tuna salad be with you.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: how to actually find out whether data hit the disk?

[Peter Dufault]

> I am doing the following, on the partition with softupdates turned on:
> 
> 1. fd = open("a file", O_CREAT)
> 2. mmap(fd)
> 3. sequencial write to mmapped region
> 4. some other processing
> 5. munmap
> 6. unlink
> 7. close
> 
> Since this is a supposedly high-perfomance application, I am interested
> that data do NOT hit the disk.  I understand that softupdates do a good
> job at that.  The time taken by step 4 is usually sub-second, but
> sometimes it can take longer (network delays etc.).  The question is -
> is it possible to actually find out whether data hit the disk or not for
> a particular run of 1-7?

Answer to your question:

Do an msync with MS_SYNC someplace.  Also, use MAP_NOSYNC in
mmap until 4.3 when Matt Dillon plans to make that the default behavior.

But: When does the data need to "hit the disk", given that
you're unlinking the file in step 6?  If I read the posix spec
correctly it may never need to hit the disk.  Consider a set
of unrelated processes whacking a shared memory file.  Set it
up so the first one creates it, a bunch attach, and a final
one attaches and unlinks it:

process 1: fd = open("foo", O_CREAT|O_RDWR);
   mmap(fd, MAP_NOSYNC|MAP_SHARED);
   Write to mapped region

process 2: fd = open("foo", O_RDWR);
   mmap(fd, MAP_NOSYNC|MAP_SHARED);

process 3: fd = open("foo", O_RDWR);
   mmap(fd, MAP_NOSYNC|MAP_SHARED);

...

process N: fd = open("foo", O_RDWR)
   mmap(fd, MAP_NOSYNC|MAP_SHARED);
   unlink("foo");

Everyone now happily does what they want and then all exit and no one
ever does an msync().

Then you never need to actually transfer any data to disk.  I'm
not sure what actually happens now.

Peter

--
Peter Dufault ([EMAIL PROTECTED])   Realtime development, Machine control,
HD Associates, Inc.   Fail-Safe systems, Agency approval

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

memorylocked resource (was "Setting memory allocators...")

[Peter Dufault]

Why is the mlock(2) call restricted to the super user instead
of enforcing it through per-user or per-login class limits?
I was checking to see if most of the pieces were in place for
"mlockall(MCL_FUTURE)" and noticed the "memorylocked infinity"
setting in limits (I didn't know about memorylocked).  Setting
"memorylocked 0" for normal users is a flexible way to address
this, then create a special class of programs that are permitted
to do some locking.

Along the same lines (matt probably knows the answer) is it
easy to force paging in and locking down of any memory associated
with a process so that mlockall(MCL_FUTURE) together with
an appropriate memorylocked limit gives the requested
memory semantics?  I'd have to check through the specs to see
how mmap() is supposed to play with mlockall().

Please leave aside most resource management issues
for now, I'm assuming the main use for this is debugged
small closed embedded systems, only bring up kickers.

Peter

--
Peter Dufault ([EMAIL PROTECTED])   Realtime development, Machine control,
HD Associates, Inc.   Fail-Safe systems, Agency approval

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

how to actually find out whether data hit the disk?

[Anton Berezin]

Hi,

I am doing the following, on the partition with softupdates turned on:

1. fd = open("a file", O_CREAT)
2. mmap(fd)
3. sequencial write to mmapped region
4. some other processing
5. munmap
6. unlink
7. close

Since this is a supposedly high-perfomance application, I am interested
that data do NOT hit the disk.  I understand that softupdates do a good
job at that.  The time taken by step 4 is usually sub-second, but
sometimes it can take longer (network delays etc.).  The question is -
is it possible to actually find out whether data hit the disk or not for
a particular run of 1-7?

&Anton.
-- 
May the tuna salad be with you.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Setting memory allocators for library functions.

[Dag-Erling Smorgrav]

Tony Finch <[EMAIL PROTECTED]> writes:
> What about setrlimit(RLIMIMT_DATA)?

Yep, I'd forgotten about that. Malloc() will return NULL if you hit
your data size limit.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: rootdev problems with /boot/loader.

[Josef Karthauser]

On Wed, Feb 28, 2001 at 11:32:02AM +, Josef Karthauser wrote:
> > What does 'lsdev' show.
> 
> Here's what lsdev shows:
> 
> disk @ 0xf3e4
> disk0:   BIOS drive A:
> disk1:   BIOS drive C:
> disk1s1a: FFS
> 
> So why is it trying to book disk1s2a at mount time.  /me's confused.

Ahha!  It looks like /boot/loader or the kernel sneaks a look at
/etc/fstab to try and work out what to mount. :)  I had /dev/ad0s2a
in there for /.  Changing it to /dev/ad0s1a fixed the boot.

Joe

 PGP signature

Re: rootdev problems with /boot/loader.

[Josef Karthauser]

On Tue, Feb 27, 2001 at 02:44:04PM -0800, John Baldwin wrote:
> 
> On 27-Feb-01 Josef Karthauser wrote:
> > I've got a bootable filesystem that although it's installed in the first
> > slice on a disk the kernel/bootloader tries to mount /dev/ad0s2a as the
> > root filesystem.  I'm scratching my head as to why.  Any ideas?
> > It should be mounting /dev/ad0s1a automatically.
> > 
> > The following are set by /boot/loader:
> >   rootdev=disk1s1a
> >   currdev=disk1s1a:
> > 
> > Joe.
> > 
> > p.s.  This image is being booted via /dev/md0 in vmware.  What I'm
> > trying to work out is whether it's a bug in either of these parts.
> 
> What does 'lsdev' show.

Here's what lsdev shows:

disk @ 0xf3e4
disk0:   BIOS drive A:
disk1:   BIOS drive C:
disk1s1a: FFS

So why is it trying to book disk1s2a at mount time.  /me's confused.

Joe

p.s. It's not devfs.  It does the same thing with static dev nodes in
/dev.

 PGP signature

Re: Setting memory allocators for library functions.

[michael schuster]

Matt Dillon wrote:

> Allowing a program to run the OS itself out of VM, with or without
> overcommit, is (being generous) just plain dumb.

I'm not a fan of either (overcommit or non-), I can see advantages with both
(seeing that Solaris, which I happen to work with, has one and FreeBSD the
other), but your last remark does beg an answer:

In a non-dedicated environment (ie a general-purpose Unix machine), it's the
mix of applications that brings down your memory, not a single one. In such a
situation I can imagine synchronous information to the effect "you're out of
swapable memory" to be practical (that's the way Solaris implements it).

I haven't thought this out in detail, but I also imagine it easier to handle
ENOMEM than SIGDANGER, because of the synchronous nature of the first versus
the asynchronous nature of the second.

just my 2 euro cents
Michael
-- 
Michael Schuster  / [EMAIL PROTECTED]
Sun Microsystems GmbH / (+49 89) 46008-2974 | x62974
Sonnenallee 1, D-85551 Kirchheim-Heimstetten

Recursion, n.: see 'Recursion'

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: rootdev problems with /boot/loader.

[Josef Karthauser]

On Tue, Feb 27, 2001 at 03:51:03PM -0800, Paul Saab wrote:
> Oops.
> make that
> vfs.root.mountrootfrom="ufs:/dev/ad0s1a"

Thanks Paul
Joe

 PGP signature