Subject: Re: Full source dist.
To: David Brownlee <david@city.ac.uk>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: port-mac68k
Date: 11/10/1995 10:40:09
On Fri, 10 Nov 1995 13:32:16 +0000 (GMT) 
 David Brownlee <david@city.ac.uk> wrote:

 > 	disklabel should be using sysctl to get kern.maxpartitions & 
 > 	kern.rawpartition.... (tsk - I guess I should send-pr a fix
 > 	for this given I've just opened my mouth about it :)...
 > 	eeprom should report that it cant find the eeprom device on
 > 	non sun machines...
 > 	screenblank I think works on the amiga as well - it should
 > 	probably be in all ports longterm... :)

disklabel(8) should do many things differently.  First of all, knowledge 
of how to install boot code should be ripped out, stomped on, shot, and 
buried in manure.  Installing boot code is inherently machine-dependent, 
and until every port has a /usr/mdec/installboot (where appropriate; I 
guess that wouldn't apply to the mac, atari, and amiga), there's not much 
hope of having an MI disklabel(8).  Oh ... I almost forgot about the `-r' 
option ... that's where disklabel(8) opens the raw device, lseek()'s to a 
machine-dependent area (defined in <machine/disklabel.h>) an reads the 
label.  I've been thinking of a solution to the disklabel problem, one 
that involves adding a few DIOC* ioctls.  RAW_PART and MAXPARTITIONS are 
the _least_ of disklabel(8)'s problems.

As for eeprom(8), it won't even _compile_ on ports other than the sun3 
and sparc.  It requires access to a couple of very machine-dependent data 
structures.  The same might be said of grfconfig(8) for the amiga.

screenblank(1) uses no machine-dependent data structures other than the 
sun-style "fb" framebuffer interface.  It, also, has no hope of 
compiling on ports which don't use it.  I gathered at one time that cgd 
was going to use this interface on the alpha, and hence screenblank(1) 
would work there, too.

 > 	PS: There really needs to be a sysctl to get the cputype
 > 	    (ie sun4c, sun4, sun4m on the sparc port :)
 > 

Paul has been using "hw.model", which returns something like:

	hw.model = SUN-4/200 series (MB86910 or WTL1164/5 FPU)

You can parse this string to get the cpu model.  In eeprom(8), I simply 
used libkvm to grab the cputyp kernel variable.

--------------------------------------------------------------------------
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939