Date: Fri, 01 Jan 1999 21:18:08 -0800 From: Mike Smith <mike@smith.net.au> To: undisclosed-recipients:; Subject: Re: DEVFS, the time has come... Message-ID: <199901020518.VAA00463@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 01 Jan 1999 22:11:36 MST." <199901020511.WAA15502@mt.sri.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'. :( You were specifically complaining about not being able to fix something that a boot-time script would have been more than adequate for. > We've got boot rc.* scripts (which I hope Warner has pointed out is > insufficient), Actually, in most cases they'd be fine, if decidedly inelegant. > and the infamous 'daemon', which IMO would be difficult > to customize easily, A non-comment on a non-design. > I'd like to see something of substance *implemented* before we agree to > go with DEVFS. How can you implement something for something else that doesn't exist? > 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. Lack of SLICE-equivalent functionality would instantly disqualify any DEVFS candidate; I think that much has to be obvious. -- \\ 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-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901020518.VAA00463>