Date: 31 Jul 1998 16:55:21 -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: <x7hfzxzqo6.fsf@singularity.enigami.com> In-Reply-To: "Kenneth D. Merry"'s message of "Fri, 31 Jul 1998 00:04:57 -0600 (MDT)" References: <199807310604.AAA15343@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... >> 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. > 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. Second, cam_open_device claims to take a device name. It doesn't actually. 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! > 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. > - 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! 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. 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? +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?x7hfzxzqo6.fsf>