Date: 31 Jul 1998 10:37:33 -0400 From: Cory Kempf <ckempf@enigami.com> To: Greg Lehey <grog@lemis.com>, freebsd-scsi@FreeBSD.ORG Subject: Re: dev links won't open. Why? Message-ID: <x7iukeytle.fsf@singularity.enigami.com> In-Reply-To: Greg Lehey's message of "Fri, 31 Jul 1998 22:18:31 %2B0930" References: <x71zr2y571.fsf@singularity.enigami.com> <19980731162635.T7830@freebie.lemis.com> <x7zpdqw6ko.fsf@singularity.enigami.com> <19980731221831.K11960@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Greg" == Greg Lehey <grog@lemis.com> writes: >>>> Why? Assuming it is a bug in cam_open_device, can we get it >>>> fixed? >> >>> Well, it doesn't solve whatever the problem might be, but why not >>> use a hard link? >> 'cause it fails the same way? > That seems unlikely. In the case of a device node, a hard link is > effectively a copy. But if that doesn't work, you can always > recreate the node. Well, I provided the code, you can try it yourself :-) The problem, as it was explained to me, is that cam_open_device looks at the path as a string, and parses that string into 'pass' and a number. Any path that does not match that string will fail. To make life more quixotic, I just tried renamed /dev/pass3 to /dev/scanner: the results of the test did not change: it opened (the non-existant!) /dev/pass3, and failed on /dev/scanner! Anyway, Justin has suggested that since I am the one complaining, I should fix it. So I will be looking into in it... +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?x7iukeytle.fsf>