Date: Thu, 04 Jul 2002 19:39:53 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Daniel O'Connor <doconnor@gsoft.com.au> Cc: Bruce Evans <bde@zeta.org.au>, Greg 'groggy' Lehey <grog@FreeBSD.ORG>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Mario Goebbels <mariog@tomservo.cc>, current@FreeBSD.ORG Subject: Re: About DEVFS (was: Re: About GEOM...) Message-ID: <3D2506F9.8B34FD80@mindspring.com> References: <20020704210304.Y21619-100000@gamplex.bde.org> <3D24BB6E.3829314A@mindspring.com> <1025835014.4223.5.camel@chowder.gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel O'Connor wrote: > I am pretty sure you can put chmod/ln -s commands in /etc/rc.local (I > rc.devfs? My -current box is asleep ATM) which largely solves this > problem. If you have PCMCIA, PCCARD, USB, IEEE 1394, or a docking station, the devices that you are interested in do not necessarily exist at the time that your rc.local is run. If that's the case, this doesn't work. The obvious solution to this is the "devd" that Bruce mentioned; but if you take the obvious solution, you might as well be creating and deleting devices from the devd, rather than in the kernel in a devfs (this is what Bruce meant when he mentioned his "might as well"). The failure with this model is that there is a race on device deletion, which would leave a device present in /dev, when the hardware was no longer available. A devfs (if written correctly) will not have this problem. Note that the PCMCIA code was argues on the point of the two shorter pins, on card eject, about two years ago -- the consensus was that it was possible, but it would take a lot of work, to get to where Windows is, in terms of capability of handling ejected devices. > It isn't perfect but the current DEVFS has good advantages - especially > the hardware/node synchronisation which is very useful when you have to > shuffle hard drives and have neglected to make the right device nodes > first. Yes. It has advantages and disadvantages. It all depends on what you personally value. > > Personally, I've never been persuaded that the persistance of modifications > > argument against devfs had any validity; I have yet to see one case that > > can not be managed via rc.local or modification of driver defaults > > (e.g. I know of no transient device that results in the creation of > > multiple device nodes for the same major number). I personally think > > the correct way to handle this is to write the changes back to the > > kernel image, if we are talking about modifications to the primary > > instances of the devices. > > Loader? > ie on shutdown write a list of permissions etc into a file which the > loader can slurp up next boot and shove into the kernel and be parsed. This really doesn't work very well. You end up with two sets of data. Having done something like this in practice, and had to live with the aftermath, I don't recommend it (at all). > > But overall, it seems to be a move forward. I guess if you valued > > persistance (e.g. the ability to rename your floppy device to be > > /dev/mickeymouse) over the new features, I guess I could see your > > point. > > Mmmm.. unnecessary pain. Eye of the beholder. It's nice to not have to modify binaries with hard coded path strings in them, and instead just hardlink or symlink the local oddly named device to the system local name for the device. For tape devices, for example, the desire for tape rewind before access is really a site local policy preference, and is normally controlled through the device node -- and therefore device name used. THe "mt" command is relatively new, and is not really independent enough (as one example). -- Terry 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?3D2506F9.8B34FD80>