Date: Fri, 29 May 1998 22:53:02 -0700 From: Mike Smith <mike@smith.net.au> To: Greg Lehey <grog@lemis.com> Cc: Mike Smith <mike@smith.net.au>, Peter Wemm <peter@netplex.com.au>, "Jordan K. Hubbard" <jkh@time.cdrom.com>, Eivind Eklund <eivind@yes.no>, current@FreeBSD.ORG Subject: Re: Creating/deleting devfs nodes (was: I see one major problem with DEVFS...) Message-ID: <199805300553.WAA01042@antipodes.cdrom.com> In-Reply-To: Your message of "Sat, 30 May 1998 16:13:49 %2B0930." <19980530161349.F20360@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 1. Why should it be possible to delete a device node from devfs? It > >> shouldn't be possible to remove individual nodes without removing > >> their functionality. rm isn't the right tool to do that, and I'd > >> consider it a bug to allow it. > > > > There is an argument that suggests that this can be used to enhance > > security, eg. in chroot-jail duplicate devfs mounts. > > I think you need to be more specific. I can see a number of things > that you might mean here. What's wrong with setting the permissions > of the nodes? That shouldn't be impacted by devfs. It's impacted by devfs insofar as it's devfs that retains the nodes. As for why changing permissions isn't enough, you'll have to talk to someone else about that. I don't feel adequately passionate about how closely devfs has to cleave to "normal" file semantics. > >> 2. If for some reason (including explicit disabling, or unloading of > >> an LKM), a device node *does* disappear, the obvious tool for > >> reconstruct it is the device driver. If you need to do this, > >> something akin to camcontrol's rescan function is what you need. > >> In the case of an LKM device driver, the driver should always > >> create its nodes when it starts. > > > > If a node is removed from a mounted devfs, the driver is not impacted - > > it will have copies of this node in other devfs instances including > > the invisible "master" instance inside the kernel. > > That's an assumption. The way I stated it, it would be incorrect. It's a statement of fact based on the model to which DEVFS adheres and its implementation. There is no facility for reflexiveness in the node instantiation, and MHO is that it would be an extremely difficult path to follow. > > The easiest way to "resurrect" a node is to simply duplicate the > > original from the "master". > > The real question is what the device nodes are for. If they're > supposed to be an accurate reflection of the device driver's > capabilities (my premise), this wouldn't make sense. If they're > supposed to provide access to the device driver (your apparent > premise), that's fine. But then we don't really need devfs, we can > use the current method. I fear I have no idea what you mean by the device node "being an accurate reflection of the device driver's capabilities". A device node is an access method. The current (static) device node population process is less than adequate for this. > BTW, vinum creates its own device nodes when it's started. Does > anybody have any comments on this? Is this the driver doing the work, or an administrative program? How can you presume that / is read/write when vinum starts? How can you presume that the device nodes should be in /dev? What if someone wants the device nodes in a chrooted tree? What if someone doesn't want all the device nodes present? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805300553.WAA01042>