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.