Date: Sun, 14 Dec 1997 12:52:07 +1030 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: mike@smith.net.au (Mike Smith), bgingery@gtcs.com, hackers@FreeBSD.ORG Subject: Re: blocksize on devfs entries (and related) Message-ID: <199712140222.MAA04796@word.smith.net.au> In-Reply-To: Your message of "Sat, 13 Dec 1997 20:55:27 -0000." <199712132055.NAA29304@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Theoretically, the physical layout of the device should be stored > > > whether or not there's any filesystem on it. > > > > This is a fundamentally flawed approach, and I am glad that Julian's > > new SLICE model (at this stage) completely ignores any incidental > > parametric information associated with an extent. > > One "incidental" piece of parametric information I am interested in > seeing is the physical block size. I wouldn't want to call the physical block size "incidental"; in combination with the block count it is a fundamental parameter of any extent. > Consider the FFS directory management code. It has knowledge of > physical blocks. In fact, it can not easily handle a directory > block that is not exactly a physical block size. The current code > can not be broken across block I/O's, nor can it handle partial > block I/O's well (there are a number of failure modes). This sounds like a fault in the FFS design. Do you know of any work that deals with this? > For you to be able to fit a maximally-sized file name in a single > directory block means your directory block must be over 512 bytes > in length. Would you suggest upping the "fundamental" system blocksize? How would FFS cope in the face of 2k blocks? > > Incorrect. It is relatively straightforward to create a vnode disk, > > slice it, build a FAT filesystem in one slice and then pass that slice > > to your favorite PC emulator. > > I believe there should be an INT 21 redirector in the PC emulators to > allow them to use any VFS disk to which the process they are running > in has legitimate access. Yes, yes yes. Doscmd and PCEmu do this already. Bochs is rather more primitive in that regard, but now that we have a fulltime FreeBSD-Bochs liaison there is a chance that some of the work in those tools will be absorbed there as well. > Consider a FAT FS. A FAT FS deals with 1K blocks. But these 1K blocks > are not constrained to start at an even offset from the start of the > disk, only from an even cylinder boundry. In the light of the nonexistence of "cylinders" in the proposed model, it strikes me that this becomes an issue of synthesising a conforming pseudo-geometry at filesystem creation time, and little more. Compatability is likely an issue there. > > This is trivially obvious, and forms the basic argument for the use of > > DEVFS. You fail to draw the parallel between system startup and the > > conceptual "massive arrival of devices" which is still the major > > argument for such a system. > > The events should, ideally, be propagated out of the devfs framework, > IMO. I'm not sure Julian agrees with me on this. This would mean that > after you ask the slice handlers if they want the device, and they all > say "no", it's a terminal device. But the event should keep going. Hmm. I've been wondering about the issues involved in an "event dispatcher" of sorts. There's already something along these lines in the network code, as I understand it, where you can sit on a socket listening for routing events. A similar facility would be useful for listening for other interesting events. The issues that I've been puzzling over are to do with queueing events (eg. consumer is not actually listening right now; do you keep a single list of events and discard at the point where the event has been heard by all listeners, or do you create a separate queue for each listener and copy events per the listener's "interest mask"?) and passing events to in-kernel consumers... > Ah, brave new world, that has such thing in't. 8-). Yeah. I bet the old farts are saying "good thing it's them windbags discussin' this, if'n it were someone prone to doin' stuff we'd be in serious shit, eh boys"? 8) mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712140222.MAA04796>