Date: Sat, 13 Dec 1997 04:36:24 -0700 (MST) From: bgingery@gtcs.com To: julian@whistle.com Cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) Message-ID: <199712131136.EAA20537@home.gtcs.com> In-Reply-To: <Pine.BSF.3.95.971213021310.29160D-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 Dec, Julian Elischer wrote: -} On Sat, 13 Dec 1997, Mike Smith wrote: [mucho muncho] -} Most new access methods will either: -} 1/ be totally random access .... (we get no gain from using geometry) -} 2/ emulate a disk, (using the apparent geometry may be wrong pessimal -} in the face of teh underlying REAL geometry) -} 3/ have a differnt geometry charateristic that we cannot try guess ahead -} of time. Yes. I may be mentioning things that have no immediate effect here. Yet, I mention it just in case it MIGHT affect designs in such a way that it reduces the work for future adaptation. The last I heard about gel memory was well over a year ago, and I also have seen no updates on the impregnated porous glass. BOTH would seem to be optical and involve 3-d addressing at the substrate level. What controllers are placed above that - most likely a "disk emulation" as the LEAST efficient, but quickest to use. If an XYZ coordinate system *could* be stored for maxvalues as if it were blk/trk trk/cyl and ncyl, then if those storage positions are available, they could be overloaded. [munch history] -} -} I'm sure I've forgotten some, but you must see a pattern here. Over the -} last 5 years I've been constantly working towards a more modular and -} dynamic freeBSD. Many of the things I have added are not really fully -} appreciated yet, but will become so as soon as more pieces of the jigsaw -} are completed. If you're using "appreciated" in terms of people's attitudes, you've got my vote! At Sat, 13 Dec 1997 21:51:26 +1030 (CST) Mike Smith <mike@smith.net.au> followed up (in part): [Re: using IOCTL to notify drivers of change between ro/rw] -} How would you reject the ioctl? (FWIW, I am inclined to agree that -} overloading the ioctl interface is the "best" approach here, if not the -} most architecturally clean.) Bear in mind that an unknown ioctl will -} usually return ENOTTY or similar; you would have to specify an explicit -} return value for rejected upgrades. Yes, ENOTTY or similar if it doesn't apply, and EINVAL if the an underlying device refuses it. That would agree with at least three uses of EINVAL. Bruce Gingery <bgingery@gtcs.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712131136.EAA20537>