Date: Sat, 10 Feb 1996 12:42:55 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: KentH@HNS.St-Louis.Mo.US Cc: julian@ref.tfs.com, jkh@time.cdrom.com, terry@lambert.org, current@FreeBSD.org Subject: Re: FS PATCHES: THE NEXT GENERATION Message-ID: <199602101942.MAA16319@phaeton.artisoft.com> In-Reply-To: <199602100633.AAA00595@gwydion.hns.st-louis.mo.us> from "Kent Hamilton" at Feb 10, 96 00:33:54 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > hmm but devfs might be compulsory :) > > > > > I'm joking until I figure a way around the persistance problem > > personally I'll be using a kernel that will disable the use of devices > > on all kinds of filesystems other than devfs. > > > > Actually I think persistance is not a real problem, it's a PR excersize > > We're getting creamed by NT which doesn't have permissions persistance. > > I think a utility that allows the admin to tune the permissions of devices > > will make the screams go away. > > > > basically a little menu system similar to what you use in the > > install system. > > as output it produces a littel file called devs.rc that is run at boot. > > I've never seen the proposal for this stuff (I only subscribe > to -current)... so I may be way off on my understanding of what > we are talking about, but... I'll still toss in my two sense :-) > Where can I find a copy of the proposal for this anyway? The rationale for a devfs can be seen in the rationale documents for AIX and Solaris. It can also be seen in the historical discussion of the devfs for nearly two years now on the -hackers, and later on the -current list. There are a number of Usenix papers also dealing with devfs concepts, each with a rationale. Finally, there is rationale in the argument against my original patchkit and the centralization of semaphore control for the code repository (the primary reason for the existance of a core team). Details: A devfs decentralizes one of the annoying controls: the same one I had with the assignment of patch numbers in the patchkit code, the need for a number. For devices, specifically the need for a major number assignment. Using a MAKEDEV mechanism to create /dev entries requires that the MAKEDEV major number assignment match the kernel major number assignment. This requires a central registry and control of the central registry to synchronize requests as single-threaded transactions to avoid collisions. A devfs dynamically assigns the numbers -- replacing them with a symbolic reference that is potentially different from boot-to-boot. And it gets rid of the administrative headache of assignment and opens up driver develeopment. A devfs helps LKM-based devices. It allows registration of more than one device interface per driver (a problem with a traditonal LKM device table substitution). It also, by virtue of name space export rather than node creation, eliminates the need to know the assigned major number for a loaded device in order to create /dev device node entries for it. A devfs provides a framework in which it is easy to produce cloning devices. This allows dynamic allocation of things like pty's, which have historically be statically preallocated as an administrative trade-off based on expected utilization. These are cloning devices. With a clone device (for rationale, see Usenix papers on cloning devices), you don't have to precalculate the trade-off for each system you install (or provide complex administrative guidelines with guesses for expected "typical configurations" that a site administrator has to rebuild a kernel to implement). A devfs provides a framework that is not limited by zone assignment of typical minor numbers. For instance, a major number for a SCSI driver, and then bit-division of minor numbers for target (3 bits), Lun (6 bits), leaving 7 bits to divide among other controllers, per disk partitions, per partition slices, etc.. You quickly use up the 16 bits available via NFS from some systems -- what do you do: artificially limit some ranges and screw some users? Use more than 16 bits, and screw some some users doing diskless/dataless/etc. configurations? Because you effectively carry the /dev directory around with the kernel, there is no need to "go remote" to get your device nodes. Devices are local to a kernel instance, /dev entries should be too. And this only scratches the surface; the opportunities for device and logical device interaction for file system support (volume spanning, RAID, media perfection, alternate disk partitioning mechanisms, cross mounting of "foreign" file systems) is absolutely huge. As is the potential for positive impact on nomadic computing and/or removable media on fixed location systems. > I am a sysadmin for a company and we use a couple of FreeBSD systems > currently. If I change a device file then there was a damn good > reason for it and I want it to still be that way when the system > re-boots. I *don't* want to have to wade through YACMS (Yet Another > Cute Menu System) to have to make those changes stick either. > > I *do* really like the entire idea behind devfs and if there is a > way to make it stick across boots, etc. that doesn't require my having > to take extra steps to do it then I'd be happy to see it. There are multiple ways to do this. They just haven't been implemented in the current devfs code, other than as source file changes. > I *strongly* disagree with you. If I change the dev's on my firewall > I expect 'em to damn well stay changed and the first time they don't > I first go searching for the person that hacked the firewall, then > finding nothing, I dump it and rebuild it from scratch assuming that > I've just been badly beaten at my game. Now you tell me that they won't > stay that way? I dump it and get a new o/s. A devfs implementation would allow you to lock them against change based on security level. Just like immutable files via chflags. This is an administrative win beyond what is available to you now. > Also, just curious, how do you plan to handle any applications like, > as an example, Informix OnLine which expect to be handed a raw partition > (slice) owned by informix.informix mode 660 and won't work unless it > get's it. Call it a "legacy app" and forget it? (And yes I know it > doesn't apply to FreeBSD, but who knows.... I've run the "Standard > Engine" version on FreeBSD under the IBCS emulator and it worked for > my *really* limited testing, had to swipe a couple libraries from a > SCO box as I recall though.) Chmod the device in the rc script, if necessary. The Informix engine should probably be started there anyway. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602101942.MAA16319>