Messages in this thread |  | | From | "Eric Youngdale" <> | Date | Mon, 1 Jul 1996 11:43:20 -0400 | Subject | Re: SCSI device numbering (was: Re: Ideas for v2.1 |
| |
>Actually, I've long been of the opinion that we should use more major >numbers. It doesn't make much sense to use the same major number for >different controllers, and I think we could use dynamic mapping of _major_ >umbers within controllers. Each controller (*) that is found gets a major >number of its own, with some very simple algorithm (reserve najor numbers >256-384 for SCSI devices, increment for each controller, something like >that).
If you suggesting that we use one common major number for every device on a given bus, then we need to decide how we assign minor numbers in light of the fact that we can have a mix of disk, tape, cdrom and generic device nodes trying to use the same major number. My guess is that for cdroms the 'partition' field would be 0. For tapes, the partition field could be used for the rewinding/non-rewinding part. This strikes me as a bit unclean, but I could be talked into it. I need to think about this a bit to see whether there are any other potential problems.
My main objection to the dynamic major idea is that it still leaves potential problems with devices being remapped to different major numbers if you move controller cards around. Some utility like scsidev would still be required to maintain the /dev entries that correspond to the dynamic majors. If people don't mind this level of inconvenience, then I have no problem with it, but I thought the point of this exercise was to try and see whether we could completely get away from dynamic assignment of device numbers.
Also, there are some people who would like to have one common major number for *all* cdrom drives on the system (ide, scsi, etc). A top level driver would essentially dispatch through a table down to whatever the appropriate driver is to do the job. Dynamic majors take us further from this, although a sort of virtual device driver would probably also do the job here.
I am not trying to be negative, but just playing devil's advocate. Splitting up the request queue into smaller lists is certainly a positive side effect of a change like this, as it simplifies some of the queue handling code that we have, and effectively using one major per bus is undoubtably a logical way to divide things up.
-Eric
-- "The woods are lovely, dark and deep. But I have promises to keep, And lines to code before I sleep, And lines to code before I sleep."
|  |