Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!usc!sol.ctr.columbia.edu!hamblin.math.byu.edu!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.os.386bsd.development Subject: Re: Coexisting on the PC Date: 26 Mar 1994 09:02:47 GMT Organization: Weber State University, Ogden, UT Lines: 70 Message-ID: <2n0tnn$l5f@u.cc.utah.edu> References: <Mar.24.02.21.57.1994.28171@farside.rutgers.edu> <Cn6GtH.FIp@apollo.hp.com> <hastyCn6psK.D5n@netcom.com> NNTP-Posting-Host: cs.weber.edu In article <hastyCn6psK.D5n@netcom.com> hasty@netcom.com (Amancio Hasty Jr) writes: >However, there should be no need to use a funky BSD label to access a >DOS partition;specially, if the information is already available >in the form of a DOS partition. Agreed; the problem is the decode order. What really wants to happen is that logical devices (as defined by DOS partitioning) need to be decoded in an Intel (DOS machine) specific way, such that all machines of this ilk always use DOS parititioning and treat them as disting logical devices. My first tendency would be to use the minor number bits reserved for LUN and say LUN's aren't supported on DOS machines (ie: a limit of 7 devices + the controller for each SCSI BUS). The logical place for logical partitioning is an Intel specific layer in the block I/O interface, preferrably using macros so that it can invisibly drop out on other (non-intel) machines that want to use the same drivers. PCI/ISA/EISA based non-Intel machines like the DEC Alpha AXP-150 and several announced Motorolla PPC boxes fit this description. It would even allw the minor number decoding to occur "invisibly", also in macros. Another interesting piece is the support for a non-BSD partition; to do this, you have to steal one number (prefferably 0) from the device slice identification namespace to refer to the logical device without considering the BSD label for logical BSD partitions withing the DOS partition table logical partition. That still leaves 1-f -- the rest of the 4 bit slice namespace -- to identify BSD logical partition contents. Then the file systems that understand non-BSD file systems don't apply the BSD partitioning to that device, and the mount "just works". Finally, the last stage is understanding of translated DOS geometry for DOS and other BIOS-based-OS's logical partitions (HPFS, Chicago, etc.). This involves getting the geometry from the BIOS during the boot prior to going to protected mode (where the BIOS won't run) OR by getting the BIOS geometry afterwards usign vm86() calls (not yet supported). The easiest of these is to call INT-13 AH=8 from the BIOS-based boot blocks and pass the information to the kernel for later use by the BIOS-based-OS's file system module in the protected mode OS (BSD). This is the missing piece in SVR4, actually (as many times as I've tried to give it to them too, you'd think it's be there...). This is actually very, very simple to implement, and only gets incrementally (that is to say, "not much") harder from supporting extended partitions at the same time. In reality, it is unlikely that the BSD disklabel will be truly portable, and with this being an isolated layer on top of the block I/O layer and calling it via macro that know about the DOS partition and it being Intel centric, it should be easy to make the BSD disklabel based slice management portable. This would go a long way to having a unified system that still allowed the native SunOS formatted UFS partitions to "just work". Anyway, that's my $0.02 yet again (I guess I owe close to a buck now). 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.