*BSD News Article 12080


Return to BSD News archive

Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!umd5!roissy.umd.edu!mark
From: mark@roissy.umd.edu (Mark Sienkiewicz)
Newsgroups: comp.os.386bsd.development
Subject: Re: Release of drivers etc.
Message-ID: <18733@umd5.umd.edu>
Date: 1 Mar 93 17:32:40 GMT
References: <1993Feb24.100925.24396@gmd.de> <18685@umd5.umd.edu> <1993Feb26.084810.15566@gmd.de>
Sender: news@umd5.umd.edu
Organization: University of Maryland
Lines: 44

In article <1993Feb26.084810.15566@gmd.de> veit@fanoe.gmd.de (Holger Veit) writes:
>If anyone really wants to write a new driver, instead of "improving" some existing
>one (which is general practice now), a new name can be found. With the numbering
>scheme, the few available numbers will be "reserved" real soon (unless we move to
>16 bit major numbers).


Actually, I like the ability to name the device whatever I want.  e.g. If
I change the device driver for com1, I don't have to change all my uucp 
files.  Presumably you would keep this capability via links or symbolic
links.

>|> For example, the idea of "devfs" changes cdevsw[major(dev)] into a lookup
>|> table indexed by name instead of the major number.  In this case, I would
>|> claim that the major number is now a variable number of bytes instead of
>|> a fixed small integer.
>
>No, no. With a special hash function you might map names uniquely to small integers.
>But this is too complicated. When the lookup tables ([bc]devsw) are built up at
>boottime, there is still a simple index which is, however dynamically allocated,
>and may even change if you move a kernel to another system.

My point is that you have merely changed the size of the namespace for devices
from 8 bits to 255*8 bits.  Of course you would hash it into a small number.

I'm interested in just how you would go about getting from the open system
call to the device driver.  The special filesystem for devices sounds
like a clean interface into the current system.  Do you have other ideas?

>|> Maintaining compatibility with the programmers is an important part of 386BSD.
>|> _I_ am using it because I wanted BSD.
>Again the question: *application* or *kernel* programmer? The application programmer
>won't see at all that something has changed.

I see your point, but I am mostly interested in kernel programming.  I do
applications all day. :)

It also sounds like the fundamental kernel-driver interface is not very much
changed by your scheme.  i.e. you open a file and, somehow, XXopen() gets
called.  I think this is a good thing, because people can learn and practice
device drivers on 386bsd, then take that knowledge with them to other
BSD-based systems.

Mark S.