Date: Mon, 6 Jan 1997 15:01:30 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: peter@taronga.com (Peter da Silva) Cc: hackers@freebsd.org Subject: Re: more than 32 disks? Message-ID: <199701062201.PAA12717@phaeton.artisoft.com> In-Reply-To: <199701031302.HAA07824@bonkers.taronga.com> from "Peter da Silva" at Jan 3, 97 07:02:49 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> with an sd3<n> problem yet. :-) It looks like there are only 5 bits for the > >> unit number. This means that one will have to make driver changes to go > >> beyond 32 units. :-( > > >*sigh* I absolutely hate fixed fields :( *grumble*. So whats the generic > >solution besides encoding data into the minor number? Encode a table offset > >into the minor number and make the table dynamic? > > Use a wider minor number, a wider portion of the minor number for unit, > decrease the number of bits used for things other than unit, use multiple > major numbers, or use another encoding than major/minor numbers for device > files (via devfs). > > Some aspects of the System V kernel build model, where the major numbers > can be easily reassigned and the same file is used to drive the building > of the kernel and the files in /dev, are really handy. Of course devfs > makes it a point moot... The major number is the index in the cdevsw/bdevsw; the major number should go away (though devfs, unfortunately, carrys one around). It should die because cdevsw/bdevsw should die. The minor number is a unit index for the device driver; the minor number should go away, since the instance records which the device operates against should be referenced via the data pointer in the vnode for the device (which itself references a common driver data structure (though devfs, unfortunately, carrys around minor numbers, too). It should die because the unit records are context which can be provided by an allocated instead of a statically indexed unit context value for a given driver. So the point is not only moot, the context in which the point was being made is also moot (or should be... screw backward compatability with bogus old drivers -- update them to register with devfs if they are useful). Same argument applies to having permanent attributes set by chmod/chgrp/chown by reflecting static data into a real file system anywhere... if you want to change the values, do it in the config file when you define the device in the first place, and have it built into the registration record for the device instead of kludging it up. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701062201.PAA12717>