Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Bill Davidsen <davidsen@tmr.com>]

Con Kolivas wrote:
> Albert Cahalan writes:
> 
> 
>> Joerg:
>>    "WARNING: Cannot do mlockall(2).\n"
>>    "WARNING: This causes a high risk for buffer underruns.\n"
>> Fixed:
>>    "Warning: You don't have permission to lock memory.\n"
>>    "         If the computer is not idle, the CD may be ruined.\n"
>>
>> Joerg:
>>    "WARNING: Cannot set priority class parameters 
>> priocntl(PC_SETPARMS)\n"
>>    "WARNING: This causes a high risk for buffer underruns.\n"
>> Fixed:
>>    "Warning: You don't have permission to hog the CPU.\n"
>>    "         If the computer is not idle, the CD may be ruined.\n"
> 
> 
> Huh? That can't be right. Every cd burner this side of the 21st century 
> has buffer underrun protection. I've burnt cds _while_ capturing and 
> encoding video using truckloads of cpu and I/O without superuser 
> privileges, had all the cdrecord warnings and didn't have a buffer 
> underrun. Last time I gave superuser privilege to cdrecord it locked my 
> machine - clearly it wasn't rt_task safe.

This may be a side effect of your scheduler, then. Cdrecord is run as or 
by root on a lot of systems and I've never had any indication that ever 
does anything which hurts response, other than to lock down a small 
memory section for fifo.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me