kjh@aludra.usc.edu (Kenneth J. Hendrickson) (10/27/90)
I have learned that on the NeXT (and possibly other *nix systems), there is a /etc/disktab animal that lists characteristics of disks, much like /etc/termcap lists the capabilities of a terminal. This sounds like a good idea to me. The kernel could read this file and configure itself for the correct number of tracks, sectors, cylinders, heads, etc. Thus this information would not need to be hardcoded into the kernel as it is now. I don't know much about disk controllers, but could this help the compatibility problem, and development of SCSI and ESDI device drivers? It is kind of "begging the question" to use this if you are booting from a hard disk, but it makes perfect sense if you are booting from a floppy. What say the device driver gods? Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (10/30/90)
How can the kernel read drive parameters from a disk file before the drivers get initialized. So you must at least make the kernel so intelligent to read the root disk. P.S. The kernel knows nothing about file system structure and has to call FS for that, blocked waiting. FS will call a driver... is this deadlock-proof? I still prefer to control everything through the minor device numbers. C.v.W.
korni@sietec1.sietec.de (Jochen Kornitzky) (10/31/90)
+---- "Kenneth J. Hendrickson" about "disk controllers" : | | I have learned that on the NeXT (and possibly other *nix systems), there | is a /etc/disktab animal that lists characteristics of disks, much like | /etc/termcap lists the capabilities of a terminal. This sounds like a | good idea to me. The kernel could read this file and configure itself | for the correct number of tracks, sectors, cylinders, heads, etc. As I known the *ix-world, /etc/disktab is not read by the kernel itself (there is no reference to ANY filename inside the kernel) ( ... mumble mumble ... oh: /etc/init ;-) but by various tools (as markbad, mkfs, low-level-format, disklabel ...). When formatting and partitioning a disk, such a tool writes the selected (from /etc/disktab) characteristics *on the disk* where the kernel can read it. | Thus | this information would not need to be hardcoded into the kernel as it is | now. I don't know much about disk controllers, but could this help the | compatibility problem, and development of SCSI and ESDI device drivers? There could be various device drivers in the kernel and decide at startup which to run. | It is kind of "begging the question" to use this if you are booting from | a hard disk, but it makes perfect sense if you are booting from a | floppy. That's why it's written onto the disk. | | What say the device driver gods? | Oh Lord. | +---- Jochen -- +--Jochen Kornitzky-------+---------------------------------------+-----------+ | | | . | | SMAIL: | EMAIL: | . | | Sietec GmbH & Co. OHG | | . | | z.Hd. Jochen Kornitzky | korni@sietec1.sietec.de | . | | Nonnendammallee 101 | ...!uunet!unido!sietec1!korni | | | D-1000 Berlin 13 | Postmaster for *.sietec.de | . . | | Germany | | | +-------------------------+---------------------------------------+-----------+
jca@pnet01.cts.com (John C. Archambeau) (11/02/90)
kjh@aludra.usc.edu (Kenneth J. Hendrickson) writes: >I have learned that on the NeXT (and possibly other *nix systems), there >is a /etc/disktab animal that lists characteristics of disks, much like >/etc/termcap lists the capabilities of a terminal. This sounds like a >good idea to me. The kernel could read this file and configure itself >for the correct number of tracks, sectors, cylinders, heads, etc. Thus >this information would not need to be hardcoded into the kernel as it is >now. I don't know much about disk controllers, but could this help the >compatibility problem, and development of SCSI and ESDI device drivers? SunOS has something called /etc/format.dat. All that basically does is tell the generic driver the physical parameters of the disk. Very similiar to the ISA drive types in your AT BIOS table. If the Sun is equiped with multiple controllers, then that is also part of the format.dat entry. Help the development? All this would eliminate would be the need to hardcode the hard drive parameters. It does NOT circumvent or make writing a device driver for a given hard drive controller any easier. You still have the problem (especially with SCSI host adaptors) that every manufacturer does it differently. >It is kind of "begging the question" to use this if you are booting from >a hard disk, but it makes perfect sense if you are booting from a >floppy. > >What say the device driver gods? Admittedly, it is a nice idea, but first you need a working device driver for brand X hard drive controller. // JCA /* **--------------------------------------------------------------------------* ** Flames : /dev/null | Small memory model only for ** ARPANET : crash!pnet01!jca@nosc.mil | Unix? Get the (*bleep*) out ** INTERNET: jca@pnet01.cts.com | of here! ** UUCP : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */
evans@syd.dit.CSIRO.AU (Bruce.Evans) (11/05/90)
In article <12771@chaph.usc.edu> kjh@aludra.usc.edu (Kenneth J. Hendrickson) writes: >I have learned that on the NeXT (and possibly other *nix systems), there >is a /etc/disktab animal that lists characteristics of disks, much like Shoelace already has a /etc/disktab. It does not consult it at boot time, however. >good idea to me. The kernel could read this file and configure itself >for the correct number of tracks, sectors, cylinders, heads, etc. Thus The kernel cannot read files. Especially before the disk drivers have been initialised. You can think of shoelace as a pre-kernel. It can read files and pass strings to the (1.5) kernel in the environment. The current drivers do not take advantage of this. -- Bruce Evans evans@syd.dit.csiro.au