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

[Albert Cahalan]

On Tue, 2004-08-10 at 00:47, Con Kolivas wrote:
> Albert Cahalan writes:
> > On Mon, 2004-08-09 at 18:59, 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'm pretty sure my FireWire CD-RW/CD-R is from
> > another century. Not that it's unusual in 2004.
> > 
> >> 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.
> > 
> > That's cool. My hardware won't come close to that.
> > Burning a coaster costs money.
> > 
> > Let me put it this way: $$ $ $$$ $$ $ $$$ $$ $
> > 
> > The warning, if re-worded, will save people from
> > frustration and wasted money.
> 
> Sounds good; how about something less terrifying? That warning sounds like a 
> ruined cd is likely.

I'm not about to burn CDs trying, but I do believe
that "a ruined cd is likely" would be accurate if I
were to keep busy with Mozilla and such. OpenOffice
would surely ruin a cd. Light web browsing makes my
mp3 player skip.

Not all of us have hardware like you do. Encoding
video is something I wouldn't bother to try, even
without the CD burner going!

(the box isn't that old; it's fanless though)

> >> Last time I gave 
> >> superuser privilege to cdrecord it locked my machine - clearly it wasn't 
> >> rt_task safe.
> > 
> > So, you've been working on the scheduler anyway...
> > An option to reserve some portion of CPU time for
> > emergency use (say, 5% after 1 second has passed)
> > would let somebody get out of this situation.
> 
> This breaks the real time policy entirely. That's why I run it SCHED_ISO ... 
> but of course this isn't available in mainline linux.

Of course it breaks the real time policy entirely.
It would have to be enabled via a sysctl.

The NMI watchdog breaks cli/sti. We have it anyway.
This is the same thing.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/