Date: Sat, 1 Aug 1998 02:01:11 -0600 (MDT) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: Cory Kempf <ckempf@enigami.com> Cc: scsi@FreeBSD.ORG Subject: Re: dev links won't open. Why? Message-ID: <199808010801.CAA22973@narnia.plutotech.com>
next in thread | raw e-mail | index | archive | help
>>> 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. I agree. Most of the users of CAM will have no inkling of how the internals work. Instead, they will be using utilities that have been properly ported to CAM which have command line interfaces that document explicitly how that particular utility expects devices to be specified. None of these end users will know anything about "cam_open_device()" and if the utility doesn't behave correctly, it is the fault of the person who ported the utility. >>> 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. Haven't you heard? Major and minor numbers are "going away". When DEVFS becomes a reality (probably not for another 6 months), the entire kernel will transition to using vnode lookups to get to the devices behind DEVFS entries. Although CAM does not currently work with DEVFS, I will not accept a design that will be obsoleted once DEVFS becomes the standard. There are too many tables of device major numbers in the kernel and userland utilities as it is. The final semantics of mknod(8) haven't been decided yet, but I doubt that this interface will work the same way it does now. Now, let me propose an example of my own. Lets say that a user of cdrecord wants to do a record session on cd5. He doesn't know that cd5 also has pass2 attached to it even though pass2 is the device cdrecord really needs to talk to. How does the system determine this information? The correct way is to pull out the unit number of the CD device of interest and go ask the XPT to do the lookup for you. cam_open_device is simply one implementation of a function that attempts to parse a user supplied string and to extract the base device type and unit number for an XPT lookup. It may not be a perfect implementation, but it does exactly what it was intened to achieve. > This is the expected behaviour. This is how the rest of the system > behaves. If you wish to write a CAM compliant userland program that expects the user to provide a device node for the pass-thru device directly, there is nothing stoping you from doing it right now. The proper routine to use is "open". I simply do not expect the typical user to: 1) Hardwire their pass devices so that they don't move should they power off an external device or remove a device from their system. 2) Go around making funny links to their unwired pass devices. 3) Remove or rename the standard DEVFS entries for the devices they wish to talk to. 4) Know much if anything about the fact that pass-thru devices exist at all. I expect that they will want to say, "work on /dev/cd0a", not "work on /dev/pass15". I do also expect that they may use a symlink to create a more convenient name for some devices, and I even told you how this could be addressed using lstat and readlink in cam_open_device. >> 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. This is secondary to your original point. I had planed to talk to Ken about this as the other devices are superflous. The r devices should die. Anyway, lets finish addressing your first complaint without any more hauteur. > 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. The mechanism used to get to the pass-thru device is something that each utility can decide on it's own. The cam library provides a few mechanisms to do that. You can completely ignore the libary (including the proposed extensions that allow you to specify devices in additional ways) if you wish. The cam_open_device routine is simply there to handle the quite common case of someone specifying one of the known, non-pass devices as an argument, and determining the correct pass through device to use. >> 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. So that all of our users need to know about the pass through drivers and how they map to the devices they are more familiar with? Or do you want all CAM compliant utilities to do the XPT translation themselves instead of relying on common code? > 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. Hint. It can't. It will work in 99% of the cases, and if the utilities are written correctly (i.e. simply take a unit number to work on and pass that and a device type identifier into the cam library), it will work so long as the pass device exists in /dev. With DEVFS, the pass entry is guaranteed to exist unless administrative action was takes to remove it or change its access permissions. > 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? Yes. But also realize that using cam_open_device at all is flawed. That is why it is specified as a "Backards compatible only" interface. You should really be using cam_open_spec_device and provide a user interface to your utility that maps nicely to a call to this routine. > 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? It will have to be the device name. If you commit a new CAM driver, you should also update the library. If you don't, you aren't doing your job as a developer. > 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. Translating based on driver name is much more exact and will also work when DEVFS is fully integrated. The days of statically declared major and minor numbers are numbered. Pun intended. Whether the translation is in a configuration file or in the library itself really doesn't matter much. Either scenario requires something to be updated. Users of FreeBSD update their binaries more often then they do their /etc files. You can still get all of the flexibility of the configuration file so long as the base device in question is a standard one and you use symlinks instead of mknoded or renamed device nodes (assuming lstat/readlink code in cam_open_device). > Are we in agreement that this is how the code should be changed? No. -- Justin 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?199808010801.CAA22973>