Date: Fri, 31 Jul 1998 16:30:36 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: ckempf@enigami.com (Cory Kempf) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: dev links won't open. Why? Message-ID: <199807312230.QAA18632@panzer.plutotech.com> In-Reply-To: <x7hfzxzqo6.fsf@singularity.enigami.com> from Cory Kempf at "Jul 31, 98 04:55:21 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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's not a bug, and it really isn't something to fix. You > > misunderstand what cam_open_device() does. Have you read the > > source? I'll explain: > > First, one should not have to look at the source to figure out what a > function should do. Well, how else do you propose to figure it out, when the documentation hasn't been written? > Second, cam_open_device claims to take a device name. > > It doesn't actually. That's a historical artifact left over from when it actually did take a path to a device node. I left the name and arguments the same so we wouldn't have to rip the interface out from under people. In most cases, it works just fine. > 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. > > So, I've got several suggestions: > > > - don't use cam_open_device(). Use cam_open_spec_device() instead. > > Perhaps this would be an acceptable answer on Windows or OS/2. > Certainly on Macintosh it would fly. > > Part of the design of unix is that device access is done through the > file system. I will restrain myself from getting on a soap box here, > and just say that the current approach violates the core of unix OS > design. > > With the exception of the berkeley socket interface, ALL unix I/O is > done though the file system. This is the key reason that unix has > scads of filter programs that can be string together to do interesting > things. > > This is why, for example, tar works with files as well as tapes. > Hence kernfs, procfs, et al. Personally, I find this a rather useful > abstraction. > > Unfortunately, CAM has disconnected itself from the file system. > > Try the following: > > mv /dev/pass3 /dev/scanner # or whatever pass# works for you > > and run the code I posted. > > /dev/pass3 opens, *EVEN THOUGH THERE IS NO SUCH FILE!*, but > /dev/scanner doesn't open, even though it exists, nad has the correct > major and minor device numbers. > > I think that if you float this about, the response will be > overwhelming that this is wrong behaviour. I think if you looked at the source code, you would understand why it is doing what it is doing. You're moving /dev/pass3, when that isn't the device that gets opened at all! You claim that CAM has "disconnected" itself from the filesystem metaphor, when it isn't true in the least. When you pass in the string "/dev/pass3" to cam_open_device(), it figures out that you want to open device type "pass" and unit number "3". It passes that into the kernel, which of course says that the passthrough device for that device is pass3. 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. Now does it make sense? > > - read the source code and try to figure out what's going on. > > You've obviously spent some time pondering this, it wouldn't take > > too much more time to figure out the reason your code fails. > > Clearly I am going to have to: Justin says he doesn't have the time to > deal with such 'minor' design flaws, Kenneth seems to be saying that > opening non-existant files is a feature. > > > I'm sure someone or another will pipe up about now and ask why > > we can't just do an ioctl or some such on the device in question to > > figure out what its passthrough device is. Well, the answer is that > > it's a philosophical question that I think I've covered on this list > > before. > > I must have missed it. I would love to understand the reasoning > behind breaking with fundimental unix design, and the consiquent loss > of functionality. > > I certainly would be interested in hearing a justification for opening > non-existant files! See above, they certainly do exist. > In any case, all that *should* need doing is to determine the major > and minor device numbers of the file passed in, and ensure that the > effective UID/GID allows access to the device file. > > > So what does this have to do with determining what the > > passthrough device is for a given device? It's simple. In order to > > do that, you'd have to do some sort of ioctl on the device. > > I really don't understand why: /bin/ls can determine that a file is a > link, and can show the resolution of said link. It can also display > the major and minor device numbers for that file, and what kind of > file it is (e.g. block special, character special). It does this via > stat. What if the device the user is trying to open isn't a passthrough device? What if they're trying to open /dev/cd0a? That's the point of cam_open_device(). It tries to figure out what device the user wants to open, and then opens the corresponding passthrough device. You seem to be assuming that whatever the user tries to open *will* be a passthrough device. I don't assume that at all. I assume people will want to say something like "give me a way to send raw SCSI commands to cd0". I think I have an idea of how to solve your problem, though. See below. > So, clearly we have a rather serious disagreement here. I certainly > don't mean to imply any disrespect for the work Kenneth and Justin > have done -- without which I wouldn't even be able to run FreeBSD. > But, I really don't think that the interface is correct for UNIX. > > I am willing to put in the work necessary to fix the problem, if that > work will become a part of the CAM code. > > So, how do we proceed? I think the solution to your problem is a function that will treat whatever you give it as a passthrough device and attempt to open it as such. Something like "cam_open_pass()". Then it wouldn't depend on knowing a device type or unit number. It would know that the device in question is a passthrough device, so you can rename it to whatever you want. You can name it "/dev/scanner", "/dev/scanners/1" or anything else under the sun, as long as the major/minor are correct. Another thing that would work in some cases, but not in others is to do what Justin proposed -- have cam_open_device() attempt to do a stat/readlink on what is passed in, just in case it is a symlink. That would still depend on the underlying device having the correct name. You could still do something like: mknod /dev/foobar c 200 3 ln -s /dev/foobar /dev/scanner That would make a node named "foobar" that points to the third passthrough driver. Doing a stat/readlink on /dev/scanner would still give you the wrong name. 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 you'd like to do the code, I'll be glad to take a look at the diffs. Ken -- Kenneth Merry ken@plutotech.com 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?199807312230.QAA18632>