From owner-freebsd-hackers  Sun Apr 23 03:09:55 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id DAA20300
          for hackers-outgoing; Sun, 23 Apr 1995 03:09:55 -0700
Received: from tfs.com (mailhub.tfs.com [140.145.250.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id DAA20294
          for <hackers@freebsd.org>; Sun, 23 Apr 1995 03:09:54 -0700
Received: by tfs.com (smail3.1.28.1) 
Message-Id: <m0s2ybU-0003voC@TFS.COM>
Date: Sun, 23 Apr 95 03:09 PDT
From: julian@TFS.COM (Julian Elischer)
To: hackers@FreeBSD.org
Subject: [DEVFS] related matters
Sender: hackers-owner@FreeBSD.org
Precedence: bulk


There are a few matters pertaining to devfs that reflect out to
other parts of the system. These include:

1/time: 
	it appears that 'time' is not set up at teh time of device probing.
	this means that the fields in the device structures that 
	correspond to mtime, atime and ctime are initialised to 
	teh epoch (Jan1 1970).. which is obviously NOT one of the
	options for the correct value..
	possible work-arounds include:
	a/	passing through the whole tree later and 'touching'
		each device (yuk).
	b/	changing the place in the initialisation where
		the real time is read in from the CMOS..

2/VFS initialisation:
	At device probe time, the VFS hasn't been initialised yet..
	I've worked around this in two ways:
	a/ 	he first time a device registers with devfs,
		the initialisation routines are called.
	b/	Pointers that would normally point to the methods
		structures (which are set up and created by
		VFS initialisation) are made to be pointers to 
		pointers, where the address given is the address of a
		location that AT SOME TIME IN THE FUTURE, will point to 
		the methods, (when they are finally set up). This
		means that there is an extra indirection on all
		devfs operations and should somehow a device need to
		be accessed before the VFS is set up, it will
		probably get a page fault.

	I would like to move these two initialisations to be BEFORE the
	device initialisations.. Can anyone see what the problems are
	with this..

3/DEVICES that are never attached.
	Some devices are never probed or attached in the same way that 
	(say) a serial port is.. An example of this is /dev/mem.
	I would like to either
	a/	add a special table of such devices
		at the beginning of autoconf or somewhere, so that
		they can have entries placed in the devfs for them..
	or
	b/	add some small init/attach functions to these devices
		and place their names in some 'compusory devices'
		list so that they can be attached like any other device.
		The fact that some devices just 'are' without any
		initilisation code has always irked me for some reason..
	If the cdevsw and bdevsw are to be made dynamic, (or ever
	made to go away), then probably each device will need an init
	routine anyway, unless a general init routine reading a table
	will do...

Your thoughts are solicited on these topics.....

julian