Date: Fri, 31 Jul 1998 00:04:57 -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: <199807310604.AAA15343@panzer.plutotech.com> In-Reply-To: <x71zr2y571.fsf@singularity.enigami.com> from Cory Kempf at "Jul 31, 98 01:12:18 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Cory Kempf wrote... > > As root, create a link to a /dev/pass device, e.g. > > ln -s /dev/pass3 /dev/scanner > > Again as root, attempt to open /dev/scanner via cam_open_device. > > It fails. Why? Assuming it is a bug in cam_open_device, can we get > it fixed? 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: cam_open_spec_device(): This function takes a device name and unit number. It passes those values into the kernel to find out which passthrough device corresponds to the given device. Then, it opens the appropriate passthrough device. cam_open_device(): This function takes a device name. It must first translate the string it is given into a device name and a unit number. Then, and only then, can it ask the kernel what passthrough device corresponds to the given device. So what is happening is cam_open_device() passes "/dev/scanner" or whatever you call your device into the cam_get_device() function. cam_get_device() won't even get a unit number out of that. There's no way you'll end up opening the right passthrough device; the function shouldn't succeed at all. So, I've got several suggestions: - don't use cam_open_device(). Use cam_open_spec_device() instead. - 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. 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. There are two general ways to do passthrough SCSI commands. The first way is the way the old SCSI subsystem does it, through the control device. When you open the control device in the old SCSI layer, most of the open/close checking is bypassed. The second way, the way Justin and I have chosen to do it, is to have a separate device that is used for passthrough commands. This way, you have an open routine that doesn't have expectations about device state, and succeeds no matter what. 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. That means going through the open routine. That also means that we'd have to have control devices, which we've decided not to do. So, instead, we've got the transport layer device that does a number of things. It allows CCB types that wouldn't make sense to give to a device, and it allows things like finding the passthrough device for a given peripheral. I'm working on some more comprehensive device matching code for the transport layer. It will allow matching against bus/target/lun, peripheral name and unit number. It will provide the basic functionality in the kernel necessary to make device trees. (like everyone seems to think camcontrol -l is supposed to work. This will be camcontrol -L instead. :) ) It will be somewhat similar to the PCI device matching code, but will be necessarily much more complex. PCI devices are kept in one list, but the transport layer's EDT (Existing Device Table) is a tree of linked lists, with another linked list connecting different types of leaves at the bottom of the tree. Oh well, I've said enough. Hopefully this will answer a few questions. 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?199807310604.AAA15343>