From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 4149 invoked from network); 1 Oct 2022 21:23:23 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 1 Oct 2022 21:23:23 -0000
Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Sat Oct  1 17:20:17 -0400 2022
Received: from stockyard.localdomain (cpe-68-174-86-38.nyc.res.rr.com [68.174.86.38])
	by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id f87ae533 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO)
	for <9front@9front.org>;
	Sat, 1 Oct 2022 14:20:16 -0700 (PDT)
Message-ID: <63930A6D48F026FB3A6DAA769914CA81@eigenstate.org>
To: 9front@9front.org
Date: Sat, 01 Oct 2022 17:20:14 -0400
From: ori@eigenstate.org
In-Reply-To: <827131327.3389568.1664620465910@comcenter.netcologne.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: deep-learning JSON information wrapper 
Subject: Re: [9front] [patch] cdfs handle block sizes correctly
Reply-To: 9front@9front.org
Precedence: bulk

Quoth Arne Meyer <meyer.arne83@netcologne.de>:
> The Readblock enum does not work when you try to read audio cds.  4
> cdda blocks are lager than 8192 and the command fails (at least when
> using an usb cd drive).  This sets the block count according to the
> track block size.  With this and the fix for libdisk I can rip audio
> cds on my el cheapo usb dvd drive.  Tested with "Midnight Oil - Blue
> Sky Mining"
> Greetings,
> Arne


> 
>  typedef struct Buf Buf;
> --- a/sys/src/cmd/cdfs/mmc.c
> +++ b/sys/src/cmd/cdfs/mmc.c
> @@ -1171,7 +1171,7 @@
>         o->track = &drive->track[trackno];
>         o->nchange = drive->nchange;
>         o->omode = OREAD;
> -       o->buf = bopen(mmcread, OREAD, o->track->bs, Readblock);
> +       o->buf = bopen(mmcread, OREAD, o->track->bs, Maxrpc/o->track->bs);

these changes smell funny to me; if the block size is larger than Maxrpc, we
set nblock to 0. Looking at bread in buf.c, it seems like we'd simplly end up
trying to read 0 bytes out of these large buffers.