Date: Fri, 1 Jan 1999 22:11:36 -0700 From: Nate Williams <nate@mt.sri.com> To: undisclosed-recipients:; Subject: Re: DEVFS, the time has come... Message-ID: <199901020511.WAA15502@mt.sri.com> In-Reply-To: <199901020455.UAA01211@dingo.cdrom.com> References: <199901020438.VAA15410@mt.sri.com> <199901020455.UAA01211@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > To counter Joerg's 'not bothered by non-persistent DEVFS', I'd have to > > say that my experience with Solaris has been less than enthusiastic. > > Note, it only dealt with one device (the tape drive), but it was a pain > > in the butt. > > > > I setup the machine so that 'normal users' could do their own backups to > > the tape drive, but the default permissions would not allow this to > > work, so I had to 'chmod' the device special node. The combination of > > the Solaris init implementation (where do I stick the chmod call in the > > mess of init files?), the fact that the tape drive was 'mobile' (it > > moved to a PC for backups on occasion), and the fact that I couldn't > > make the mods persistent w/out a lot of work. > > > > Yes, it could be done, but it was a huge pain in the backside to get it > > to work 100%, and it shouldn't be that much work IMO. > > This sounds more like you were bitten by the lack of easily-adapted > support infrastructure than that the basic concept is flawed, > especially as the case you offer as support is one that would be a > non-issue with our infrastructure. What infrastructure? Nothing exists at this point in FreeBSD to do this 'easily'. There is lots of hand-waving, but nobody has even agreed on *what* form a persistence mechanism would take, other than those who argue 'we really don't need it'. :( We've got boot rc.* scripts (which I hope Warner has pointed out is insufficient), and the infamous 'daemon', which IMO would be difficult to customize easily, and then Mike's 'white-out FS' design, which sounds good on paper and is similiar in scope to what was dicussed a long time ago with some sort of 'union mount' over top of DEVFS. I'd like to see something of substance *implemented* before we agree to go with DEVFS. There are still also outstanding issues of *how* a device node shows up in the first place. We still have the chicken/egg problems of whether or not to create device nodes for *every* conceivable disk device for a particular disk (wd0, wd0a, wd0s1a, wd0s2a, etc...), which SLICE was supposed to help with. This issue is somewhat orthogonal to persistence, but in some ways could make things easier, in that once it was determined *which* devices were needed the rest could be 'cleaned' out of the /dev directory. Of course, we'd still need a way to 're-surrect' some of the nodes if the configuration changed. Nate 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?199901020511.WAA15502>