Date: 31 Jul 1998 22:38:29 -0400 From: Cory Kempf <ckempf@enigami.com> To: "Kenneth D. Merry" <ken@plutotech.com>, freebsd-scsi@FreeBSD.ORG Subject: Re: dev links won't open. Why? Message-ID: <x7ww8twhne.fsf@singularity.enigami.com> In-Reply-To: "Kenneth D. Merry"'s message of "Fri, 31 Jul 1998 16:30:36 -0600 (MDT)" References: <199807312230.QAA18632@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Kenneth" == Kenneth D Merry <ken@plutotech.com> writes: > Cory Kempf wrote... >> "Kenneth" == Kenneth D Merry <ken@plutotech.com> writes: > Cory >> Kempf wrote... >> As root, create a link to a /dev/pass device, >> e.g. >> >> ln -s /dev/pass3 /dev/scanner alt: ln /dev/pass3 >> /dev/scanner alt: mv /dev/pass3 /dev/scanner >> >> In all three cases the open of /dev/pass3 suceeds. The open of >> /dev/scanner fails. > That isn't surprising at all. I'll explain below. It may not be surprising to *you*. I guarantee it will be surprising to both the system admins out there and to developers. NB: most of the users of the device will not be software engineers, but sysadmin types. This mode of operation drastically changes how they control the system. Worse, it does so in a rather subtle way. >> It takes a string that is parsed according to some internal rules. >> The fact that there may (or may not) be a device in the /dev >> directory with the same name is purely coincidence! > Right. The idea is to try to determine what the user wants to > open, determine the passthrough device for it, and open the > passthrough device. I understand *what* it is doing. What I am trying to say is that it is not doing The Right Thing(tm). What I do not understand is a compelling reason *not* to use the traditional mechanism. Lets say I want to open a device "george". The Open call determines that this is a special device, digs out the major device number. That major device number says which driver to call. The minor device number belongs to the driver. Using this number, the driver can figure out which thing to play with. Neither the open call, nor the underlying driver care whether my device is named "george", "john", "pau1", or "ring0". By using the major and minor device numbers, a determination can be quite easily made as to what the user wants to open. Check out the mknod(8) man page. This is the expected behaviour. This is how the rest of the system behaves. > So it opens "/dev/rpass3", and goes on about its business. > You're complaining that deleting/removing/renaming /dev/pass3 has no > effect on opening the 3rd passthrough device. You're correct. > That's because the device node that is opened is the character > device, /dev/rpass3, not the block device /dev/pass3. Considering that so far, all I have attempted to do is say "open", it shouldn't matter which I call it on, it should work in either case. However, it sounds as if you are saying that the pass device doesn't actually support both buffered and raw access. Good, it shouldn't -- according to intro(4), buffered access is only for file system support, which pass shouldn't be used for. So, pass should be the raw device, and rpass shouldn't exist at all . I really don't understand why they both are present. It is kind of like having a door in your house that is nailed shut, and leads to a brick wall. > Now does it make sense? Again, I understand *what* is being done. My contention is that the *what* is not the correct thing for unix. There is a system in place for accomplishing the task of translating between a path and a device. We should be using it. So no, why the standard mechanism for translating between an entry in the file system and a device is not being used has not been made clear to me. > What if the device the user is trying to open isn't a > passthrough device? What if they're trying to open /dev/cd0a? I am not sure what you are asking here. Are you asking what happens if the user calls cam_open_device() on /dev/cd0a? It *should* fail. I certainly *hope* it fails. I can certainly understand the desire to want to make this kind of translation, but I don't see how it can work in all cases. > So, perhaps it would be best to do two things: > - make cam_open_device() attempt to do a stat/readlink on whatever > it is given, just in case it's a real path that's a symlink > - create a new function called cam_open_pass() or something like > that that expects to be given the path to a passthrough device. If I do the first, and the second is redundant: anything that could be passed to the second could be passed to the first with the same results. Essentially, what you are suggesting is fixing cam_open_device to work the way I think it should work, and, if that doesn't work, attempt to guess what the pass-though device should be for that device? What happens if, next year, I write a new device driver for the system, how will cam_open_device know how to translate either my device name, or my major/minor device numbers to a particular device on the chain? I would recommend for the latter case (assuming that you don't already) making the translation between random other devices to pass through devices something that is stored in a /etc/config file. That way, at least, when I build my super-whatsit driver next year, it will still work. > If you'd like to do the code, I'll be glad to take a look at > the diffs. Are we in agreement that this is how the code should be changed? If so, I will take a shot at it. +C -- Thinking of purchasing RAM from the Chip Merchant? Please read this first: <http://www.enigami.com/~ckempf/chipmerchant.html>; Cory Kempf Macintosh / Unix Consulting & Software Development ckempf@enigami.com <http://www.enigami.com/~ckempf/>; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?x7ww8twhne.fsf>