Date: Fri, 29 May 1998 12:36:46 -0700 From: Mike Smith <mike@smith.net.au> To: Joerg Schilling <schilling@fokus.gmd.de> Cc: mike@smith.net.au, freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet Message-ID: <199805291936.MAA00596@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 29 May 1998 19:03:23 %2B0200." <199805291703.TAA14897@sherwood.gmd.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805291936.MAA00596>