> At 9:41 -0800 3/20/00, Eduardo E. Horvath wrote:
> 
> >[2] I have experimented with using a 32-bit init on a 64-bit kernel.
> >Some parts of it can be made to work.  But eventually it bombs when
> >trying to issue sysctl()s.
> 
> One way that the sysctl issue can be mitigated is by using /kern more 
> creatively. There is already a hierarchy of names in the sysctl(2) 
> space which look either like filenames or SNMP OIDs, depending on 
> your particular bent, and it strikes me that it should not be all 
> that difficult to set up /kern so that those objects can be 
> manipulated in a machine-independent way.

The main problem with that is you start making /kern or some other
funky filesystem mandatory and you break chroot(), along with any
associated security holes the filesystem may introduce.

I think it would be much easier to fix sysctl itself.  It just needs
to be changed so instead of each subsystem having to provide some
specialized function to handle its sysctl variables, we have a
parsable kernel structure providing the name, type, size, security
information and a pointer to the actual variable.  Then generic code
can parse the structure and the 32-bit syscall wrapper can do
appropriate type conversions.

Actually, the entire syscall framework should be overhauled to
separate out the interface from the implementation.  I have found the
need to duplicate complete system calls because they issue
copyin()/copyout() of additional data not part of the args structure.
The SYSV messaging stuff is certainly the worst offender.

=========================================================================
Eduardo Horvath				eeh@netbsd.org
	"I need to find a pithy new quote." -- me