*BSD News Article 13080


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!umd5.umd.edu!roissy.umd.edu!mark
From: mark@roissy.umd.edu (Mark Sienkiewicz)
Newsgroups: comp.os.386bsd.development
Subject: Re: Some ideas on the driver interface (yet another idea!)
Date: 19 Mar 1993 15:59:13 GMT
Organization: University of Maryland
Lines: 70
Message-ID: <1ocqkh$lm4@umd5.umd.edu>
References: <1993Mar17.122612.5929@neptune.inf.ethz.ch> <1o9l9u$nn@tricky.wft.stack.urc.tue.nl> <1993Mar19.074044.18995@gmd.de>
NNTP-Posting-Host: roissy.umd.edu

In article <1993Mar19.074044.18995@gmd.de> veit@mururoa.gmd.de (Holger Veit) writes:
>
>Why would *you* want to modify *default* protections in a system? There are

I find that defaults are _frequently_ not correct for my uses.  I should
be able to set them up the way I like.  The current system allows me to
do this with well known commands like chown and chmod.  A replacement
system should have a similar functionality.

>A proper fs has something like
>the concept of inodes, dynamic allocation of name slots/inodes, thus making
>links and named pipes (and perhaps subdirectories) available.

I totally agree with this.  I suggest that subdirectories are not optional.

To add to that, though-  I also suggest that _storing_data_ is not optional.
I.E. /dev/fd0a may be a floppy disk, but /dev/fd0a.note may be a file that 
contains a note for users of that device.

Here is an idea I submit for discussion:

Keep your devices disk based, but don't use major/minor numbers as we
have them now.

There is enough space in the inode that you could be storing a string
instead of a major number.  When you open a device file, it could fetch
this string from the inode and look it up in a table in the kernel.  Cache
the inode-to-device lookup, and you have the equivalent of a dynamically 
assigned major number.

Then instead of
	mknod /dev/com1 c 35 0
I might
	mknod /dev/com1 c cgd_com 0
	mknod /dev/sd0a b julian_scsi 0
                          ^^^^^^^^^^^
                        the _name_ of the driver instead of some arbitrary
			number

This idea has some advantages:

technical:

	- it solves the problem of limited major numbers by using device
	  names (the thing that started this whole discussion)

	- it gives _permanence_ to devices and the changes you make to them

	- it 

	- it can _not_ get confused if you boot a different kernel

political:

	- it gives both sides of this discussion the features/functionality
	  that they want (IMHO)

Disadvantages are:

techical:

	- it doesn't work over NFS (neither does anything else)

political:

	? you tell me :)

>Holger

Mark.