Date: Wed, 1 Nov 1995 13:11:36 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: erich@lodgenet.com (Eric L. Hernes) Cc: jkh@time.cdrom.com, grog@lemis.de, hackers@FreeBSD.org Subject: Re: More nits Message-ID: <199511012011.NAA00375@phaeton.artisoft.com> In-Reply-To: <199511011953.NAA26090@jake.lodgenet.com> from "Eric L. Hernes" at Nov 1, 95 01:53:29 pm
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... more CD automount ... ] > I kind of remember someone either working on or asking about an > amd.map which would automount the CD. I think this would > be preferable to actually mounting the CD, because it could better > handle media changes and such stuff. Also if you gratitiously mount > whatever CD is in the drive and I want to change it, I'd have to > manually unmount it, then change it and manually remount it. (but you'd > probably have to do that anyway) Anyway someone could, in theory > come up with a pretty fancy amd map that could detect media changes > and do the right thing. I just wish I knew more about amd maps :(. AMD is the wrong way to handle this period. A CDROM is just one of the class of transient media that need to be supported in BSD. The main issue is the potential removal of the media while mounted for the other media, but that's a device management logical mapping issue more than anything else as long as the device has insertion locking. This really, really needs to be addressed seperately. There are some UFS modifications that one of my coworkers has done in terms of FS state cleanup on idle that ought to go into the main kernel. Right now, the changes unfortunately depend on other modifications I've done, so they can't be integrated until the other changes have been pulled in. 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?199511012011.NAA00375>