From owner-freebsd-current Fri May 29 15:09:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06012 for freebsd-current-outgoing; Fri, 29 May 1998 13:42:52 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA05957 for ; Fri, 29 May 1998 13:42:34 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA00596; Fri, 29 May 1998 12:36:46 -0700 (PDT) Message-Id: <199805291936.MAA00596@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Joerg Schilling cc: mike@smith.net.au, freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet In-reply-to: Your message of "Fri, 29 May 1998 19:03:23 +0200." <199805291703.TAA14897@sherwood.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 29 May 1998 12:36:46 -0700 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id NAA05971 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >From mike@antipodes.cdrom.com Fri May 29 18:26:05 1998 > > >> First some notes. You are discussing things related to cdrecord. > >> If you like to see your effort back in the main stream cdrecord, this > >> is definitely the wring mailing list. > > >It's a good place to deal with the specifics of making cdrecord work on = > > >FreeBSD though. It's certainly unlikely that Peter would have been = > > I see that this should be discussed on the FreeBSD list too, but if you like > to get help from me, you could not get it from freebsd-current, I am not > subscribed. I understand that. > >The FreeBSD Posix implementation is still under development, and the = > >scheduler module is an optional addition (as allowed for under the = > >spec.). Cdrecord doesn't make the required runtime check for the = > >presence of the desired functionality. > > OK, but this is a new issue. It never has been nessecary before. > If other operating systems will start to behave similar, it would make > autoconfiguration a lot more complex. I suggest you study IEEE Std1003.1-1988 and the definition of sysconf(). It certainly appears to me (and the FreeBSD Posix implementors) that it's legitimate to define the various _SC_ constants without providing the backing functionality. If you have a differing interpretation, and some time to discuss it, I'm quite certain that we would appreciate your input. I take your point that the current state is somewhat unique, and likely to surprise an implementor that's not expecting it. This is somewhat normal for -current, which changes on a day-to-day basis. > >> >> > Bus error (core dumped) > >> = > >> If you are not able to analyze the core with adb and send a usable > >> bug description, I cannot help.. > > >The bus error is (in my case at any rate) due to a buffer overrun = > >elsewhere. I haven't been able to ascertain the cause of this yet, but = > >there are indications that winding back the visible Posix interface = > >resolves the issue. > > I am interested to find the reason for this core dump as it should not > happen. Some versions of HP-UX have the definition for POSIX RR and do not > implement it. On such HP_UX versions you usually get a warning about > the non existence of RR scheduling and cdrecord then uses nice(2). It's due to not checking the return value from the sysconf(_SC_PAGESIZE) in fifo.c. Once you get past that, there's a timing failure between the writer and reader processes due to a similar omission a little further down the file. Having dealt with these, I seem to be dummy-burning quite happily. I'll cut a disc for real to be sure, and then send you my patches for discussion. > I am testing cdrecord on all systems I can get hold of in a way that allows > testing to me (root access). As the SCSI implementations usually are not > sufficient, development and testing is mainly done on Solaris. We can almost certainly arrange that sort of access for you to a CAM system, if you're interested. > >We're not talking about "rubbish". We're talking about an > >in-development implementation of the Posix environment. > > OK, I understand. BTW: I would be happy if the user interface of the new > SCSI user transport calls would be easier to access and to understand. > In other words: > > I like to have the device files be present by default so that > programs like cdrecord onlu have to open the right file to get > access to the device. The CAM interface works like that: sprintf(name, "cd%d", unit); dev = cam_open_device(name, O_RDWR); specifically, it takes care of working out where the device nodes are and how to connect to the device. What you get back is a cam_device structure referring to the device. If you want to search on SCSI ID, that's a little trickier: for (passno = 0; ; passno++) { sprintf(name, "pass%d", passno); if ((dev = cam_open_device(name, O_RDWR)) == NULL) break; if ((dev->path_id == bus) && (dev->target_id == target) && (dev->target_lun == lun)) break; cam_close_device(dev); } The "pass" device attaches to everything, so you can use it if you want to work this way around (ie. as cdrecord currently does). > >It was. The real problems with scg have to do with the lack of visible > >documentation. It is unclear how to do any sort of meaningful error > >handling, or whether this should be managed at a lower level. Again, > >this is an issue I was postponing until I had established that > >everything else was going to behave and the interface had stabilised. > > OK, here is what I send to Sun some weeks ago: Thanks for this. I will verify that I (believe I) am compliant with this before I send you the changes. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message