Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Feb 2003 23:12:29 -0800
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Kris Kennaway <kris@obsecurity.org>
Cc:        Dan Nelson <dnelson@allantgroup.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, arch@FreeBSD.ORG
Subject:   Re: (almost) Ready to ditch device major numbers.
Message-ID:  <20030227071229.GB2442@dhcp01.pn.xcllnt.net>
In-Reply-To: <20030227063039.GA88321@rot13.obsecurity.org>
References:  <28750.1046295228@critter.freebsd.dk> <20030227033854.GA87187@rot13.obsecurity.org> <20030227040145.GA25640@dan.emsphone.com> <20030227063039.GA88321@rot13.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030227071229.GB2442>