Date: 03 Aug 1998 23:47:52 -0400 From: Cory Kempf <ckempf@enigami.com> To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com>, freebsd-scsi@FreeBSD.ORG Subject: Re: dev links won't open. Why? Message-ID: <x7d8ah1k7r.fsf@singularity.enigami.com> References: <199808010801.CAA22973@narnia.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Justin" == Justin T Gibbs <gibbs@narnia.plutotech.com> writes: >> 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. Personally, I have never found pointing fingers of blame to be a productive excersize. "It is your fault" "No, it is yours" 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. At this point, all I can really do is provide a README file, giving workarounds. > 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. > I expect that they will want to say, "work on /dev/cd0a", not "work > on /dev/pass15". Unfortunately, scanners do not at present have a device driver, nor is it likely that they will anytime soon. The pass through interface seems to be the only option. 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. >> 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. 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. So, you win. +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?x7d8ah1k7r.fsf>