Date: Fri, 29 May 1998 08:21:43 -0700 From: Mike Smith <mike@smith.net.au> To: Joerg Schilling <schilling@fokus.gmd.de> Cc: freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet Message-ID: <199805291521.IAA02861@antipodes.cdrom.com> In-Reply-To: Your message of "Fri, 29 May 1998 16:14:14 %2B0200." <199805291414.QAA12750@sherwood.gmd.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
listening on the cdrecord list.
> >> > $ sudo cdrecord -dev=0,4,0 -data -dummy /scratch/img/psnl
> >> > Cdrecord release 1.6 Copyright (C) 1995-1998 Jörg Schilling
> >> > cdrecord: Function not implemented. WARNING: Cannot set RR-scheduler
>
> This seems to be a problem in FreeBSD & the Posix standard.
> All other operating systems that define _POSIX_PRIORITY_SCHEDULING
> have it functional.
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.
> >> > 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.
> >> If you set _POSIX_C_SOURCE to 199009L with a -D in the makefile
> >> and cderecord still tries to use the round robin scheduler then
> >> someone has screwed up - either us or cdrecord - so try that too.
>
> Is is not as easy as you think!!!!!
>
> Cdrecord is not a FreeBSD program. It is highly portable and for that reason
> cannoot adopt to any rubbish added to a specific operating system.
We're not talking about "rubbish". We're talking about an
in-development implementation of the Posix environment.
> On SVr4 systems the _POSIX_PRIORITY_SCHEDULING is definitely worse
> than the RT priocntl() interface and proicntl with RR scheduling is even
> available since the early days of SVr4. I cannot change the source in a way
> that only makes sure that nothing works after the change.
This sounds like "rubbish" in SysV.
> >> It checks _POSIX_PRIORITY_SCHEDULING at build time.
> >
> >That's understandable, then.
>
> >> Can you give an example of the correct mechanism for using sysconf() to
> >> determine the availability of the scheduler? I'll fix it in the
> >> updates I'm working on.
>
> > if (sysconf(_SC_PRIORITY_SCHEDULING) == -1) {
> > if (errno != 0) {
> > /* This isn't valid:
> > */
> > err(EX_OSERR, "sysconf(_SC_PRIORITY_SCHEDULING)");
> > }
> > else {
> > errx(EX_UNAVAILABLE,
> > "No run-time support for POSIX priority scheduling");
> > }
> > }
>
> This code is highly non-portable as it uses non-standard interfaces (err & errx)
> This is a common problem on *BSD. Programs written for *BSD tend to get more and more
> non-portable.
It's a trivial example intended to give me an idea of what to do about
the situation, not a patch to cdrecord (note the absence of patch
items). When I have something that works like it "should", I'll
certainly be sending you patches. Until then, and while we're pursing
the definition of "should" in this context, I see no need to drag you
into this unnecessarily.
> The scg drvier which I wrote in 1986 is based on this interface and
> itself is the base for my portable SCSI user-level command transport
> system. It should be faily easy to make a CAM adoption layer for scg.
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.
--
\\ 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?199805291521.IAA02861>