From owner-freebsd-arch Wed Feb 26 23:12:55 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 929AE37B401 for ; Wed, 26 Feb 2003 23:12:53 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 500D443FBD for ; Wed, 26 Feb 2003 23:12:48 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h1R7Cc1o058035; Wed, 26 Feb 2003 23:12:38 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.7/8.12.7) with ESMTP id h1R7CcqV002675; Wed, 26 Feb 2003 23:12:38 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.7/8.12.7/Submit) id h1R7CTRU002674; Wed, 26 Feb 2003 23:12:29 -0800 (PST) Date: Wed, 26 Feb 2003 23:12:29 -0800 From: Marcel Moolenaar To: Kris Kennaway Cc: Dan Nelson , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: (almost) Ready to ditch device major numbers. Message-ID: <20030227071229.GB2442@dhcp01.pn.xcllnt.net> References: <28750.1046295228@critter.freebsd.dk> <20030227033854.GA87187@rot13.obsecurity.org> <20030227040145.GA25640@dan.emsphone.com> <20030227063039.GA88321@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030227063039.GA88321@rot13.obsecurity.org> User-Agent: Mutt/1.5.3i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Feb 26, 2003 at 10:30:40PM -0800, Kris Kennaway wrote: > On Wed, Feb 26, 2003 at 10:01:45PM -0600, Dan Nelson wrote: > > In the last episode (Feb 26), Kris Kennaway said: > > > On Wed, Feb 26, 2003 at 10:33:48PM +0100, Poul-Henning Kamp wrote: > > > > We are now (almost) ready to ditch device major numbers if we want > > > > to. > > > > > > There are a number of ports that create device nodes in the package > > > tarball (e.g. the linux_base ports which create a shadow /dev). How > > > will this be affected under your plans? > > > > linux_base-7.1_2 doesn't put anything in /compat/linx/dev, and I don't > > see anything in linux_base-6's plist that indicates it does, either. > > > > Anything that tries to generate a device node in /dev from userland > > should already fail anyway, right? devfs won't let you do anything > > except make symlinks. > > No, it definitely does. I noticed this because I recently made a > change to the bento package builds so they build packages in a jail > instead of a chroot. A number of packages (3-4) failed because they > try and mknod at install-time, which is disallowed within a jail. > > See e.g. > > http://bento.freebsd.org/errorlogs/i386-4-exp-latest/linux_base-7.1_2.log In this case it's the ports makefile that creates the device file. The reason it does that is that rpm is run with --root ${LINUXBASE} so that the RPM database is located in /compat/linux, even though the rpm binary itself is a FreeBSD native one (and thus likes to put its bits under /var). The --root command line option results in a chroot(2) and thus causes some nasty problems. One of which is the dependency on /dev/null, which has to be created under /compat/linux for that case. I think (but I'm not sure) that it should be safe to remove the major/minor numbers, because we could probably do some trickery with devfs and symbolic links. I seem to recall however that iBCS has a stronger dependency. Also, VMWare probably needs a quick audit. It might also be a good idea to look at osf1 emulation because it's needed for Linux emulation on alpha. While we're at it, we might as well look at SysV emulation too :-) Overall: I think there might be some weird cases we need to deal with. But since we don't have any major/minor number mappings in the various emulation layers, I expect that the weird cases are mostly special cases and that we don't have a fundamental problem. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message