On Oct 7,  5:50pm, Greg A. Woods wrote:
} [ On Tue, October 6, 1998 at 00:35:20 (-0400), der Mouse wrote: ]
} 
} Don't go that far.  I presume that everyone would like to see the
} current layering in SCSI maintained.  That means that it's merely a
} matter of ensuring that there be a predictable way to map SCSI
} controllers onto "scsibus" attachments.  Eg. slot # for PCI or Sbus
} (I'll leave PCs out of this for sake of a clean argument!  ;-)

     I'm assuming that you're ignoring VME and the various VAX buses
as well.  This doesn't make for a clean argument, it makes for an
absolutely disgustingly filthy dirty argument.  Anything that would be
produced from it would need a ton of special cases and hacks to handle
all the machines that NetBSD supports.  With NetBSD, you can not
afford to ignore anything when making design decisions.

} I.e. the first one found in slot order goes to scsibus0, the second to
} scsibus1, etc.  We can then map the "scsibusN" to "cN" in /dev/*disk.
} Each "cN" is given a different major number, and a given kernel
} configuration is allowed only a maximum number of scsibus attachments
} through a config line such as "pseudo-device scsibus N".  This same
} number is given to MAKEDEV (perhaps as scsibusN).

     I assume this pseudo-device would simply be a passthrough driver
that figures out to which real driver the syscall should be routed,
and would be completely optional?  Even at that, there is a major
problem: pseudo-device's only get one major number, with each instance
being assigned consecutive minor numbers.  Are you planning on
creating a new kind of pseudo-device where each instance is given a
seperate major number and changing the kernel configuration code to
implement this?  That sounds like a pretty major change.

} (Pure ISA pc's could assign by order of IRQ or port# or whatever, though
} I don't know what I'd do about PCI+ISA etc.  I don't like thinking about
} PC hardware too much....)

     Me neither, but the reality is that it can't be ignored.

} > Each scsibus can hold at least 56 devices (120 if it's wide).
} 
} That's still just over half the possible minor numbers (2760) used for a
} given bus, even if you assume expansion of MAXPARTITIONS to the current
} MAXMAXPARTITIONS of 22 (plus one for the "raw disk").
} 
} Assume a "GENERIC" kernel has "pseudo-device scsibus 4" and you still
} only need 11040 entried in each of /dev/dsk and /dev/rdsk.  I don't have
} any problem with that at all, though a devfs would probably speed

     I do!  It would slow down every directory operation immensely.
Remember, you have to do linear searches through directories to find
files.  They aren't sorted, and can have varying lengths.  The only
version of UNIX that I know about which handles huge directories well
is IRIX.  SGI has apparently created a new filesystem type which uses
B-Tree's for directories.  Apparently, this thing is capable of
handling 100,000 files in a directory without batting an eye.  That
would be something neat to get although I don't know of many places
where it's needed (except for /var/mail; I have one machine with over
10,000 accounts on it).

} installation up a lot!

     I really don't like the idea of a devfs.  Various people have
stated the problems with it in the past, so I won't dwell on them.
But, if it was completely optional and didn't have any impact on the
rest of the system, I probably wouldn't be bothered too much by its
presence.  That means it can't be implemented like the FreeBSD one
where every driver has to be modifed for it.

}-- End of excerpt from Greg A. Woods