Date: Mon, 03 Aug 1998 22:41:37 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Cory Kempf <ckempf@enigami.com> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, freebsd-scsi@FreeBSD.ORG Subject: Re: dev links won't open. Why? Message-ID: <199808040447.WAA10254@pluto.plutotech.com> In-Reply-To: Your message of "03 Aug 1998 23:47:52 EDT." <x7d8ah1k7r.fsf@singularity.enigami.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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. > >Personally, I have never found pointing fingers of blame to be a >productive excersize. "It is your fault" "No, it is yours" I wasn't pointing fingers, just trying to clarify the difference between a tool, and the way that a tool is or isn't used. >I consider the SANE port to be done. There are some bugs in CAM, but >there doesn't seem to be any more I can do to fix those. 8-) >At this point, all I can really do is provide a README file, giving >workarounds. During our conversation, I readily admitted the following things: 1) There should only be the passX and xptX devices. 2) There should be a method for opening a pass-thru device directly as well as being able to specify the device by B/T/L. 3) cam_open_device should be smarter about how it deals with the passed in string, most likely attempting to open it first and if that fails (or a test ioctl fails) using a combination of lstat/readlink and table lookups in an attempt to decipher what the user intended. Ken, the author of the userland CAM code, is already working on some of these items. I expect all three will be addressed before the next snapshot is released. From my point of view, this completely addresses the issues you brought up without any need to look at major/minor numbers. You should tell your users in the SANE README: 1) Hard wire a pass-thru device to the location of your scanner. 2) Either use this device directly when you invoke sane, or create a link. >> Haven't you heard? Major and minor numbers are "going away". > >Whether device numbers are going away at some point in the future is >pretty immaterial. They are here today, and they work today, on most >(all?) unix systems, including both versions of FreeBSD that CAM >supports. > >If / when device numbers go away, I am sure that something that is at >least as functional will replace them. At that point, the old >mechanism can be replaced with a new one that performs the same task. > >Until that point, there is a need to work with what exists. When major and minor numbers go away, the system will rely, as I said before, on filesystem -> vnode lookups in order to determine the device in question. Major and minor numbers might be "emulated", but they will be completely arbitrary. Major and minor numbers were developed as a quick way for the kernel to perform filename to driver indexing. They were never intended for use by userland programs. The whole notion of forcing the user to know some random number of the device they want to access is really quite gross. In the two years that we have been working towards this transition, there has never been any talk of adding something akin to major/ minor numbers to a DEVFS system. There is no "if" about device numbers going away. It will happen by sometime in 1Q '99. Now do you understand why I'm so emphatic about not relying on major numbers? To do so simply adds more work to the DEVFS transition which is already in the works. >I rather expect that they will want to say work on /dev/scanner, in >the case of scanners, especially given that SANE's scripts are set up >that way, and the users will have to edit those scripts. > >In any case, that option doesn't seem to have been left open. I guess you haven't been reading my mail to you then. >>> Are we in agreement that this is how the code should be changed? >> No. > >In that case, there doesn't seem to be much I can do. You sit as >gatekeeper for the interface. Not really. Ken is in control of the userland interface. The ANSI CAM spec is what is driving many of the design decisions about the pass-thru driver interface. >I don't feel any interest in your part in working towards a mutually >acceptable solution, and I don't see much point in continueing to argue it. You put up a, somewhat scathing at times, proposal for changing the interface. At the end you ask, "are we in agreement?" and now you cringe because I said, "no". Do you always expect the maintainers of a system to accept your proposals wholesale without discussion? I agreed with some of your points and didn't agree with others. The question now is whether you are interested in continuing this discussion in order to ensure that your needs are met. >So, you win. I didn't know we were competing. -- 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?199808040447.WAA10254>