From owner-cvs-sbin  Sat Sep 13 04:46:39 1997
Return-Path: <owner-cvs-sbin>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA00938
          for cvs-sbin-outgoing; Sat, 13 Sep 1997 04:46:39 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA00856;
          Sat, 13 Sep 1997 04:45:03 -0700 (PDT)
From: Peter Wemm <peter@FreeBSD.ORG>
Received: (from peter@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id EAA16429;
	Sat, 13 Sep 1997 04:41:51 -0700 (PDT)
Date: Sat, 13 Sep 1997 04:41:51 -0700 (PDT)
Message-Id: <199709131141.EAA16429@freefall.freebsd.org>
To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-sbin@FreeBSD.ORG
Subject: cvs commit: src/sbin/newfs mkfs.c
Sender: owner-cvs-sbin@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

peter       1997/09/13 04:41:51 PDT

  Modified files:
    sbin/newfs           mkfs.c 
  Log:
  Some tweaks to get this to cope with ELF where the address space starts
  higher up in memory (0x0800000 upwards) rather than near zero (0x1000
  for our qmagic a.out format).  The method that mount_mfs uses to allocate
  the memory within data size rlimits for the ram disk is entirely too much
  of a kludge for my liking.  I mean, if it's run as root, surely it makes
  sense to just raise the resource limits to infinity or something, and if
  it's a non-root user mount (do these work? with mfs?) it could just fail
  if it's outside limits.
  
  Revision  Changes    Path
  1.20      +18 -8     src/sbin/newfs/mkfs.c