Date: Wed, 19 Apr 95 11:54:59 MDT From: terry@cs.weber.edu (Terry Lambert) To: peter@bonkers.taronga.com (Peter da Silva) Cc: julian@freefall.cdrom.com, fs@freefall.cdrom.com, hackers@freefall.cdrom.com, hardware@freefall.cdrom.com Subject: Re: [DEVFS] your opinions sought! Message-ID: <9504191754.AA19153@cs.weber.edu> In-Reply-To: <199504191240.HAA14829@bonkers.taronga.com> from "Peter da Silva" at Apr 19, 95 07:40:06 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I don't see any reason in devfs to make these symlinks, since it's all > virtual anyway... just have them both have the same major/minor. The reason for symlinks is to cannonize the access to the devices by heirarchy. This means that the same heirarchy is used for each access. The point in doing this is to embed some of the device information in the heirarchy itself. Typically, this would be what was formerly called the minor device number. > Secondly, is there a technical reason for separating wdn from sdn in the > disk-only view? I see a reason for seperation by controller instance, but not by controller type. The main issue in controller type is instance order to the BIOS to determine which disk we are booting from when we are booting from 0x83. I think this is totally irrelevant to the discussion of device creation. On the other hand, one could certainly desire to have direct access to the SCSI bus on a per target basis... although perhaps the same is true of EIDE. > Finally, since you only show things that actually exist, there's not much > point to a deep hierarchy. Sun's devfs uses a hierarchy and it's a pain... Again, it's useful to unclutter the top level directory AND to add a major number while still getting rid of specfs entirely. > A little hierarchy to avoid /dev chaos with everything in one place, yes, > but how about just two levels? I agree. You *can't* exceed two levels within the representational geometry anyway, since the only thing you are passed to resolve a path component is the directory vnode pointer of the previous path component and the path component to resolve. You can assume you are on /dev easily enough, which gives you a single selector. The only way around this would be adding an argument to the lookup that was a pointer to a long that could be modified by the called FS to generate context for looking up subsequent path components. Direct use of the context as a synthetic inode value (you could not use it for a vnode, since by then that vnode has been unlocked) yields only a single additional lookup depth. Anything beyond that would require that the long be used as a pointer to a file system specific context record. As I said in a previous post, I have every intention os using this mechanism some day anyway. [ ... blue sky ... ] I agree with most of this, but would suggest two digit naming to ensure place holders and to simplify the per device name generation. This admittedly results in a loss of 10 potential devices, but I think a distinction between a '07' and a '7' device would be confusing in and of itself anyway. Terry Lambert terry@cs.weber.edu --- 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?9504191754.AA19153>